As it turns out a friend of mine works at the SNO!zone in Braehead - an indoor ski slope. I have been thinking that it may be best to angle my project towards an indoor centre as it allows for more control over the environment in which the cameras operate. I know the scope of my project doesn’t really cover all these details but it also means I am not limited by there being snow or not as to whether I can film.
However, filming at the centre is strictly forbidden (even taking photos of your kids requires a photo release form and even then only from the balcony). I have been in touch with the centre and am waiting on a response from the PR and Marketing director as to whether I may be granted special permissions. Here’s hoping.
Other news
I spent a little time today working on the new code for the camera which I received from johnnyonthespot (at the Arduino forum). I had hoped that I may be able to apply the logic of the new code to my hardware setup but as it transpires my servos may be fatally flawed.
Johnny’s approach uses continuous rotation servos, I (think) I have standard servos. I manipulate mine by telling them which angle to go to - I can’t manipulate speed, etc. I fear that to be able to use Johnny’s approach I will need to rebuild the hardware.
I know I had thought of this, but I had hoped to be able to rejig my setup and fix my issues using code. So, the decision here (assuming I do need new servos) is whether a build a second unit (at cost and time) or modify my current unit (at a lower cost and shorter time but more risk). Why is life never simple?
It’s been a wee while since I updated this blog with anything properly uni related. So here’s the run down on what I’ve been doing with myself in regards the SlopeScope interaction design project…
Since the MkII hand in I’ve been primarily focused on getting the other elements of the project finished up a bit more; i.e: the website and iPhone app. This, annoyingly, I’m finding to be a real struggle. For some unknown reason I have lost the ability to design websites; every time I work on something I find myself hating it with a relatively short period of time. Still, I’m beginning to get somewhere and have the basics of a website kinda there, see below.
Viewing a High Definition video in the browser:
As you can see it is still very much in its infancy but at least it’s a start. I’m my biggest critic and I’m pretty hard on myself. My biggest worry here is that the website and iPhone won’t justify the concept of the project. I feel like these two elements have to be super well done as they are a core aspect of the user-service interaction. However, my project is primarily about the camera movement technology and how it relates to this conceptual service. I guess what I’m saying is that I can’t nail everything (although I’m definitely aiming for it)
Breakthrough in WiiMote code
The next piece of news I have is that, eventually, I received a response on the Arduino forum. I posted a thread asking for help in regards the jerky motion of the WiiMote. Some kind fella has done something very similar to what I’m doing (a Wiimote controlled pitch/pan system … OK exactly what I’m doing). His approach was radically different to mine however but seems to be a more sensible one.
His uses a constantly rotating servo which rotates faster or slower dependant on how near to the edge of the field of vision the source is; when it is sufficiently close to the centre movement stops. Another cool thing here is that he is doing it completely within the Arduino and reading directly from the expansion port on the back of the WiiMote. I still need to work out a little more of the hardware issues but this could be a lifesaver. Check out his demo video:
Now, herein lies the deal breaker. To do this would require a lot of work, in fact I’d probably be more sensible building a second unit but that means more costs (a cool £45 minus delivery + £15 [if I want a black WiiMote] + £20 [if I buy an extra 2 servos]. Yikes). The reason I say this is that if I failed to build it in time I’d still have my original which would suffice for the degree show but it’d be ncie to have a smoother, more constant demo - something I feel is important (but I’m scared I’m running out of time). This is something to discuss with Graham methinks.
Another bonus for rebuilding is that It’d give me the chance to implement the old iSight which Ali kindly lent me. The camera is of a FAR higher quality than my current ‘webcam’ (if you can call it that) and has things like autofocus which is a nice extra. However, it’s caveats are: it’s much bigger and would need an entire redesign of the case and that it get’s kinda hot. Potential issue here? *sigh* it’s never easy is it.
Tell Phase
Finally, I am ever aware that I haven’t really started thinking about my Tell Phase i.e: the video, images and story behind my project. I need to create a minute long video which summarises my project and captures what it is, what it does and who it’s for. A minute is painfully short though…
While the minute video is my deliverable I’m thinking of producing a second, longer, video to document how the finished project works; covering aspects such as the mechanics of the camera, Arduino code, the iPhone app and the javascript behind the website. I’d like this video also tot ouch on the concept as a whole. Basically I’d like to create a mini documentary on the project for my folio and to show people so they can understand all the details. This, for sure, will have to wait until all my other deliverables are at a sufficiently high standard.
Tomorrow I continue with the website and hopefully over the weekend will wrap it up so I can start to focus on my Tell Phase; I really want to nail this bit good.
Katy managed to pick up some IR LEDs from Maplin when she was home over the weekend for me. After successfully blowing up two of the few seven I had I succeeded in creating an ‘IR pen’ - i.e: an empty biro with an LED and a resistor soldered together inside.
Now I have a constant, non-flashing, IR source (but still without my second stepper motor) I can start building the second part of my project - the pan/tilt mount. Using the processing code I developed in my Zoom Phase (a hacked apart IDEO project, this one in fact) I made a make-shift pan rig. I mounted a HandyCam and the WiiMote to the top - professionally with sellotape - and recorded a Point of View video of how it looks. The result is somewhat jerky but it’s definite proof that the system can work (and in fact only needs a bit of dampening). Yay.
Below is a photograph of the setup (minus a WiiMote, well, it’s there but not attached as I’d dismantled it all to downlaod the video from the camera before I thought to photograph it - silly me).
I’m still not entirely sure how I’m going to build the entire pan/tilt unit nor am I sure if the motors will be strong enough. I may be spending a day in the Product Design studios tomorrow…
Today’s major goal of the day was to be controlling the motion of a stepper motor from the computer, preferably in Processing, thus completing the path from detection (WiiMote) to physical movement (motors) - theoretically.
I have been successful to an extent; I can control the motor from Processing - great - but not in the way I would have liked. I was aiming to be able to explicitly tell the motor to turn X number of steps and for it to unquestiongly to oblige. My downfall was serial communication…
Serial communication sends information bit by bit; as an example let’s say Iw as sending the value of 100 to the stepper motor, which on a 100 step motor should mean one complete turn. The numebr 100 is in fact three seperate bits, a 1 a 0 and another 0. The Arduino would read the first character and act, then the second and so forth. This meant that rather than one complete turn my motor was in fact moving just one step (1 step followed by 0 steps and then another 0 step). Disaster.
In a bid to try and outsmart it I wrote all sorts of loops and other clever coding bits to try and catch all the values and then apply it to the motor - all failed.
However, I have now realised that in practice I will likely not need that sort of precision. As everything happens so fast the changes between tracked points will be small so single digit values are probably going to be ok.
A little more thinking led me on to consider these serial values as ‘speeds’ and I would actually hard code the steps into the Arduino code. The theory this time is that I can constantly tell the motor to turn (say) to the right at speed 3 for as long as I transmit the number 3 on the serial port.
So imagine, if you will, that I have 7 speeds; 1-3 are clockwise speeds, 4 is stopped and 5-7 are anti clockwise speeds. The setup could have a sensitivity/speed setting which is customisable in the code on the computer - leaving me in the ideal situation where the Arduino is an interface and not actually doing much thinking for itself.
So far so good. Zoom phase seems definitely focused on getting the concept working.