Connecting the ArbotixM with the Raspberry Pi, part 2

Pew, I thought for a moment that the patient had died. My troubles with writing the bootloader for the ArbotiX continued and some how and I always got a to low result on the Pololu USB AVR ISP programmer.   I resorted to resetting the firmware to the same as it already reported 1.0.7 vaguely remembering that I probably did this before as that version came after I acquired the device to begin with.  But what seem to do the trick in the end was reversing the programming cable and suddenly every thing went smoother than ever before, no complaints, just a satisfying 'Done burning bootloader' from the Arduino IDE.  Yay, now I can hurriedly rush towards the next wall to run face first into.

So lets get blinky installed on the arbotix from the Raspberry Pi.  To avoid repeating all the build parameter for the target board model and the serial interface we add a ino.ini file with the following configuration.

board-model = arbotix
serial-port = /dev/ttyUSB0

Use the dmesg command to figure out where your serial interface ends up. This is also safer as now we don't have to remember to add the flags which could have sad result if we accidentally build a Uno target and try to send that to the ArbotiX.  Next we clean the previous build stuff to be sure we have the right.  As the documentation for ino is a bit light outside the getting started I resorted to looking up the commands directory in the python code that was a bit more forth coming.  I could verify that there is indeed a clean command and that it basically just wipes the .build folder that can easily be overlooked as it is hidden by default due to the . in front of the name.  So lets execute:

$ ino clean

Build again, relying on the ino.ini to set the board model and serial port to use.

$ ino build

Then we upload to the device.

$ ino upload

That produces lots of rapid green light blinking and finally a happy 'avrdude done. Thank you.' message in console and a steady blinking light on the arbotix.  Seems like the mission is a success. We have a successful upload of firmware from a Raspberry Pi using the USB FTDI serial interface to the ArbotiX robot controller using command line.

Before I declare victory I try out the serial communications and create a new empty ino sketch.

$ mkdir serios

$ cd serios

$ ino init

$ nano src/sketch.ino

paste the serial code from the ino getting started replacing all the contents.

void setup()
{
    Serial.begin(9600);
}

void loop()
{
    Serial.println(millis());
    delay(1000);
}

then I copy the ino.ini file from the blinky project over and build

$ cp ,,/blinky/ino.ini .

$ ino build

$ ino upload

Then I attempted to connect to the serial port using ino

$ ino serial

That failed as ino could not locate the picocom program it uses for the serial communications. Thankfully that was readily available via apt-get

$ sudo apt-get install picocom

After that things worked out better and I got a steady steam of millisecond readouts. Ctrl-A, Ctrl-X killed the session and normality was restored once more.

Next I will try to build the arbotix_ros firmware and see where that gets me. But that is a different story for later.

Connecting the ArbotixM with the Raspberry Pi, part 1

Right, so now I have an ArbotixM, Raspberry Pi B+ and a UartSBee V4 which is a USB XBee TTL interface that is essentially a FTDI interface with support for 3.3V and 5V logic.  Which is exactly what I need as the Raspberry Pi is a 3.3V device while the Arbotix is a 5V device preventing me from connecting directly without a level converter on the serial line.  I also happen to have an extra one lying around as I conveniently ordered two since two is always better than one.

We connect according to this guide from Trossen Robotics.



The diagram is replicated here for clarity.

We also replace the blink from my last post with the ArbotixM test blink. Which is effectively just swapping digital pin 13 (Arduino Uno) for pin 0 (ArbotixM).

Next we try to build the blinky for ArbotiX

$ ino build -m arbotix

This resulted in a error in arbotix/core/arbotix/HardwareSerial.cpp and arbotix/core/arbotix/Print.cpp.

After some googling it turns out that the definitions are out of date since the compiler has moved on and some definitions have been deprecated.  The follwing changes where made to the two files to overcome this.

Changes in HardwareSerial.cpp line 1.
+ #define __AVR_LIBC_DEPRECATED_ENABLE__

