3-3. Basic Programming of the Android Controller/Camera

When I was trying to figure out what would be the brains of Porter, there were a few design considerations.

• Computer Vision processing - a 640x480 raw RGB image takes up about a MB of memory, so if I wanted to do some object recognition or tracking with it, that put most "microcontrollers" like the Arduino off-limits.
• Easily programmable - After poking around, I settled on Android as a platform OS, so I needed some hardware that had good support for Android.
• Small form factor - It needs to fit into a small form factor to provide flexibility for the chassis design.

Freescale wired up for use

I finally have settled for my initial prototype on using Freescale's i.MX53 single board microprocessor (Their quick start kit costs $149).   It's about the size of a smartphone, is beefy enough to handle the computer vision with 1GB of RAM, and has multiple USB ports. Freescale used to be Motorola semiconductor, so they have a lot of history and a good user community. Also, Adeneo makes a nice BSP port of Android for the i.MX53, with driver support for cameras, mice, etc.  

There are a few other comparable boards on the market, most notably the PandaBoard ($161) and the Raspberry Pi ($35), which I might end up using for the final production robot, but I felt that at this point in development, Freescale's community and maturity of the Android port were enough to go with them.

i.MX53 hooked up to VGA monitor

Why Android?

Some of you might question why I'm using Android as the platform OS for Porterbot.  Aside from my desire to eventually create a custom OS for truly parallel and intuitive robot processing, Android attracts me because of Java.  Why is Java important?  Why not program in C++, or better yet, in some "hot" old language like Python or Ruby?  Here are my personal and highly biased reasons.

• I've been using Java in my dayjob since 1997, so I'm inherently comfortable using it. 
• Java gets a bad rap these days by programmers wanting to be more efficient but it was never intended to be the ultimate programming language.   It was written by James Gosling for the same reason I would; because cross-compiling C++ code and makefiles with endless dependencies  makes my skin crawl. 
• I can create a robot DSL (domain specific language) in Groovy (a functional language wrapper around Java) and with a little bit of lifting, figure out how to make it work on Android.
• It would be nice to bring the robot community into the 21st century in a good way (not in a Nightmare on Elm Street way like Microsoft's Robot Developer Studio monster).

Anyway, Android is Google's take on Java, it's reasonably open source, and the developer community is very large. 

3-2. Research Motor Control Electronics and drive systems

in other words...  How will Porter climb stairs?

Porter robot will use a rocker-bogie suspension, which involves 6 and sometimes 8 wheel configurations.   

Illustrations by Jorg Roth

Perhaps more familiar is the rocker-bogie use in NASA's Mars Rover.

Courtesy of NASA JPL

In order to drive these wheels to turn, you need to apply rotational torque using motors.  

As mentioned in a previous blog, we use two types of motors in robotics - stepper and DC.  

In any case, I went ahead and did some research on stepper motors.  I found out that in order to control them, it's usually better to have a dedicated motor controller that will send the electrical pulses to the motor.  The motor controller will then communicate with the main controller when the main controller determines that movement needs to take place. 

For my initial Porter prototype I chose 4 Soyo Uni-polar 125 oz-inch stepper motors (from Robotshop) and a 4-motor Uni-polar motor controller (from Phidgets).

Phidget Motor Controller

The motors are 6 wire motors, with 3 wires for controlling each set of cores.  It was fairly straightforward hooking up the motors to the motor controller.  

Phidgets provides a lot of code for interfacing with their driver, so I was able to use their Java API to test that each of the 4 motors were running correctly. 

Soyo steppers connected to the Phidgets controller

I was able to easily control the speed, ramp up the acceleration, test rotating in the opposite direction, etc.  My only roadblock was discovering that the maximum velocity this specific controller was capable of handling was 383 half-steps a second.  

With a step being 1.8 degrees, this was roughly a revolution a second, which with a 2 or 3-inch radius wheel is going to be too slow for production purposes.  

I still intend to use these motors for my initial full prototype, but will have to look for a better alternative beyond that.  Phidgets sells a bi-polar motor controller capable of more speed, but it only controls one motor and is pricey at roughly $70 bucks.  


I did find a lot of useful information from the RepRap folks; stepper motors are used often in CNC milling machines for their precise control, so they have a plethora of information about stepper motor control theory.  

I think using that information it would be reasonably achievable to develop an in-house motor controller board for about $10/motor.