Archive for the Prototyping Category

OMG!

Posted in Processing, Prototyping on August 23, 2015 by asteriondaedalus

I have IntelliJ IDEA on my desktop, I sort of flick between it, Eclipse JDT etc.  I had actually pulled it up to use it for my Elixir and Erlang programming.

Turns out BoofCV has a Gradle build and is IDEA friendly so I thought I would poke around and make a few changes.

One thing I wanted to do was to look at integrating sarxos webcam-capture in with BoofCV and I was poking around trying to workout how to do that.  Well, turns out there is a folder in the BoofCV project in IDEA that actually already does this so I was able to run a couple of feature and object tracking examples off my Bloggie.

I did note they were using 0.3.10 versions of webcam-capture so the “get camera by name” method was missing, so I had a look at how to add it in the IntelliJ IDEA.  I will have to get a Gradle book but it looks like an xml file pulls jar base libraries into a cache.  I did the change the dirty sneaky way and I copied 0.3.11 over 0.3.10 in the cache to see if that would let be play.  It did and I modified a BoofCV class to allow for named webcams.

I will still need to read up on Gradle to work out WTFO on the URL and the URI that seems embedded in it.  Might not be straight forward as 0.3.11 does not appear in the main or tagged branches yet (you can download a jar with that version from the sarxos site however).

So, will now look at prototyping the omnivision collision detection and fuzzy steering on my PC before porting to the Processing for Android.

I am feeling it is all doable.

Robot fish

Posted in Arduino, Prototyping, Sea on September 18, 2013 by asteriondaedalus

robo fish

 

Go figure you don’t have a realistic “fish” thing going to build a robotic fish.

With the $10 second hand handycam dive enclosure we have a body.

sony cam

 

Now I was saving pennies for waterproof servos to see if they would paddle this along.

Then I noticed cheap (really cheap) camera gimbal drivers and brushless motors.  Brushless motors, in principle, can work underwater (plenty of examples on you tube) so I thought why not gimbal motors which work like servo motors.  I will have to re-code the driver but it will be to take the IMU code and replace it with sinusoidal drivers to “undulate” the tail.

gimbal driverI bought 4 $13 motors to try the idea out.

 

Snapping it all up

Posted in Hardware, MESH, Prototyping on August 28, 2012 by asteriondaedalus

So, a rough start to using SNAP but a good bit of understanding now.

One exciting discovery is the SNAP Connect Python code has had a change in licensing and you can use it FREE for up to 10 nodes (not including Portal or the PC root node).

I have been looking at integrating SNAP networks with ROS and ROSPy seems to be the go – but I really need to build a LINUX box so …

Along with the ROSPy there are various other libraries I have been grabbing for rpc in Python and connecting to CORBA (OmniPy for OmniORB).

The SNAP connect can be used over networks yadda so pretty cool (I am thinking of introducing my nephew to robotics and the ability for him to control things my end or me to upgrade software at his end is a great feature – we live about 1000km apart).

DESIGN DECISIONS

Now that I am flying with SNAP I am looking at a basic bit of code to run on the Flyduino to allow me to run it remotely via the SNAP Connect Python code.

Ahead of this I have been looking at the schematic and, while it allows for 12 servos to be controlled, I will limit this to 9 to give me the SPI channel.  Also wik, while the Flyduino provides 8 Analog in I will look at whether I can keep pins 27 and 28 for an I2C channel.   This will allow for some smart sensors on the Swash Bots.  This will allow for gaits to be run from the PC until they are too finely tuned.

Also 6 servos and use D8, D9 and D10 for chip selects for the SPI bus or inputs for bumpers … oh yeah, already decided on visual odometry.

The little board is actually quite flexible, below is the SNAP RF266PC1 (XBee clone) sitting in the socket.  I am looking into the simple mods to allow (perhaps) programming the Flyduino wirelessly.

flyduino

Events, QP vs. Armarino(MeetAndroid)

Posted in Arduino, Prototyping on May 29, 2012 by asteriondaedalus

A little experiment with the QP event based material and then dabbling with Amarino for a couple of hours and the conclusion is simply that the Arduino side of the Armarino will go.  The MeetAndroid sketch simply builds a simple event based toy so that would be replaced with events in the QP.

Dang blasted

Posted in Prototyping, Vision on May 28, 2012 by asteriondaedalus

First test run of OpenCV on Android had mixed results.

Compiled for Android 2.2, it was a no-go on the IDEOS but ran under 4.03 on both of the ACER A500 and the Samsung Galaxy SII.

Will need some debugging on my part as it appears no one has reported a similar problem, though it is known the OpenCV camera doesn’t work on Motorola phones.  The problem, I tried two apps, one with Android Java camera and one with OpenCV camera and both terminated after displaying camera image for approx. 1 second.

In the meantime, I am trialing some of the QualCOMM libraries since the Samsung Galaxy SII has the later version of the SnapDragon processor.

Now that’s what is needed!!

Posted in Arduino, Hardware, Locomotion, Prototyping on February 18, 2012 by asteriondaedalus


1-340x340

So, a Usurper!  I fiddled with the Films and will find something else for them to do.

This new board from DFRobotics is PERFECT for a Swashbot project.  I have one coming along with a XBee/USB board (you can see the XBee socket underneath.

So, will need to build gaits into board and pass sensor data back to laptop for moving around room.

crabful-swashbot

I will use larger servos as I am hoping the thang’ll carry a small android phone as well.  I have been playing with video streaming from android devices and so the field is open.

With 12 pwm outputs it can have a couple of extra servos with IR scanners, and with 8 analog inputs the IR scanners can be backed up with resistor whiskers for close in bumps.

There is also a prospect for some sort of animatronic bird chaser.  Pesky birds are eating the vegetables in the yard so something to flail and make noise when it detects motion close by.

Seek and you shall …

Posted in Agent, Arduino, Prototyping, Software on December 4, 2011 by asteriondaedalus

… well, find Seek.

A pivotal paper on avatar behaviors caught my attention (see here).

I started to look at pulling the basics out of the C++ templates and work it into basic behaviors for use on Arduino/Processing, then came across someone who had already “ported” it (see here).

Ideally then, ignoring the graphics and using “real” sensor input (rather than simulated) one should have a basic set of vehicular behaviors (running, say, on the Romeo) with the Jason app, running on the Android phone, selecting behaviors.

Work to go but things falling into one’s lap to spur one on what!

Actually!!

Posted in Chase That Dog!!, Prototyping, Software, Vision on December 3, 2011 by asteriondaedalus

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

Posted in Chase That Dog!!, Ground, Prototyping, Vision on December 3, 2011 by asteriondaedalus

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 😉

BroooMMMM!!

Posted in Arduino, Chase That Dog!!, Locomotion, Prototyping on July 24, 2011 by asteriondaedalus

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.