Changes in HardwareSerial.cpp lines 50-51
- volatile int head;

+ volatile unsigned int head;
- volatile int tail;

+ volatile unsigned int tail;

Changes in Print.cpp line 44
- const prog_char *p = (const prog_char *)ifsh;
+ const char PROGMEM *p = (const char PROGMEM *)ifsh;

Next I had to restore the bootloader of the ArbotixM as I had been directly programming in via ISP programmer interface from Pololu previously as I was using the XBee which occupied the serial port.
Also I didn't have the FTDI interface when I first got the ArbotixM due to an oversight.

This is where I hit a wall. The AVR ISP is not managing to write anything to the ArbotixM due to the minimum voltage being to low (> 400mV) which is very weird.  After lots of thrashing an unplugging and plugging and measuring the ArbotiX voltage and trying different power supply and whatnot the error transmuted into a communication error where no response is received but the min voltage is fine now.  I verified that the chip is still functioning by getting a serial response from the current program (written by the ISP) using the FTDI. Next I'm going to try to use avrdude directly from linux/raspberry to write the bootloader.

Arduino and Raspberry Pi via command line

Since I'm about to hook up an ArbotixM robot controller to a Raspberry Pi to control it with ROS, I needed to set up the tools to do that.  I'm avoiding the the raspberry desktop (which is quite fine mind you) for by robot and want to do it all via command line since so I can do this remotely via SSH.

Installing the 1.0 arduino environment for debian is just a matter of installing the debian package.

$ sudo apt-get install arduino

For the command line I found a very interesting set of tools called inotool.  To install that I did:

$ cd ~
$ mkdir repositories
$ cd repositories
$ git clone https://github.com/amperka/ino
$ sudo apt-get install python-setuptools
$ sudo easy_install pip
$ sudo pip install glob2
$ cd ino
$ sudo make install

there is a pip package available but it gave me issues later on when I wanted to add a new hardware board. More on that later.

Ino now allows me to create sketches, build, upload and communicate via serial.  Every thing the IDE would does for me. So to try that out do the following.

$ mkdir blinky 

$ cd blinky

$ ino init -t blink

$ ino build

$ ino unload

Immediately got me a blink program uploaded using a USB port connected Arduino UNO.  Ino actually makes educated guesses about what serial port to use and defaults to UNO. So far so good.

Since it isn't the UNO we want to program ultimately but an ArbotixM controller we need to add some magic to get that working for us.  First we need the arbotix hardware files for the arduino environment.  To be able to define additional board definitions with out adding the directly to the arduino install (which is bad manners) I had to switch to the git version as I noticed it was different from the pip package and able to deal with multiple directories.  It only searches in two places and on of the is the install directory and the other in /usr/local/share/arduiono.  So to get that set up I did the following.

$ git clone https://github.com/vanadiumlabs/arbotix

$ cd /usr/local/share/

$ sudo mkdir arduino

$ sudo cp -r ~/repositories/arbotix/hardware arduino/

The /usr/local/share/arduino folder should now contain hardware folder with an arbotix folder inside.

no we can build using the the arbotix target

$ cd ~/arduino_sketches/blinky

$ ino build -m arbotix

and we should end up with a nice arbotix blink program

Next lets test a serial program connected via a FTDI cable to the arbotix,  upload it and configure the ino.ini to make life easier.

LEGO Digital Designer goodness

While prowling the internet I found this wonderful LEGO build site.  I was drawn in by the LEGO Tachikoma from Ghost in the Shell anime series seen here which is motorized and multi functional to boot.  It has a walk and a drive mode which I find quite a feat for model of this size. You should check out the video.  He has a few other bad ass builds i.e. the Batman Tumbler.

