I’ve had the design for a while now but have been procrastinating and sat on it for a while.  That is until seeing how well an Ultimaker worked with its ducted fan attachment.

Jumping to the results, it actually works alot better!

• The models come off the supports really easily now <— This is the most noticeable
• ‘Undersides’ and supported surfaces are alot cleaner now
• There appears to be reduced warp, since the top layer is cooled down immediately after extrusion.

Off topic, but there is a duck in those photos… it looks a bit weird but its a prototype.  Plus the weird details like the screw thread attachment serves  well to show how cleanly the supports come off now (I only used my hands in all the photos below!  Seriously!)

The files for the OddBot Launchpad are supplementary to the OddBot and does not contain the 3D files for the wheels etc.

The files are located on Google Code :-

http://code.google.com/p/madox/source/browse/#svn%2Ftrunk%2Foddbot-launchpad

The code is written for mspgcc ‘Uniarch’ with a Makefile to install the program using Ubuntu + mspdebug.

This demonstration was mainly an exercise for me to familiarise myself with the msp430 LaunchPad + value line chips.  What little “documentation” there is exists in the comments of the oddbot-launchpad.c file.

As usual there is an imperfect demonstration video that goes with it (the rotate is in the wrong direction in the video) :-

So I got a freebie OddBot sent to me a couple of weeks ago, it basically is a derivative of my Mecanum Rover and Olaf was kind enough to sent it with almost everything attached less the Chumby.  Since I’ve been on a TI Launchpad buying spree, I thought I’ll tack one on in place of the Chumby to drive it.

So far this post reads like a gigantic spam with all those links…no enlargement links coming up, I promise…just one short video of it not working and running away on me.

So I figured, how hard can it be?  I procrastinated soldering 2 header pins onto the Launchpad’s TP1 and TP3 tie points for power but after doing that everything was almost recycling :-

