The beauty of the Arduino lies in its simplicity. A look under the covers of the Arduino and its IDE, however, reveals a fascinating chipset and an open, extensive toolchain.
From A to Z with the AVR
The MCU on the Arduino is an 8-bit RISC chip called the AVR. I’ll get to the Arduino component of the chip shortly (hint: the bootloader plays a big role), but first, let’s focus on what happens from programming on a computer to executing the program on the AVR. While there’s an 8-bit AVR and 32-bit AVR variety, we’ll assume 8-bit for this post.
Overview of the AVR toolchain
One reason for the popularity of the AVR is the free (as in beer and speech) toolchain. At the second highest level of this toolchain is the compiler: AVR-GCC. AVR-GCC converts C code into assembly language files. Although AVR-GCC compiles C, it’s basic C, which means referencing registers by memory address, lack of floating-point support, and so forth.
Luckily AVR-GCC is only the second highest level; at the top of the toolchain is the AVR Libc. This is the C library all AVR programs use. The library takes care of naming all the registers, supporting floating-point, adding helpful AVR-macros, and plenty more. The AVR Libc library can be included with:
#include <avr/io.h>
After writing C code that references the AVR Libc library, AVR-GCC compiles the code into individual assembly files, which the Assembler turns into object files (files in a format runnable by the AVR), the linker then combines the multiple object files into a single object file that, finally, is converted into a HEX file. Whoa, let’s take a breather.
…and breather over. The resulting file after this compile process is an Intel formatted HEX file. This HEX file is the executable instructions and, once uploaded to the AVR, will be processed as is.
How do we upload the HEX file to the AVR? An 8-bit AVR by itself cannot communicate over the USB protocol. An In-System Programmer connects from the computer (via USB or Serial port) to the AVR. When starting the upload, the programmer activates the AVR’s reset pin, which puts the microcontroller in Programming mode. Once in Programming mode, the AVR can accept the instructions from the programmer, which allows for writing the file to the AVR’s flash memory.
In-System Programmer for the AVR
The final piece of the AVR toolchain is AVRDUDE, a command line utility that sends the compiled code to the In-System Programmer or Development board for execution.
The Arduino
The AVR has up to 2KB of flash memory dedicated to a bootloader, a special region of memory that always executes after a reset. A bootloader combined with the AVR’s ability to write to its own flash memory allows the AVR to program itself over serial. Yep, a bootloader negates the need for the In-System Programmers and Development boards, requiring only a simple serial connection to the computer to program it. The bootloader can perform this serial programming by listening to the Tx/Rx (transmit and receive) lines on the AVR and write the instructions it receives to memory.
The Arduino comes with such a bootloader burned onto the AVR chip. See, even though a bootloader allows for programming via a serial connection, the bootloader itself needs to be programmed into the board initially using an In-System Programmer.
While any serial connection should work with the AVR chip and the bootloader, most Arduinos contain a USB interface. USB’s protocol is different than the simple serial protocol the AVR expects. Instead of doing the conversion on the AVR, a separate chip converts from USB to serial. On boards like the Duemilanove and earlier, this was an FTDI chip. On boards starting with the Uno, an Atmega8U2 is used to convert USB to serial. This 8U2 is more capable than the FTDI chip, allowing for the Arduino to broadcast itself as other devices, like a USB keyboard.
The (optional!) Arduino IDE
The Arduino IDE actually uses the same AVR toolchain described earlier. The IDE hides the complexity and presents a simple interface to the user.
But guess what? Any plain old text editor or IDE can be used to program the Arduino. Since the brain of the Arduino is simply the AVR chip with a booatloader, the exact same toolchain described in the AVR section can be used. AVRDUDE even comes with presets for dealing with the Arduino bootloader.
In addition to wrapping up the toolcahin, the Arduino IDE also includes useful C libraries that build on top of AVR Libc. The libraries included with each program can be found in the hardware/cores/arduino directory of the IDE.
My TurtleBot arrived! I pre-ordered the robot from Clearpath Robotics in June and their robotsmiths sent it out last week. I’m ecstatic.
Wait, what’s a TurtleBot?
The TurtleBot is a robot consisting of an iRobot Create (a Roomba, without the vacuum), a Kinect, a gyro sensor, and a netbook computer.
The TurtleBot represents the most advanced and complete robot platform to reach the thousand-dollar price point yet. While all the components of the TurtleBot have been available for almost a year, the TurtleBot platform brings everything together in one standard package.
The creators of the TurtleBot are also the maintainers of the Robot Operating System (ROS), which the TurtleBot runs. ROS is a popular, extensible collection of libraries and tools for robotics. The beauty of ROS is anyone can contribute a package for it. Need the ability to interpret Kinect sensor data? There’s a package for that. Looking for an algorithm to intelligently navigate a room? Yep, there’s a package for that.
The TurtleBot arrived, now what?
Assembling
I’m going to assume the TurtleBot arrived fully assembled with ROS installed. If a TurtleBot kit was ordered instead, the documentation includes detailed instructions on assembling and the ROS TurtleBot page contains TurtleBot-specific ROS installation.
However, even an assembled TurtleBot requires a few extra build instructions before beginning.
First, the gyro sensor must be connected to the Create, as pictured. The gyro sensor aids in providing better odometry to the robot. In other words, the sensor provides more accurate sense of direction and speed.
USB cannot supply the 12V the Kinect requires. The TurtleBot includes an adapter cable that splits the Kinect cable into a USB adapter and a power adapter. The power adapter connects to the gyro sensor and draws its power from the Create.
Gyro sensor/Power adapter. Black cable is the Kinect power cable.
Finally, while tempting to leave the netbook open on top of the robot, be sure to secure it! The TurtleBot can jitter when being teleoperated, which will cause the laptop to fall off the top. Secure the netbook to the top (bungee cords? velcro? I’m open to suggestions) or leave the computer snug in the bottom deck.
Netbook snug in bottom deck.
Network Configuration
When logging in to the TurtleBot netbook the TurtleBot stack will start up in the background. The network will need to be configured the first time logging into the laptop as most interaction with the robot will happen over SSH from the workstation.
Before continuing any further, change the default passwords. Seriously, someone will SSH into the robot at the least opportune time. Treat the robot like any server and secure it.
The following instructions will change the password for the turtlebot user and root user.
# Changes the password for the user turtlebot
passwd
# Changes the password for root
sudo passwd
To test the network configuration, SSH from the workstation into the netbook. ROS does not have to be installed on the workstation for SSH-only sessions.
# SSH into the TurtleBot# The IP address of the TurtleBot can be found using ifconfig
ssh turtlebot@10.0.1.18
Run an “app”
Okay, the boring stuff is over, time to get the TurtleBot to do something. A simple app to start with is the Keyboard Teleoperation app, which allows the TurtleBot to be controlled by the workstation’s keyboard. To begin, run the keyboard_teleop.launch in the SSH shell:
roslaunch turtlebot_teleop keyboard_teleop.launch
Now, pressing the arrow keys from the workstation should move the robot forward or backward, or turn left or right.
What does roslaunch do? Well, ROS is based on the idea of connecting separate, specialized programs called nodes. One node can process data from a Kinect while another node computes a navigation route. A launch file is an XML file describing which nodes to run. Roslaunch reads in the launch file and executes the nodes with any specified parameters.
For example, keyboard_teleop.launch sets the velocity of the TurtleBot and listens to the keyboard for direction instructions (referenced as cmd_vel in the file).
Most of the TurtleBot “apps” are launch files and their associated nodes. Running these apps is a matter of running roslaunch on the launch file.
Where to go from here?
There are more advanced apps ready to play with on the TurtleBot. Following the Network Setup and Bring Up tutorials will be necessary before running the advanced apps.
The gmapping app creates a 3D map of the robot’s environment. It may look simple from videos, but actually navigating the TurtleBot around and seeing it update the map in real-time is nerdtastic. The Gmapping app also serves as an excellent introduction to the SLAM technique, which helps a robot understand its surroundings.
A list of apps configured for the TurtleBot are available on the TurtleBot wiki.
Digging deeper into the robot’s capabilities will involve digging into the Robot Operating System. Luckily, ROS has exceptional documentation, including a start guide and tutorials covering developing for ROS.
What if I have a question?
The first place I recommend for support is the TurtleBot wiki pages on ros.org. The answer may be a couple links in, or simply be a matter of re-reading the instructions (which has helped me a few times already).
If you need to ask a question, answers.ros.org is a Stack Overflow-like Q&A site with many knowledgeable and friendly roboticists.
Organizers of the Open Hardware Summit. Images by Bill Ward.
It was a big week for the open source hardware movement, starting with the first conference dedicated to open hardware: the Open Hardware Summit. Yep, a conference just for open hardware. And it sold out. Big name presenters in the rather nascent field include Limor Fried of Adafruit, Chris Anderson of DIYdrones, Massimo Banzi of Arduino, and Bunnie Huang of Chumby. The OHS was followed by the New York Maker Faire.
While plenty happened, two big announcements were new Arduino boards and an updated draft for the Open Source Hardware (OSHW) Definition.
New Arduino boards
Arduino Uno
Massimo and the rest of the Arduino team announced the successor to the Duemilanove: the Uno. The Uno and the more recent Duemilanoves share the same ATmega328 chip with 32 KB of flash memory (for storing programs), 2 KB of SRAM (for storing variables), and 1 KB of EEPROM (for storing “long-term” data). The Uno is also FCC certified, opening the door for using the Arduino in new fields with regulation requirements.
The biggest change is a new USB-to-Serial chip. When you plug an Arduino into the computer using a USB cable, the computer sees the Arduino as a serial device. This allows sending commands and getting feedback between the computer and the Arduino. The previous chip — the FTDI FT232RL — has been replaced with the Atmel Atmega8u2 chip. Before, the computer only saw the Arduino as a serial device, with the Atmega8u2 the computer can see the Arduino as a keyboard, or a mouse, or whatever the developer decides.
The flagship Arduino — the Mega — was also updated to the Mega 2560. The ATmega2560 chip used in the Meaga 2560 has 256 KB of flash memory, twice that of the Mega while keeping the same size of SRAM and EEPROM. The Mega 2560 also uses the Atmega8u2 USB-to-Serial chip found in the Uno.
Though capable of speeds up to 20 Mhz, both the Uno and the Mega 2560 remain calibrated at the previous speed of 16 Mhz.
Updated Open Source Hardware Draft Definition
Discussing the Open Source Hardware Definition.
Back in July, several news outlets reported OSHW ratified a constitution. What was agreed upon was version 0.3 of the definition of Open Source Hardware by several players in the community. While ratified, the definition/license is still evolving, as Bunnie Huang described in his post.
Version 0.4 came out during the week with some minor changes and clarifications. These changes include:
Adding a Scope criteria specifying what part of the hardware falls under the license
Preferring native file formats as documentation, for example, the CAD files over a PNG
Requiring sufficient documentation on how to interface with the hardware in software
Honestly, when I started this post, I was expecting more changes between the drafts. Diffing the two definitions showed otherwise. Oh well, that’s a good sign there’s still a general consensus.
To the future
The Open Hardware Summit was the culmination of the growing OSHW movement. Yet the summit is just the beginning. There’s a strong community of hardware hackers, not only online, but in your city. Hackerspaces are forming, meetups are starting, and the local community is growing. It’s an exciting time to get started!
