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.

Well, sadly, this week has been a bit of a write-off with fundraising taking up more time than anticipated. I’m going to be in Manchester this weekend also which means I can’t be in the studio working away. *sigh*

I had a catch-up chat with Graham the other day which highlighted some issues; in a nut-shell I’m terrified at the amount of work that needs done and I’m getting slightly scared that I’m just not going to be able to cut it. In short, I spy panic town in the not so distant future.

Anyway, to summarise my chat with Graham, I am approaching my project more as a well developed proof of concept (I think). This is the antithesis of what I was setting out to do. In the early days of the project I wanted to create something which was very well executed, looked great and had a very specific purpose. I am now aiming to boil the concept down into it’s three main elements demonstrating them well and documenting them thoroughly.

I feel like I’m getting caught up in the product design element of the project now and neglecting my core skills as a graphic artist and interaction designer; many elements of the project still have a long way to go before I will accept them as anywhere near complete. As such I’ve made the decision to build my prototype camera/pan-tilt unit from card and ‘decorate’ it with the visual language and branding which will apply across the elements. This will bring a unity to everything while also making it very clear that I am not a product designer and hence not focused on the materials but instead the interactions (for lack of a better word) and user experience of the concept/service.

Regardless, I have mounted my pan tilt system onto an old tripod but in order to do this I had to seek the help of the workshop staff. No blog post would be entirely complete without photos so here goes…

Roddy preparing the cylinder which will securely hold the servo.

And a little wide angle shot to give an idea of scale.

Graham asked us this morning to answer some questions as regards our project in a bid to help us think a little about the direction our ‘Make Phases’ are going.

What will it do / what won’t it do?

Make Mk1 (MM1) is about creating the ‘first versions’ of the elements; prioritising on the moveable rig and the iPhone app as I feel those are the key aspects of the project - if a basic website can be put together for MM1 then all the better however will not be focus.

What will it show / what will it not show?

- design / fee/ aesthetics / “looks like works like prototype”

MM1 is a “looks like works like” prototype; I want it to have at least basic functionality (camera tracking and iPhone demonstration). The app is in a relatively ‘demoish’ state with basic concept being portrayed well with dummy data. The rig however is still in proof-of-concept form on a breadboard while I await components. The majority of the next two weeks will be spent constructing the first iteration of the pan-tilt movements. If not possible in MM! I intend to use MM2 to  link the elements of the project together (i.e give the iPhone app “real” data to work with)

How are you going to do it?

MM1 will be split mainly into two parts: rig and app.

APP: The app is being built using the PhoneGap framework where native (also offline) apps can be built using HTML, Javascript and CSS. I have chosen this route as taking the time to learn Objective-C will inevitably lead to a less impressive app; by suing skills I already have I can fine-tune the interactions well.

RIG: This is slightly out of my comfort zone and as such will be seeking help from experts in the field. However, as a basic overview I can see the rig taking form by hacking apart the dummy CCTV camera mount I have as a basic structure and adding the mechanics in around it. The whole system will be controlled by an onboard ardunio board with two cables (hopefully shrink wrapped into one) coming from the uni: a USB cable (unless I can find wireless functionality) - possibly a MM2 consideration and the power cable for the stepper motors.

In other news, I still don’t have my components (tomorrow, hopefully?!) and no one was available to help me get my iPhone app working on my iPhone today. *sigh*

After the success of documenting my work throughout the Zoom Phase I am disappointed to realise that I have all but stopped writing about what I’m actually doing or the thought processes I have been going through.

Just now a lot of my time has (stupidly) been spent working with some of the others on advertising material for our Degree show Fundraisers (‘Tache Bash for those not in the know). Whilst it is entirely necessary (and important) to make sure this is a busy event so that we can benefit as much as possible from ticket sales I have to remember that my degree is paramount.

I had intended on trying to catch up with my uni work tonight but I’m struggling to find something useful I can do. Recently I’ve been building and fine-tuning my iPhone app while I wait for components to be delivered. Once said components are here I can try my hand at building some of the tripod system; I can’t wait to be able to have all the elements connect together (albeit maybe crudely). For Make Part 1 I’m intending on having (basic) functionality and connectivity between elements which demonstrate the key interactions of the project.

Make Part 2 will build upon what I achieve in Part 1 and polish everything up. I really want the system to actually work even if it is not built to look like the final product; i.e: a prototype tripod which records realtime video which the iPhone app then picks up on and can be used to watch back the video (it’d be awesome if the users could also then post it to their Facebook or similar - maybe too much effort, could be a demonstration feature or something on a board or video). If I can get these two elements working then having a website which also interacts with the recorded data will just be a matter of data crunching and time spent on design elements - the back-end will practically already be there.

Excellent, now I just need a name for the whole project; any ideas?

This is the result of seven hours worth of work with the IMD PR team for our upcoming fundraising event, ‘tache bash (Twitter and Facebook - please follow and if you’re Dundee based come to the event!). They need to go to print by 10am tomorrow (this?) morning with half the class not having seen the final products. Obviously we could only photograph the people left at the end of the meeting but the plan is to have a poster for each of us for use all around campus.

Let’s hope there isn’t a huge amount of damage controlling to do amongst those who didn’t bother themselves to come at all.

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.

Well, today was a success. I have now got the wiimote connecting via Bluetooth to my MacBook and it’s all happening in Processing. This is ultra cool as before all the connections were happening through compiled applications meaning that I was unable to script custom code easily without some level of hacking; but now I have script access to it meaning I can pull data from the sensors efficiently and easily.

Most of what I achieved today was from tearing apart the source files of an IDEO wiimote project. If you already weren’t so high in my estimations, IDEO, I’d place you higher!

Anyway, I’m hoping I’ve not spoken too soon as I am still a VERY long way from being anywhere near a prototyping stage. That’s all still to come.

At least I can now work in my preferred way; with code!