Try, try again.

After breaking the setup my Processing for Android installation, I opted to rip out the Android SDK, rip out Processing, delete all remaining files and folders and environment variables.

I then re-installed Processing and let the fresh Android Mode install the Android SDK (rather than hook into my own  installation).

A little wrestling with the permissions on the sketch for the camera and I was (finally) able to get both my front and my back camera running on my Samsung S2.

Now we are away with modifying a bloggie lens to sit on the phone and to use the processing unwrapping of the bloggie image to knock up a collision sensor.

One snazzy sensor

Pixie up and running

I installed the pixi monitor app and drivers and got the pixie up and running.  I am looking at seeing if it will build signature(s) of my inlaw’s cross shih tzu dog to chase it on the back of a cheap knock about rover.

Chase that dog!

Actually!!

I have a Sony Bloggy (one of the first models with the rotating camera) and anyone who knows Bloggy knows it has a panoramic lens attachment.

Did you know that you can do optical avoidance relatively simply with a panoramic view (http://www.pirobot.org/blog/0004/)?

So, I will need to see what needs to be done to use the bloggy, or the omni-directional lens from the bloggy with another camera.  Since the lens is designed to work with the Bloggy camera I am guessing it will be tune the distance which may require some machining of the lens to fit it to, say, the Android phone.

I will use the PC as the remote smarts for the moment is that the proof of concept will be using RoboRealm Vision for Machines (http://www.roborealm.com).

First good thing.  If you do your research, like any good little integrator, you’ll discover some quite expensive omni-directional setups (>$1K).  So, Bloggy lens (at around $100) is a bonus.

So if you can use the bloggy itself, streaming to your BeagleBoard running Linux that would be one option.  Would take some work, what with having to find/write drivers etc.

The second is modify the lens base to work with Android phone camera and use IP WebCam to pump images up to client (Android or PC) for processing.  (This will be the approach for the prototyping.)

Mind you, Snapdragon S2 based phones will drip in price soon enough (makes me wonder why you would bother with Beagleboard if a Android phone plus Arduino would give you more for less) – my S1 based phone was $70.

So busy with work but here is updates to date

ARDrone now in possession.  Second hand from a pal who has moved to China for work.  Good luck D!

I am buying a house so stocked up on a few things in meantime.  9DOF Razer etc.

I got a DF Bluetooth for the ROMEO as the USB Host board covered too much around the edges.  The initial experiments will be from the laptop any way (which now sports dual boot Ubuntu and Windoze).

First experiments I am working towards are using IP WebCam (on Android) and Cambozola to produce something like the functionality of WOWWee Rovio (basic video streaming and remote control) before moving onto using OpenCV to experiment with flow optics.  OpenCV is slowly being ported (under open source by TI – see here and here otherwise go here otherwise here) to the OMAP devices to accelerate it on the ARM side of the world – so no need to rush to install on Android just yet.

[QualCOMM Snapdragon S2 and above has an already tuned fast CV library (go here). Pity my phones are S1 😦 ]

Android phone (acting as video streaming service) will be taped to front of indoor carriage as there is no real need to put any more dings in the ARDrone (just yet).

The neat thing about IP WebCam, from an integration point of view, it could just as easily be used as a video stream to a application on the phone that is serving the video.  A nice way of decoupling the functionality.

Also grabbed a MEGA IO shield on sale.  It has an SD card pinout (I already have the SD card breakout) and an XBEE site.  This will be great then for experimenting with OpenMAV protocol for moving to the outdoor carriage.  It will also be used for the prototyping work – so the more capable boards don’t get handled as much OR charred if something goes wrong 😉

It’s here! And it’s perfect!

The RC sail boat servo turned up.  Phew! … on a number of counts.

I guess I didn’t have a sense of the size of the thing when I ordered it AND was always curious how I would mount it.

Turns out is is relatively large BUT if I cut off one of the mounting flanges the thing will araldite or double-sided-taped in place AND it will EXACTLY fit into the nook in the front of the chasis.  The “winch” is large enough to clear the rack steering AND the “winch” lines up exactly over the rack.

Above it is loosely dropped in to give the idea.  A small amount of “surgery” will be required to fit it.  The pulley has a couple of small holes in it so the pulley cable won’t slip.  The 360 degree motion is more than what is needed but I thought it might help if some amount of auto calibration is required.  I am thinking of something as simple as a black spot on the rack (look beneath the pulley) and a means to find the SPOT (apt since this is a dog chaser).

Chase that Dog Platform

So the basic 1/10 monster truck chasis.  All electronics ripped out.  Notice the basic steering.  There will be a RC Sailboat Servo with a pulley as a winch to steer this.

Notice USB Host shield inserted into ROMEO.  Still have to double check pin allocations …

As integration approach, will work initial software integration using Freeduino USB host and IDEOS, then sort out ROMEO with USB Host shield once familiarised.

BroooMMMM!!

I have  a ROMEO 1.0 board mounted on a cheap 10x toy rc truck, which I am using for the basic experiments (Rock Crawler unassembled in cupboard until experiments mature a little).

I took the RC gear out of the truck, including the clunky left-right only steering.  I am replacing the steering for a RC sail boat servo which has 360 degree rotation (1x) – rather than 180 degree of the standard servo.  It also comes with a pully so I can use it to provide proportional steering to the chassis.

PWM experiments disappointing so far.  The toy status causes a problem as the gearing is quite high, so once juice enough to turn the wheels, it lurches ahead quite fast.