Redbot – Engineer On The Loose

Atmel AVR based robots, Redbot, 3pi, Zumo – getting the build environment ready

Jan 162014

Download and install a build environment

The Sparkfun Redbot, Pololu 3pi, and Pololu Zumo robots are all based on the Atmel atmega328p processor. All three have a wealth of libraries and supporting software. All three support at least the two most popular methods of creating code for the AVR processors, Arduino and avr-gcc (Windows and Linux). The two Pololu robots also support the Atmel Studio build environment.

Downloading and installing the Arduino environment is pretty straight forward. Download for your environment, unzip or untar, run. Not much more to it than that.

Atmel has taken over the support of the avr-gcc tool chain and hosts the builds for Windows and Linux. Installing the tool chains for Windows and Linux are documented on the Atmel site.

Get the supporting libraries

All three robots have additional supporting libraries; Arduino style for the Redbot and Zumo, Arduino, Atmel Studio, and straight avr-gcc style for the 3pi. Both vendors, Sparkfun and Pololu, provide links to download their libraries. Pololu supplies prebuilt installers for different versions of their libraries. Both companies also provide source on Github; Redbot / Zumo / 3pi. For the Zumo you want both the Zumo Shield library for Arduino programming and the libpololu-avr library for direct avr-gcc programming.

I prefer to go straight to the source and download the libraries fresh from Github. All of the libraries provide a “Download Zip” link to download a compressed bundle straight to your desktop. After you have the downloaded bundle you can uncompress and install it. I prefer to use GIT directly, under Windows and Linux, and clone the repositories directly to my desktop. Whichever method you use you will eventually have copy of the libraries on your local machine.

To clone the repositories locally under Windows I use the git bash shell from git-scm, under Linux I use git. If git is not installed on your flavor of Linux use your distro’s package manager to download and install it.

Install the libraries

The Redbot and Zumo Arduino libraries need to be installed where the Arduino environment can see them. Arduino provides tutorials on installing 3rd party libraries so I wont repeat that information here. Pololu also provides ample documentation on installing their libraries, for all three environments, Atmel Studio, Arduino, and raw avr-gcc.

For the Pololu 3pi robot I am using raw avr-gcc. The steps I used to install the Pololu libpololu-avr library are:

1 ) Insure you have the avr-gcc tools installed

From a command line run avr-gcc –version
If the program is found move forward, if not, return to installing the avr-gcc tool suite.

2 ) Build the Pololu Library

The Pololu library make file by default builds all of the flavors of AVR libraries for all of the Pololu products that use the library. For the 3pi you only need support for the 168 and 328p libraries.

New 3pi robots are based on the Atmel AVR 328p processor. Older 3pi robots were based on the 168 processor. The example program makefiles still reference the 168 library. At this point it is easiest to keep both the 168 and 328 libraries. Over time it makes sense to migrate to the 328, if you have a newer 3pi robot, but for the sake of expediency build both libraries for now.

Edit the libpololu-avr/Makefile and remove the building and installing of unneeded libraries.

In a command window in the libpololu-avr directory make the libpololu libraries. Simply type make in the libpololu-avr directory. The build process should eventually yield two files called libpololu_atmega168.a and libpololu_atmega328p.a. These are the 168 and 328p libraries containing the functionality provided by the Pololu library.

3 ) Copy the libraries and include files

Next you need to make the libraries and required include files visible to avr-gcc. You can either modify the example make files as you create or re-use code to point to your local versions of the pololu libraries and include files or you can copy the library and include files to the avr-gcc default path. Pololu recommends copying the files into the avr-gcc path.

See the pololu/libpololu-avr/README.txt file:
== Manual installation ==


If you have the source repository of the library instead of a binary

distribution, you will need to build the library (.a) files by running

"make" and also copy all the files in the "src" subfolder into the

"pololu" subfolder.
Next, copy libpololu_*.a into your avr-gcc "lib" subfolder.
Finally, copy the entire "pololu" subfolder into your avr-gcc

"include" subfolder.

You are now ready to use the Pololu AVR library.

Use the make show_prefix to discover the avr-gcc paths used in your install.

– Copy the library files, libpololu_atmega168.a and libpololu_atmega328p.a, into the avr-gcc lib directory.
– Copy the pololu directory, libpololu-avr/pololu, not just the files in pololu, the pololu directory and the contained files, into your avr-gcc include directory.
– Copy the contents, including any sub-directories, of the libpololu-avr/src directory, into the newly copied pololu directory in your avr-gcc/include path. In this case copy the “contents” of the src directory, not the src directory itself, into the avr-gcc/include/pololu directory.

Test your install and build the demo code

If all of the above worked you should be able to change into the libpololu-avr/examples_templates/3pi-demo-program and type make.

Now that you have a hex file you need to upload it to your robot.

I use avrdude directly from a command line. Using the Pololu AVR programmer the command looks like:

If everything worked cleanly you should have a fully functioning build and deployment environment ready to write new code.

Competitive Robotics – introduction

Robots No Responses »

Jan 092014

I’ve always been interested in competitive robotics. Two (or more) robots duking it out on the field of honor. Trying to solve a problem as fast or efficiently as possible, all the while trying to avoid, out score, or destroy the competitions robot.

Competitive robotics can generally be divided into to groups, direct combative and competitive problem solving. Both are a lot of fun, although combative can get pretty ugly, and expensive, in a hurry.

