Week 12

We spent this week getting everything ready for next week's presentations. We did this by finalising all of our interactive elements, as well as preparing for our group presentation.

Lights:
On Russell's suggestion we implimented another gesture based interactive element. The best suited thing was to make the lights based off a gesture, so we set it up so that the lights are adjusted by holding your hands shoulder height and moving them equidistant from your head. Once your hands are no longer at your head height, the system locks the variable to the last set one. We also set the same system up with the mirror lights. Walking up to the mirror switches control over from the main lights to the mirror lights, and the system works in the same way from then on.




Russell also suggested that we add more direct feedback through the UI about what is happening and give some better instructions on how to use everything. I spent most of the studio class setting up these UI systems, and they all work nicely now, giving proper feedback. I had to make them all appear in ordered parts of the screen so they wouldnt overlap eachother if there were more than one being triggered at a time. For next week's presentation we will be coming in the day before to set up an area within the class room to use for our demonstration. We plan to set up a fake bathroom using tables as walls, and masking tape out the different sections of the room, representing things like the bench and shower. This will be the main part of our groups presentation, as we felt that giving a live demo of our system would be more benefitial than spending the entire time talking. Incase the system doesn't work during the presentation I also made a video to demonstrate all of the interactive elements as a backup.



As Matt is always the person in the videos we make (because I don't like being filmed), I've been the one filming them and recording the screen. I then edit these myself using Sony Vegas and overlay the video of Matt onto the screen capture. For these last few videos I also added annotations to explain what is happening.

Week 11

This was the week in which we combined the seperate work that our group members had been doing into one cohesive project. The team working on the modelling and visualisation side of everything gave Matt and myself a copy of the level, which we began to add in our Kinect interactivity. The initial step for this was choosing the right bathroom to use, as they had modelled three sizes, small medium and large. I decided that the best one to use would be the largest, as it would be a lot easier to use this bathroom as an example for our real world demonstration for our final presentation, and the group agreed.

Myself and Matt spent most of the weeks tutorial, as well as most of the next day working to impliment the interactive elements from the Kinect.

Temperature:
At the moment, the temperature control is the only one we have setup with an actual gesture. Like in our earlier demonstration using a ball as a substitute, the user holds their right arm horizontal to activate the control, then by holding their left hand above or below the waist, they can control the variable. I setup a red rectangular prism in the corner of the shower to represent this variable. I thought this would be the best way to show the changes. Our other option was to increase a steam particle effect, but I thought this would give a much clearer interpretation of the effect of the gesture control. This was the easiest of the interactive elements to connect up because we already had it running earlier, and only needed to change what the variable controlled.



Height control:
The height controls for the sink and toilet turned out to be one of the hardest things we worked on in the entire project. Our earlier creation along these lines was the "bench" (sideways door), that would adjust it's height according to the users knee level was a simplified version of what we set out to create here. The early test had no constraints, but we wanted to put a lot of constraints on these objects. One major concern was a maximum height, which was easy enough to limit in the flowgraph. The other main concern was only activating the controls when the user wanted them to. For this, we decided to use a proximity test. If the user is within a certain distance to the sink or toilet, the flowgraph will activate the part of the graph that controls them, otherwise it remains at it's last set variable. We set this up after Russell had a look at the work and suggested that their constant moving would wear out the parts much quicker in a real life version, so stopping it when it's not needed would save this wear and tear. Additionally, it stops them from moving when for example you bend down to grab something, or the sinks moving when you sit on the toilet.



Light controls:
At the moment we have the lights setup so that they will activate when the kinect recognises someone in the room. This seemed like it would be easy, but turned out to be difficult because of the way the kinect works. Because of it's limited range, it is difficult for it to see someone on the outskirts of the example room from where we have it situated. Also, when the kinect loses sight of someone, who for example has left the room, it leaves the last set of data it registered in the system, so the orbs we use to represent the player stay where they last were. This means that the lights will mostly stay on, even if you leave the room and the Kinect's range.
We also setup controls for the mirror lights. They are setup similarly to the toilet, and will turn on when the player moves near them.

Emergency fall detection:
One of the earliest ideas we had was a test to determine if the user had fallen over, and if so, call an emergency or family line. We found this to be a really important test due to the entire project being aimed at the elderly. One problem we kept running into was that when the user lays down horizontally, the Kinect loses it's ability to properly track them. The coordinates sent to the orbs jump very randomly, and this can sometimes turn off the trigger. We went through about three different tests to get to one that works reliably. It tests to see if the waist height is within a certain limit of the head, over a period of time. This counteracts things like bending down to grab something, which would not be within both the time and position limits.



This week I also created a number of videos. I very much dislike being filmed so I had Matt demonstrate our work, while I filmed it. I then edited it together, using both a video I took of him demonstrating and a screen capture I took of the interactivity working in CryEngine. I synched these and edited them, then uploaded them to youtube.

Renumeration presentation review - Vivid group

The Vivid group were the last group to do their presentation, which was on the topic of renumeration. I have very mixed feedback for this group because half of the group presented well and half not so well. The ones that presented well spoke very clearly and were as engaging as you can get for a presentation on renumeration, although at times they did speak in too much detail, taking up far too much time. The other side of the group gave off the feeling that they were very unsure of what they were talking about, and provided far too little detail. The half of the group that spoke well did so by reading their notes to the audience, rather than just reading their notes. They were able to elaborate and properly explain things rather than just reading a page full of large words to impress us like some other presentations have done. The other half of the group spent most of the time reading their notes off the page and didn't elaborate on anything. The written part of the presentation definitely had thought put into it's structure, as each section flowed pretty well onto the next. It's only flaw was that it sometimes had far too much on the screen at once, so it became a little difficult to take it all in at once. There was also a lot of jargon that was thrown around without being properly explained to people that hadn't researched the topic for a presentation. The examples they provided were very well explained. Especially the case of using Pat's real world pay slips to demonstrate what they were talking about. One thing I would have liked to see was their project being reflected in the presentation. Their project is the only real world project with a budget and an end goal, so it would have been nice to see some of that come out in the presentation for relevance.

Group Presentations - Conflict

DCLD: DCLD were the first out of the two groups to give their conflict presentation. Overall, the presentation was very full of information, but it's main downside was that it had far too much text on the screen. This was a common factor amongst all of the group members sections. The written part of the presentation had lots of details, but in some cases this caused a problem as they were expecting to get too much information across at some points. They also had an issue with using too many lists. On a majority of slides, all the information would be listed, in full detail, and they would simply run through this series of dot points one by one. This gave the presentation a very disjointed feel as they bumped from one topic to the next without any kind of transition. The oral side of the presentation suffered due to the nature of their slides. They had all the information they wanted to communicate to the audience written down on the slides, and then simply read off them. A lot of the time I found myself reading the entire slide quickly then losing attention to what was being spoken about because I had just read it. A more affective way of presenting would have been to have the dot points on screen contain only snippets of the information, or headings, which would then be elaborated on in the spoken component. There was also a sense that the group wasn't particularly organised for their presentation. I got this from the way they changed between the person who was speaking. They would throw the presentation over to someone else who seemed like they didn't know where to pick up. This made each section of the presentation seem like it was disconnected to the rest. The images they used were pretty decent, although a bit small or full of words sometimes. The flowgraphs seemed like they were very relevant, although it was hard to make out the details due to their size. As far as I could tell, all the images were referenced, although again they were too small to read. These problems would be negated if I had a copy of the presenation, but being in the audience as it is delivered, you cannot make out the details. Kinecting the boxes: Kinecting the boxes presented second on the day. The written side of the presentation was well done. Like the last group they used plenty of lists, but not quite to the same extent. There was definitely more of a flow between the topics, so it seems like they did think through the flow of their presentation and how one person would hand onto the next and link their subject matter. They used plenty of examples to demonstrate what they were talking about, although they were somewhat vague and unrelated to their groupwork. While this isn't wrong, it would have been nice to hear about some conflict resolution that had happened within their own group. In terms of their oral presentation, it was significantly better than the DCLD groups. They read off notes rather than the slides, which meant the audience had to listen to the presentation to gain the knowledge. They did somewhat fail to engage the audience though, as they were merely reading and not talking to us. Like the previous group, the images they used contained far too much text, and in some cases, like the flowgraph, were too small to read and took far too long to explain. I found myself losing some interest during these long explanations. They explained their topic well, but it is hard to tell if they understood what they were telling us or simply reading if off the paper infront of them.

Kinect interactivity update

This week we've been working on creating more interactivity with the Kinect into CryEngine. We've done a lot of coding in C++ to look at skeletal positions and output these into the game engine. Using the flowgraph we can then use these vectors to interact with the game world.




 This video shows the initial gesture control we've set up. By holding your right arm horizontal you activate the flowgraph, which then determines whether your left arm is above or below your hip. By raising or lowering it you can alter a value that will later be used to change water temperatures in the shower or bath. It could also be used to dim lights or dynamically change other variables in the bathroom.





This  demonstration shows a proximity test. There is a radius around the ball that when inside this, the ball will change sizes depending on how close your hand is to it. This can be used to set lights on and off by moving your hand near them, or to taps on and off.


This test calculates the distance between your foot and knee then scales the height of a seat or bench depending on that variable. This is used to alter the height of seats and benches to better suit the ergonomics of the user. I investigated into proper ergonomics of seats to determine that proper comfortable seating leaves the user with a bent knee just above a 90 degree angle. This calculation should ensure that is the case no matter who sits on the seat.

Milestone followup

As an extention to the milestone post, here are example of the arduino kit working as well as the kinect interacting with CryEngine 3.

Simple Motor:

This is a simple motor being turned on and spinning at a set speed. This is a very basic form of how our Kinect rig would spin and move. By altering the variables in the code for how fast it spins we can control the amount of rotation, and by linking the movement up to a different input variable we can determine when to move it.
A copy of the code to create this can be found here.

 Light turning on and off:

 This example shows a light being turned on and off by buttons. It demonstrates the ability to toggle one aspect of the arduino with an input other than just power. In this case it's a switch toggling on then off, for our project if could be input from a an aspect of the kinect sensor telling the arduino to act.
A copy of the code to create this can be found here. This code comes from a basic code that keeps the LED on, and is modified to allow for the button to turn it on and off.

LED dimming:

This one is essentially the same as the last, although the loop part of the code is altered to constantly increase or decrease the brightness of the LED depending on whether the on or off button is pushed.

Light array:

The light array code turns all of the lights on at the same time, while applying an increasing delay on them as it moves along the array, making it look like the light is moving across them all. The notion of a delay in code would be useful to our project both in moving the Kinect, as well as interacting with the Crysis environment through the Kinect, as some interaction would be useful with a slight delay, such as positioning different things in the bathroom to suit the occupant.
The code can be found here.

 Potentiometer:

 A potentiometer is a resistor that, in this case, connects to 5 volts actoss its three pins, and will read a value between 0 and 5 volts depending on the angle it is turned. In this setup, the value is stored and used to determine the speed at which the light turns on and off. The application of this in our project is that it demonstrates how to gather an input, store it's data and then use that to change an output.
The code can be found here.

Individual Major Milestone

Within this project, I set myself a few milestones at the beginning in preperation for this point in the course. The main thing I wanted to do was to further my knowledge of programming and try to focus on that aspect of the project's development. I was also very interested in the mechanical side of our design proposition, with moving the Kinect around a room in relation to a persons position.

At this point in time, I'm in charge of the group, although it wasn't always that way. To begin with, Laura was our leader, but because she wasn't confident in her ability to be in charge of the group she asked me to take over. I have mixed feelings about this for a number of reasons. Firstly, it was probably a good idea because I feel like I would be a better group leader than her, especially if she went into it with the idea that she wouldn't be. In contrast to this, I have a feeling that it would have been better for the group as a whole if she had stayed on as our group leader. At the moment our team is struggling with interaction, mainly due to the language barrier we face with having members who don't have English as their first language. Having Laura as our leader may have negated some of this as she would be able to take charge in their native language where I struggle to communicate with our group members sometimes.
I feel that this barrier we face as a group has somewhat hindered our ability to work thoroughly on our project. In conjunction with this language barrier, I feel that some of the members of the group have a large disinterest in the project, so much that they work a little on their part of it then put it out of mind. This makes managing a large project quite difficult, as it means work is either not delivered or it's delivered at a subpar standard. The only course of action we've been able to take in relation to this is to press on with our work as best we can and not overly rely on imput from all members of the group. The way we structured our project initially means that there are two main focuses for our group, and at present we are able to press on with at least one of these working properly. While this means we may not end up presenting everything we set out to present as a final project, it does mean that we will be able to have a large section of it finalised, be it proof of concept or finished completely.
As group leader, seeing early that these issues were arising, I had to add my milestone the notion of keeping the group running as smoothly as possible. I feel that to a certain degree I've been successful with this so far. A lot of my time in this project has gone towards trying to ensure that everyone knows what they're doing and when they need their work to be completed. Though no matter how much I stress these issues I still find that it is out of my control if the work actually ends up being done or not, which can be frustrating, especially when that work then falls onto others to complete.


Mechanical Design:
From the outset of our project, we split the group into two parts, the design of the mechanical and programming side of things, and the Crysis side. Myself and Matt took the physical aspects of our project and have been working on these since the beginning. Together we discussed idea for how our system would work. Matt designed the initial Kinect Rig, drawing up the plans which we eventually had laser cut into a prototype. Through this stage, I helped a little in talking through the design choices, although most of the work on this front was Matts.

My work on the mechanical side of things has been through the conceptualisation of our system for moving the Kinect across the room. Our initial brainstorming came up with the idea of using a Spider-Cam like system to move the rig across the roof of the room.

This type of system runs wires from each corner of the room to the decide. Motors at the corners extend or contract the wires in unison, allowing the system to move freely. I've investigated into these types of devices to see how they run, as well as how to integrate it into our proposed system for the Kinect. At the moment we are still trying to narrow down how this would work if we were to add it into our prototype, so at the moment it's use is purely theoretical.

Programming:
My main aim for this project was to immerse myself into the programming side of it, as so far I have very little to no experience with that sort of thing and would like to know more about it. The project focuses on programming on two fronts, the Kinect's integration with Crysis, as well as Arduino to run the motor systems for the Kinect.
For the Kinect, we're managed to get the integration with CryEngine 3 working properly with Stephen Davey's help. At the moment what we can do with it is fairly basic, and will probably need us to get into the code of the Kinect and Crysis SDK to achieve what we want it to do. The next step for me will to be looking into these codes and seeing if we can get positional data for each limb on the person being tracked. This will allow us to be more interactive with the bathroom appliances with gestures and body positioning. It will also enable us to do things like changing the height of a toilet seat or shower head depending on the size of the person in the room, two of the major interactive parts we were hoping to achieve.

The other part of the programming that I've been looking at has been the Arduino. Coming from having basically no programming knowledge, fiddling with the Arduino kit has been difficult. I've gone through a learning booklet that Russell provided when he gave out the kits, which has taught me a few things, but at the moment I can't just sit down and make it do something, I need instructions to achieve this. My accomplishment so far is that I actually now understand what all the code is saying, and can figure out some problems when I come to them. I'm very happy with this progress so far, as I was completely stumped by it all initially. So far I've been able to do everything we will need for our rig to work. I've been able to get a stepper motor to move depending on a varying input amount, which would be what drives our spider cam style rig, as well as rotating the Kinect around on it's rig.



So far in this group project, I feel as if I've made progress towards what I set myself out to do at the beginning. I've been able to further my knowledge of programming, as well as how to practically apply that knowledge to our project. I've also been able to help design the mechanical systems that will eventually run it all.
As the team leader, I feel like our team is slowly moving forward, although a lack of interaction has dramatically limited our progress. I feel that if we keep moving at this rate, we will be able to accomplish something substantial, although not at all what we initially set out to do.

Week 8

We collected our laser cut prototype friday of last week and have now assembled it.

We were very happy with the way it turned out, although I feel I should stress this is only a prototype. There are a few issues with this current version that need to be fixed. The main one being that we measured the Kinect wrong, so the brackets that hold it in place are too large and it slips out. This would easily be fixed by measuring it correctly and laser cutting only those pieces again. The rotation mechanism works surprisingly smoothly. The whole unit ended up costing roughly $80, which at the moment is far too much, and could be cut down if we were to do it again.
We looked at alternative mechanisms last week and settled on one specific one that Russell ordered for us from the UK. it can be found here:
http://littlebirdelectronics.com/products/df15mg-tilt-pan-kit-15kg

It's a pan and tilt mechanism that offers two axis of movement. So far it is the only commercially available unit that we've found that looks suitable, so I'm looking forward to actually getting it and seeing what we can do with it.


This week we also gave our groups presentation on Intellectual Property. I feel like it went well. Our main strength was that our group talked about the topic in the context of our project, which the other group that went this week failed to do. The text for our entire presentation can be found on our wiki HERE