Code – Copied from Madox Kart prototype code and original Rover code…took around 15-30 minutes to copy/paste and tidy up some comments.
Carrier for Launchpad + Battery +  Breadboard – Almost a direct copy of the Madox Kart prototype again… 15minutes to tweak and 1+ hour to print.  [Ok 3+ hours, 1+ hour on 0.4mm layers but 3+ hours on 0.2mm layers which I'm a sucker for].

Everything seemed ‘too easy’ so far, even the code compiled first time which I didn’t believe.  Then the problems started mounting…

Problem 1 – Cheap mini-USB cables from eBay failed to connect to the Launchpad properly.  Cable 1 was a complete no go (marked for butchering into a power cable), cable 2 worked only if the connector was held at a particular angle.  I programmed the Launchpad while keeping my hand steady holding the cable.  Cheap eBay USB cables, you disappoint me yet again.

Problem 2 – Connected everything up onto the breadboard and all, no blinky lights on the Launchpad!!!  Head scratch for a total of ~30 seconds.  It turns out it is the age old problem of ‘slightly too fat’ AA cells.  The AA cells are just a bit too wide for the battery holder and because of such, the friction between batteries was stronger than the spring and the + terminal wasn’t making contact.  Don’t know whether to blame this on the battery holder or the batteries…

Problem 3 – Continuous rotation servos were not zero’ed, and they were a pain to do so, the slightest adjustment movement will have it spinning the other way.  2 minutes later the zero’ing seems to have been gone, probably due to temperature drift (heating up) – PITA.

Problem 4 – My favorite – it didn’t work.  Initially because I didn’t pair the Wii Nunchuk (Duh! moment) and then probably down to the hackity software code  The movement matrices seemed wrong and the servo control was very odd, need to debug that later.  Highlight – IT RAN AWAY ON ME.  Best illustrated in video form :-

Problem 4.5 – The wheels haven’t been treated with Plasti-Dip or any other grippy surface, so its still very slippery…

I’ll upload the code etc when I get around to fixing it…

The idea is probably even plagiarised, I remember as a kid there was a woodworker/carpenters competition at said Darling Harbour where various companies were given a pile of wood and had to build a boat and race it in a limited time. There were awesome entries and there was the sheets of wood nailed together and fell apart as soon as it hit the water. Hilarity when the ‘losers’ swam and capsized almost everyone else.

Back to the Kart.

The idea is to build and race remote control karts (cars) around a course of obstacles and other fun things. There’ll be a set of rules and restrictions to make it challenging and fun.

That was the basic idea, with a potential spinoff that if we can aim for a low enough cost we can potentially produce a ‘kit’ that can be used for education to promote interest in electonics and Engineering.

The fork

I bounced this idea by the local hackerspace (Robots & Dinosaurs) here in Sydney and ended up with a mega thread of 144 replies so far. There are varying opinions on various items, for example how a ‘low cost’ solution might be ‘too hard’ and also confusion on who the target audience is.

So hence I propose a fork into two Karting Categories

Madox Kart – Educational

I am still very eager to create a platform that can be used for schools and keen parents to teach their kids about electronics/programming/general principles. The audience I had in mind for this is 12-16 year olds, say in high school where design/build/racing of the Kart can be built into the school curriculum. Does anyone remember or know about the ‘Mouse Trap Racers’ and ‘Rubber band Car’ competitions? Isn’t it about time we advance a little bit into electronics and build something a bit more complex? I think the Kart would be a great replacement.

To have it in a competition form provides positive motivation for the child to succeed. Who doesn’t want to win against their mates? Isn’t this alot more fun than reading out of a text book? Its interactive, its hands on and I think it should be good.

So this idea is currently at the ‘Design Challenge’ phase where I seek everyone’s opinions and ideas on how we can make this an open-source kit for children. The main driver for this would be affordability, with $25 for electronic components as my rough budget. Bonus items would include expandability (can the kit be reprogrammed or used again?) and ease of build (e.g. I’ll avoid any use of power tools).

Again a reminder, affordability is key. There will be some of us who will say ‘but it is only $1 more’ or ‘$10 is nothing’, please remember not everyone may be as fortunate as you and that amount of money may be significant to them. I want to provide the best ‘educational value’, performance is not the main theme.

Madox Kart – Hacker

Of course there are those of us who just wants to have a bit of fun and not let our creativity be constrained by tight budgets, thus creation of this new category for HACKERS. There will still be a set of rules and constraints to avoid overkill and competition domination just by money, so just throwing the idea out that its probably to put a dollar constraint on this one as well – say $100?

The possibilities for this one is that we can have build workshops at our local hackerspace to help each another and learn as well as having a bit of fun with competitions with prizes. If this gets off the floor, we can compete with neighbouring hackerspaces as well just to add a bit of friendly rivalry into the mix.

I very much like the idea of a ‘kart race’ over other forms of competitions like the robot wars type. It is less ‘violent’ for starters and may help to promote the public image of hackerspaces in a better light.

In closing, here is a rubber ducky…

Yup I originally wanted a remote control rubber duck race in Darling Harbour, somehow a ‘Madox-Kart’ seemed more practical…

I’m planning an ‘educational’ project currently code-named ‘Madox-Kart’ that I’ll get around to writing about, the summary is that it is a educational and fun project for kids to make programmable RC cars on the cheap (<$25) to teach electronics and 3D printing.  To test out the concept, I decided to make a prototype.

Prototype was ‘quick and dirty’ and looks something like :-

Madox Kart Prototype

It took a few hours to print because I printed at 0.2mm resolution and ‘fine’ as usual, in hindsight that is overkill for a quick prototype.  Mistake 1.  Don’t overkill on quality on a prototype.

Wheel printing in progress, at least I made it hollow...

Started modelling at around 8pm, the modelling was straight forward as was the printing so everything was printed by midnight.  Next comes the mistake, it is a BAD idea to code after midnight.  I had most of the code prepared as part of a previous run, with meticulously commented code.  Of course 1am me thought that code was bad and decided to ‘correct it’ – turns out it was the correction that was the bug and kept me debugging until 3am.  Mistake 2.  Avoid coding after midnight…  This and the fact that I wanted to play it safe and test with both a wired and wireless Wii Nunchuk, on the assumption that the wired would be easier and more reliable.  Of course I was wrong and the wired Nunchuk is/was probably defective.  Mistake 3.  Don’t assume things…

After sorting all that out I got lazy and instead of putting in the designed batteries, I slapped on a rather large LiPo battery with duct tape on the thing and tried it out.  This video shows the ‘ooops’ result.

Mistake 4.  Duct tape doesn’t really solve everything…

More lessons to be learnt next time!

The answers are typically ”I download it from Thingiverse…” or ”I model it up using CAD myself” (My answer), the first isn’t that fun and the latter might be too hard for the non-technical crowd.  However all is not lost, quite recently a few services have popped up that offer Photogammetry where you can upload a number of photos and back comes a 3D model.

There are a number of options but based off a chat while visiting Beehive Digital Manufacturing over the weekend I decided to give Autodesk’s Catch (was Photofly) another go so I can share the results on how easy it is to create a printable model.

Soldier Boy + Mini Soldier Boy + Micro Soldier Boy

First, find an object you want to create a model of…

I found that it was quite hard to find something that I wanted to create a 3D model of that isn’t copyright or inappropriate in some way, but in the end I found what I now call ‘Soldier Boy’ pictured below.  Soldier boy is a ‘piggy bank’ I got as a gift from a group of waitresses whilst on a business trip in China, and it appears generic enough not to infringe on any copyrights!  [PS : the other gift I got really was a pig...]

Once you have found the object of choice, you’ll need to place it somewhere where you can take photos of it from 360 degrees.   If you’re short of space indoors, you can take it outdoors like what I did :-

Place it where you can take photos from all around

 Second, take photos…lots of photos…

It is recommended that you set your camera to MANUAL FOCUS such that focus doesn’t change between shots, this helps the photogammetry algorithms.  Take photos all around the object, say 20 photos for 360 degrees.  Take note that unless you want the top of the head to be a gaping hole, it doesn’t hurt to take another round of photos (say 20 more) from a higher angle.

Take photos all around, taking care to cover the 'top' if required

I took 50 photos for soldier boy, with extra shots from a low angle to capture features such as his bags and pockets.

Then… Upload them to Photofly/Autodesk Catch…

Presuming you have the program already installed, it is really as simple as selecting all the photos you’ve taken and hitting an upload button.  There are some quirks with the program, mine crashed on the first attempt but retrying worked.

And then…

You should get your ‘scene’ back to be opened using the ‘Scene Editor’.

Scene Creator

The scene editor allows you to preview your model, with some tools to tweak here and there.  It shows you a textured model, and the positions it thinks you’ve taken the photos from.  Assuming all is well, you shouldn’t need to edit any stitch points.

You can see how each photo contributes to your scene

What is useful in the scene creator is removing obvious artifacts from the model, I ended up getting some extra fence spikes as well as the spike underneath his feet.  Removal is easy, use the lasso select tool to select the parts you don’t want and hit delete.

Removing unwanted artifacts

Artifact gone!

Give your mesh a quick look over to see if the quality is good enough for you.  There are 3 quality levels to choose from :- Mobile, Standard and Maximum.  The mesh I ended up with looked good enough so there wasn’t a need for me to bump it up to 11.

Check the mesh quality is suitable for you

Now you can export that as an OBJ file!

And then…

For no reason than ‘because I can’, I opened the OBJ with its texture files in Meshlab to see that it all exported properly…

Meshlab shows the model all pretty too...

But but but… there are holes in it!

Because I couldn’t take photos of the underside of its feet, the mesh is non-manifold and there are these humongous holes under his feet!

Humongous holes...and the feet are still joined...

So the mesh isn’t perfect and that’s where Meshmixer comes in.  Opening the model in Meshmixer helpfully shows and highlights the problem areas with a big blue/red outline as you can see above.  Removing the hole was simple, Meshmixer has a tool called ‘Erase & Fill’ where it will delete off selected portions and fill it in to make a solid.  i.e. you need to select around the edge/bottom part of the shoes, delete and it will fill it in.  You’ll need to edit the tool because the default fill is a huge ‘bulb’/'balloon’.

There are some other useful tools in meshmixer such as the smooth tool to smooth out bumps that might appear here and there but once the model is ‘solid’ it is ready for print.  Meshmixer lets you export direct to STL and its straight to the printer!

To the printer!

I took a video of my prints, but I’m too lazy to edit/upload them so photos only below.  There was an issue with my printer I haven’t seen for a year that caused some artifacts in the prints, but glad I’ve finally figured it out what the problem is and shouldn’t happen next time…

All in all the models that came out look pretty good.  With the photos + uploading + cleaning up, it took perhaps an hour (Autodesk Catch crashed once, Meshmixer crashed thrice…) so it isn’t all that time consuming.  Should be alot quicker now that I’ve got the hang of it too [Meshmixer isn't very intuitive to use...]

Cute isn't she?

The Python script generates squares and circles for each pixel in a photo, I was targeting Ponoko‘s P2 size so planned for 64×64 pixel images at approximately 6mm per pixel.  The above shows an ‘inverted’ generation where the lighter colours generate a cutout, this is intended for light being projected through it onto a surface.  Was hoping to use the sun for best effect but just used a cheap Ikea lamp to take the above photo.

The normal generation is where darker colours generate a cutout, intended for placing the cutout on top of a coloured background.  In the photo below, the background is my table tennis table.

I barely unpacked the stuff from Ponoko before taking those photos so still need a bit of clean up (some ‘holes’ still have the cardboard attached) but overall I’m happy with the result!  In case anyone is wondering, the ‘square’ cutouts are much cheaper than the circular ones based on Ponoko pricing and achieve the same result.

The script source can be found at at the link below, feel free to share.

Script source : http://code.google.com/p/madox/source/browse/trunk/misc/im2svg.py

Edit : New picture using day (Sun) lighting

However if you ARE interested in buying one, feel free to buzz me by email to : madox dot net at gmail dot com , and I’ll see if I can get you a good deal

I found mjpg-streamer but it wasn’t quite right -

• I had to compile (cross-compile!) it each time I wanted to use it (hard to share…)
• I couldn’t embed it easily with existing programs (to share same http port) etc.
• It seemed to use a lot of CPU when it had to compress the images using libjpeg

So I decided to ‘Google’ around and look for a V4L2 binding for Python and couldn’t seem to find anything… only did I realize Pygame has this inbuilt already but no one seems to mention it!  So to keep things short, here it is :-

http://code.google.com/p/madox/source/browse/trunk/webcam_stream/webcam_stream.py

• http://<ipaddress>:8080/GetStream – This gets you the multipart/jpeg stream
• http://<ipaddress>:8080/GetImage – This gets you a single image
• http://<ipaddress>:8080/JSImage – This uses the single image interface and gets the images as fast as it can via JavaScript

Framerates, ports (default 8080 in above examples), resolutions are in the source file for you to customize – go for it.

Converting from RGB565 (to PNG)

ffmpeg -vcodec rawvideo -f rawvideo -pix_fmt rgb565 -s 320x240 -i image.raw -f image2 -vcodec png image.png

Converting to RGB565 (from PNG)

ffmpeg -vcodec png -i image.png -vcodec rawvideo -f rawvideo -pix_fmt rgb565 image.raw

Now I have custom Chumby boot screens! [Yeah wasn't doing it for Android this time...]