I’m still not quite done with all of the updates for my robot—most notably the wheels. I’ve actually run into a little trouble: the wheels I was intending to use are actually too good at sticking to the ground to turn easily—the rubber tires fall off every once in a while. To solve this, I’m planning to use some omniwheels for the front, which should convert the drive system from four drive wheels to only two, and thus reduce the shearing force on the wheels.
Over the summer, I’ve been working on restructuring much of the robot—both to reduce its physical size and to reduce its power requirements.
A short (and incomplete) list of changes:
- Switch from old laptop motherboard to an Artigo pico-itx computer
- Move the Kinect down—empirical data shows that it does not need to be placed very high to get useful readings
- Elevate the base (by using bigger wheels): I’ve had troubles getting over bumps due to low ground clearance
- Change microcontrollers from an ATMega328P to a ATMega2560
- Add an LCD for quick feedback on important things like battery voltage and motor speed
Source code is available for download—there’s a Git repository at tpmo.im/robot.git.
git clone git://tpmo.im/robot.git
Alternatively, browse the repository over the internet here
I’ve been playing around with this design for about a week. Tell me what you think about it?
One of the things programmers tend to learn how to do in every language they know is how to write a quine – that is, a program that echoes its own source code out to the user, without reading the source code directly. This is an inherently recursive operation, so language-based tricks are needed to get it to work.
The Arduino is programmed in C++, however, there is no std::cout. Instead, user input is usually through the USART on the Arduino, and as such needs to initialize and print out from that port.
Traditionally, C/C++ quines are written using the preprocessor and the printf command, as it allows for simple replacement of strings with characters, thereby overcoming the recursive operation. As such, I use the sprintf command below (Arduino’s HardwareSerial doesn’t support formatted prints, sadly enough).
So I finally got around to taking some pics of the robot (as it is now):
In the course of making a to-be-revealed robot, I’ve encountered problems with various FTDI cables (and their attached peripherals) being automatically mounted in different locations, depending on the order in which they were inserted and initialized. For obvious reasons, this poses an issue – the IMU cable won’t work well with motor commands, and the actuator controller doesn’t give any IMU data.
After some thinking, I decided to solve the problem via udev mounting (somewhat hackish). In Linux, udev controls the mounting of various hardware peripherals to mountpoints in the file system. This tutorial is written for Ubuntu 10.10, but could easily be translated to any distribution of Linux (and probably Mac OS X, as well).
Read more on Mapping FTDI to files with udev…
I’ve been working on a new robot of late, taking the controller and parts from the older one and placing them into a new chassis and system. Lacking time to work on a new h-bridge circuit, I’m actually using an Ardomoto shield from SparkFun, which takes care of most of the wiring for me, and also uses a more powerful L298 h-bridge. If you look carefully, you’ll see one of my breadboard Arduinos in there, it’s currently only there to interpret the Nunchuk readings and to control the RGB LEDs in front. In the future, it’ll be used for the PID control, which I have yet to implement. It’s connected to the main Arduino Mega clone with I2C, running at 100KHz.
I’ve burnt out a few Arduinos recently, and have found it expedient to just build my own on a breadboard rather than pay $34.95 and buy an Arduino Duemilanove online. It’s cheaper ($7.40, without FTDI or breadboard, SparkFun), and easy to fix if something goes wrong. Note that this tutorial does NOT include a voltage regulator, power will come from the FTDI board.
Parts List (minimum, of course):
- 170 tie point breadboard ($3.95)
- ATMega328P w/ Arduino Bootloader ($5.50)
- 16mhz resonator ($0.95)
- 10 kOhm resistor ($0.25)
- 100uF Capacitor ($0.35)
- SparkFun 5v FTDI Breakout ($14.95)
- Assorted wires ($0.00, you can pull them from anything)
- [optional] LED, for pin 13. ($0.35)
All prices are from SparkFun, which is NOT the cheapest. Note that the capacitor and the SparkFun FTDI can be reused across many boards, and thus the costs is divided among all the boards you build.
Read more on Poor Man’s Breadboard Arduino…
The game robo.hack is the result of the last month’s worth of coding by myself, Karthik Viswanthan, and Virup Gubba. It is based on nethack, and should be relatively easy to learn.