What really made me happy was that we graciously includes a build file for the LEGO Digital Designer.  I have seen it mentioned but never really checked it out.  But having the actual build plan for a motorized Tachikoma pushed me over the edge so I downloaded the LDD app to check out the build.  After downloading the installer I took a while to fetch a bunch of data for all the brick sets. But that is actually quite cool since it implies that the get updated and I have all the latest bits.  Which is good since I recently got my son the EV3 set.

Loading the model in LDD shows a very clever drive train and the two, no three
motors that power this thing. The power pack seems to be crammed into the pilot capsule on the back.

Anyway as is so happens I had sitting on my desk a EV3 powered Nerf C-18 remote senty turret. That had been sitting there the last 3-4 months. Due to the rather complex construction nobody had dared tear the thing down yet.  But now I see that I can simply encode this creation of mine electronically and save the build for future use or to share with the world in hope for some improvements. And here we can see the first round of building.  This time the color is not constrained by the available pieces. You are looking at the tilt mechanism provided by two big turntable pieces and the seat of the Nerf C18 which is mouted upside down so the handle bar actually sits in the seat.  The turntables are then powered by a worm drive on either side as the C18 is a pretty big an heavy toy.  This is not the complete unit so don't read to much into it.  

Making a build from an existing model is fairly quick process and work alot more smooth than I had expected.  All the pieces snap to each other (with a sound) and the software makes a fairly good work at figuring out what I'm trying to connect to.  It is not with out fault though.  The automatic hinge connector has not worked for me yet for doing the angular cross beams. Probably "doing it wrong".

My 8 year old son was pretty quick to get going and was building a space thing in no time. We was pretty happy about being able to color things like he wants and the his main problem was controlling the view, some quirky brick attaching and finding the right piece in the rather large collection.  Pretty much the same as I had :) In a few short minutes we got this.

Extrusion success!!1! well, almost

I finally got some PLA to appear from the nozzle of my long awaited Sumpod.  It´s not much to look at but it proves that I can get plastic out of that thing.  But there are a few caveats still apart from the underwhelming amount extruded :)

I could not get the tip above 190°C with out shutting down the fan.  I did so for just a moment to get to 196°C.  I did not want to run it for much longer fearing that I will clog the whole this as other Sumpodders have experienced when running with the fan on.  It seem like I need a few degrees more with the PLA filament I have to get this working properly.  Another thing was that I fed the filament my hand through the teflon tube.

There are a few tricks I can try when I give it a go next time as it's to late right now for me to bother with any bravery.

1. Add more insulation
This will currently entail adding a bunch more kapton tape to the hot end.  I have 6mm roll I use for job. That should give me a bit more head room.

The long term plant is to use some fancy NASA tech in the form of an aerogel based insulation blanket called Pyrogel.  Which incidentally arrived on Friday.  That is a very dusty material with very fine particles aside from being quite expensive so I won't be doing that in a rush.  It will also be quite permanent after I seal as I'd rather not have dust spreading.

2. Regulate the fan
The extruder fan is running non stop on 12V and if I run it down a notch to decrease the amount of heat it's dissipating from the hot end.  I have a few options here and the simplest being to add a pot temporarily while I test the effect.  More fancy solution would be to add PWM to the firmware but I'd like to avoid that if possible.

That it for now

PCB etching in 30 minutes

Here is a very interesting PCB etching guide that is perfect for rapid prototyping.  I like how sparse the material usage is by using a sponge to apply the ferric chloride etchant and home much control you gain.  If my planned PCB milling adventures go nowhere (doesn't start well with the post office loosing my package of PCB engraving bits) this is what I´ll try next.  Heck, I might do it anyway since it's so quick.  Wonder how easy it is to do double sided boards with this technique.

The arrival of the Sumpod

It's finally here. I'll be posting more about my unpacking and assembly experience soon. For now you'll just have to admire the smaller than expected box of wonders.

I have already secured some primer and paint.  The color scheme will be white internals and navy blue externals. The paints are local brands.

This should keep me busy during the weekend :D