The base platform is an MMP-5 from themachinelab.com. The motherboard is a TS-7350 from embeddedarm.com (Technologic Systems), with SD-card storage. Location is (hopefully someday) determined by on-board GPS using the SiRF III chipset, from sparkfun.com. Obstacle avoidance is achieved by using ultrasonic sensors; the current heading is obtained from a solid-state compass, both of which are also from sparkfun. The communication is done via Wifi, using a Zydas chipset module from IOGear. Many of these parts are routed through a small breadboard mounted to the robot.
MMP-5
These parts are what make ReCA a robot, and not simply a small computer. The user guide for the base platform has been a broken link for quite some time now. If one can get their hands on this documentation, two things need to be done to the platform. There are some switches inside that should be set for the MMP-5 to accept serial data, as opposed to its other pulse-width modulation (PWM) mode. It is important to note that this is a TTL serial connection, not the standard 12 volt RS232. We also power the rest of the robot off the batteries of the MMP-5, so one will need to bring this out with a couple of wires. These leads should read about 12 volts. In total, coming from the platform should be the two wires for power, one three-wire lead for motor control, and one three-wire lead which now does nothing.
TS-7350
This part is the computer. It runs Debian Linux on an SD card. The processor is an EP9302 ARM core. It is supplied with 12 volts by the two power leads from the MMP-5. Be very careful not to reverse the polarity of the wires powering this board. The TS-7350 CANNOT handle this! When it is powered, it in turn provides 5 volts for the breadboard on the JTAG header's pin 15, which powers the rangefinders and compass. The picture below shows where the connections are for power and signals. The motors are connected to the transmit pin of a TTL serial port, at pin A12 of the PC-104 connector. It is important to note here that PC-104 stacking functionality is disabled in favor of being able to use this, and also that only the transmit pin needs to be connected. The motors do not send any information back to the computer. The rangefinders are plugged into the COM2 header, and are described in more detail below. There is an I2C bus which, for now, only has the compass on it. I2C is a two-wire bus capable of supporting more than a hundred other devices, so this would be a good place for expansion. The I2C SDA, or signal, pin is pin 18 on the DIO header, and the SCL clock pin is on pin 16 of the DIO header. These could be changed possibly, or another bus added, but it would require changes to the EP9302 I2C driver. Additional information about the board is available here.
Rangefinders
These were one of the easier parts to get working in a reliable manner. This schematic came from a similar one on the trossenrobotics.com forum. In fact, our requirements were even simpler. The trigger is connected to the transmit pin of the COM2 serial port, and the data returns to the receive pin. These sensors can be chained together as in the schematic below, and there is no reason to stop at three, though we have for the time being. The trigger is simply any data, or really any signal at all, and the sensors each in turn send a byte back. This byte is the distance in inches, from the maximum distance which is 255 inches, down to 6 inches.
Compass
Although the compass was incredibly difficult to get working, this was due to it being an I?C device. The circuitry is simple enough not to warrant a schematic. It's just two wires, one for the clock signal, one for the data signal. Like the rangefinders, the compass is powered by the breadboard, and once it's on the wiring is done.
GPS
This is simply a USB GPS device. It seems to require more work than should be necessary. It just doesn't work.
Wifi
Again, a simple USB device. Again, more trouble than it's worth. This one actually works though, which is a plus.
Software
The software which the ReCA robots run is all contained on an SD card which goes into the appropriate slot on the main TS-7350 board. This card contains a full Debian Linux system, the setup of which is similar to the SD card setup for TS-7390 duplicated on this site from ted.openavr.org. Perhaps the most major difference from these instructions is the fact that we build our own kernel.
Cross-Compiler
The TS-7350 has a 200 MHz ARM9 CPU. For our end purposes, it's blazing fast, but it would probably take a whole day to compile large programs (such as the Linux kernel) on it. Because of this, we use a cross-compiler to build the kernel on a faster x86-architecture computer. Technologic Systems provides two cross-compilers, and a description of the difference, here.
Kernel
One can get our kernel off an SD-card which is already set up. The procedure is similar to step 10 of the SD card setup for TS-7390, except that the arguments are reversed. Basically, one would use the dd command to copy from the block device representing the second partition on the SD-card, where the kernel is stored for a TS-7350. The output file will be an image of this partition, suitable for copying back onto another properly partitioned SD-card. Usage of the dd program is more thoroughly covered in its manual page.
The other way to get a kernel for one of our robots is to compile it. We used the sources for a 2.6.21-ts kernel, which is available here. We used the EABI cross-compiler to build our kernel, so the first thing to do after decompressing the sources is to edit the Makefile for the kernel, and set the CROSS_COMPILE variable to what it should be. For me, this line looks like:
CROSS_COMPILE ?= /opt/crosstool/gcc-2005q3-glibc-2.3.5/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-
e use a cross-compiler to build the kernel on a faster x86-architecture computer. Technologic Systems provides two cross-compilers, and a description of the difference, here.
Kernel
One can get our kernel off an SD-card which is already set up. The procedure is similar to step 10 of the SD card setup for TS-7390, except that the arguments are reversed. Basically, one would use the dd command to copy from the block device representing the second partition on the SD-card, where the kernel is stored for a TS-7350. The output file will be an image of this partition, suitable for copying back onto another properly partitioned SD-card. Usage of the dd program is more thoroughly covered in its manual page.
The other way to get a kernel for one of our robots is to compile it. We used the sources for a 2.6.21-ts kernel, which is available here. We used the EABI cross-compiler to build our kernel, so the first thing to do after decompressing the sources is to edit the Makefile for the kernel, and set the CROSS_COMPILE variable to what it should be. For me, this line looks like:
CROSS_COMPILE ?= /opt/crosstool/gcc-2005q3-glibc-2.3.5/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-
The next thing to do is apply the patches for I??C functionality. There is quite a story behind these patches. They were incredibly difficult to find, but you should be able to get them here or in your own copy of the ReCA code. They are applied like so from within the base kernel source directory:
patch -p1 < ep93xx-i2c.patch
patch -p1 < i2c-bus-ep93xx.patch
Finally, at the time of this writing, the sources do not seem to compile on Ubuntu anymore without a minor change. You will have to edit scripts/mod/sumversion.c and add #include <limits.h> somewhere at the top. A quick look at this file should make it apparent where this goes. You should now be ready to configure and compile the kernel. The first thing to do is configure the sources:
make ts7350_defconfig
make menuconfig
These two commands will first initialize the sources to the defaults for the TS-7350, and then display text menu for kernel configuration. If you are new to configuring kernels, don't panic. It's not as bad as it sounds. If menuconfig fails to run, please check the error messages (starting at the top, always a good rule of thumb) and fix one of two problems I can think of. The first common problem at this point is, your terminal is too small, in which case a simple resizing of the window should make everything good to go. The second problem is that the ncurses library is not installed, which is needed for the text menu. You can either install the ncurses development package appropriate for your distribution, or edit the file ".config" directly. I suggest and will document assuming you have picked the former solution.
Once menuconfig is running, select Device Drivers > I2C support > I2C Hardware Bus support > Cirrus Logic EP93XX GPIO-based I2C interface and enable it (I suggest setting it to be a module). Then navigate your way back to the first screen and go to Boot options > Default kernel command string. Change this string to look like:
root=/dev/ram0 rw init=/linuxrc lpj=498688 console=ttyAM1,115200
Finally, run make and wait. When it is done, you should have a kernel ready for use with dd and your SD-card at arch/arm/boot/zImage.
UARTS
The various UARTs should be available after loading the xuart7350.ko module from the embeddedarm.com ftp site.
The Team
The project was led by Dr. Suranga Hettiarachchi. The original ReCA robot was built in Spring 2008 by students in a class Dr. Hettiarachchi taught. This team included Josh Gray, Lyle Henderson, Brad Nelson, and Tim Willey. Work was later continued by Eli Cohen and Adam Sullivan.