Competitive robotics puts a lot of pressure on developers and implementers to find optimal solutions in unstructured environments where other participants are actively trying to out score, block, or destroy your robot. You often need to come up with ad-hoc solutions in the middle of competitions to account for variations in the environment and to counter competitors robots.

Things we’ve had to overcome include changes in playing field surface, broken parts, changes in starting conditions, changes in competition rules that you don’t find out about until you get to the competition, and as always, differences in competitors robots that require you to adapt and modify your strategies on the fly.

In competitive robotics you push, pull, climb, and race to get the task at hand done before your competitor does. Changes in traction on different fields requires adapting your motion platform’s drive system. You can change your wheels, from slicks to diggers, or the other way round. Sometimes simply cleaning the tires, washing the dust and dirt off, improves traction enough to make a difference. Sometimes you need more. We’ve created studded tires by lacing plastic wire ties around the wheel and tire and cutting off the tails to leave the knobs pointing out. You do what you have to do to keep your robot moving and stop the competitors robot from moving.

Broken parts are always a bane. Hopefully you’ve built your robot to be maintainable. Motors die, drivers burn out, axles twist and break, screws fall out and pieces fall off. Broken parts require more an act of Nascar like pit crew skills than design changes. How fast can you swap out or adapt parts, under pressure in the middle of a competition, while maintaining a competitive robot. Sometimes you just work around the broken part, changing code to not use the broken functionality or adapting other sensors or actuators to try to work around the broken parts.

The four robot platforms I’m actively using are the

IFI Vex Robotics line,

Pololu’s Zumo Mini Sumo bot,

Pololu’s 3Pi,

and Sparkfun’s Redbot.

All of these platforms are extensible in various ways. Each of them have varying degrees of physical reconfigurability, with the VEX robot being the most physically reconfigurable, the Redbot next, then a toss up between the 3Pi and the Zumo (at the level of not much). All four platforms support adding sensors and of course full reprogrammability. The 3Pi, Zumo, and Redbot benefit from having the same microcontroller, the Atmel Atmega328p, and the same programming environment, Arduino or avr-gcc. The VEX controller is based on an ARM Cortex controller and uses the quite capable (but not free) RobotC development environment.

The VEX ARM processor arguably provides a much more powerful computing platform but is a more closed environment. The Redbot was designed to be modified with multiple sensor and actuator mount points and a fully open design. The 3Pi and Zumo have an open software development environment but suffer from a more closed hardware platform. Both the Zumo and 3Pi robots are able to be extended physically but not as simply as the Redbot or VEX robots.

The VEX robot, while powerful and benefiting from a reasonable line of accessories, is pretty much closed. The manufacturer, IFI, provides scant documentation on the VEX controller internals.

Each platform has different strengths and weaknesses.

The VEX line is expensive and relatively closed. The platform is physically very reconfigurable and being targeted at middle and high school students is pretty robust. The IFI provided sensors are mechanically robust and easy to interface. The downside of being targeted at students is the platform is not easily extended. IFI / RobotC provide few opportunities to step outside the bounds of the RobotC development environment. The upside is, it is harder for a student to get too far afield. The downside is, it is harder for a student to bring new innovations to the platform.

The Redbot line is fully open and extensible. The schematics, board layouts, and platform components are open and documented on Sparkfun’s website. The Redbot is probably the least robust physically. The Redbot is a great development platform but with an eye towards high extensibility and low cost it is probably at the highest risk of taking a catastrophic hit in a competition. That said the Redbot might be the best price to performance platform of the four. The Redbot’s size makes it too big to qualify for mini sumo competitions.

The 3Pi platform is hands down the best choice for line following competitions. It is pretty much designed to be fast and excel at line following. The 3Pi is low to the ground, is probably the fastest by far of the four robots mentioned here, and has a built in integrated line sensing array. The 3Pi platform provides for some extensibility. The 3Pi can be readily extended with sensors and other electronics but the motion platform is pretty fixed. Pololu sells a prototyping shield for adding sensors and other electronics. They also sell replacement motors with different gear ratios to achieve different speed to torque characteristics, but that is about it. Two wheel pivot steering with a caster is pretty much all you get. The 3Pi also requires a pretty clean and unobstructed field. The wheels are on the smaller side and not made for climbing or rough surfaces. If you are doing line following, maze solving, swarm bots, stuff that relies mostly on interesting software solutions and limited environmental interactions the 3Pi is the way to go.

The final robot I actively use is the Pololu Zumo. This bot is specifically a mini sumo pusher bot. Like the 3Pi, the Zumo is optimized for mini sumo competitions. Like the 3Pi the physical platform is not readily extended. The mini sumo rules limit the weight and footprint of the bot, so large physical changes to the bot are probably not in the cards anyhow. The Zumo allows for some sensor extension but the base platform with the sensor array consumes most of the available IO of the 328p microcontroller. Like the 3Pi the motors can be changed to achieve different gear ratios. Also similar to the 3Pi the Zumo relies on two motor slip skid steering. The Zumo is a tracked platform and has a pretty good grip but again like the 3Pi it requires a relatively smooth obstruction free playing field.

Each of these robots solves a different problem in a different way. For line following competitions and newer roboticists the 3Pi is the way to go. For mini sumo the Zumo is great platform. For the home hobbyist the Redbot is probably the best answer. For a more physically extensible and more powerful (and significantly more costly) platform the VEX line is the way to go.

In the end all of the robots are great solutions each with it’s individual strengths and weaknesses. Pick the one that best fits your style or target competition and go for it!

Here’s hoping to see your robot on the competition field.