Autonomous Exploratory Robot System

Home > Design Progress:

Interface Design:

Below is an overhead diagram of what kind of interface we wish to create:

Here, the Brainstem GP is being used for its extensive connection abilities, having a 1MB I2C bus as well as an RS232TTL port. Both the Brainstem Moto and the Devantech CMPS04 Compass can be interfaced to the Brainstem via I2C Bus addressing. A simple tutorial for programming the Brainstem to use I2C can be found at: http://www.acroname.com/robotics/info/examples/srf10-1/srf10-1.html.

The following diagram from that link shows the simplicity of the 4 pin I2C interface.

Any further additions to the I2C bus involves simply assigning addresses to each device. So you may be asking, what is I2C? I2C is an acronym for Inter Integrated Circuit bus. I2C is a 2-wire serial interface standard defined by Philips Semiconductor in the early 1980's. It's purpose was to provide an easy way to connect a CPU to peripheral chips in a TV-set. The BUS physically consists of 2 active wires and a ground connection. The active wires, SDA and SCL, are both bidirectional. Where SDA is the Serial DAta line and SCL is the Serial CLock line. An excellent primer is http://i2c-bus.org/

The key advantage of this interface is that only two lines (clock and data) are required for full duplexed communication between multiple devices. The interface typically runs at a fairly low speed (100kHz to 400kHz). With I2C, each IC on the bus has a unique address. Chips can act as a receiver and/or transmitter depending on it's functionality.

The I²C-bus is devoloped by Philips to maximize hardware efficiency and circuit siplicity. The I2C interface is a simple master/slave type interface. Simplicity of the I²C system is primarily due to the bidirectional 2-wire design, a serial data line (SDA) and serial clock line (SCL), and to the protocol format. Bi-directional communication is facilitated through the use of wire and connection (the lines are either active-low or passive high). The clock is always generated by the master, but the slave may hold it low to generate a wait state. In most systems the microcontroller is the master and the external peripheral devices are slaves.

The maximum number of devices connected to the I2C bus is dictated by the maximum allowable capacitance on the lines, 400 pF, and the protocol's addressing limit of 16k; typical device capacitance is 10 pF. The I2C protocol has 127 addresses available. The original vision was to assign addresses by device function, but when Philips began to sell microcontrollers for I2C, the address could be programmed, eliminating the need for a Philips-assigned address.

To begin communication, the bus master (typically a microcontroller) places the address of the device with which it intends to communicate (the slave) on the bus. All ICs monitor the bus to determine if the master device is sending their address. Only the device with the correct address communicates with the master. In terms of wiring, all devices are simply attached in parallel to one another and simply listen for when their "name" is called to act. Our Brainstem's I2C bus is 1MB, allowing for up to 1MB of data to be transferred at a time bidirectionally. More than enough for our uses. Both the Brainstem Moto and Devantech Compass are I2C ready and can be configured using the Brainstem itself.

Gumstix

The Gumstix microcontroller is the brains of our system. It has the most advanced processing capability and is capable of large amounts of file storage. Since it runs Linux, it we will be using C rather than Java or Python simply because of our familiarity with C and its efficiency in port level interfacing as compared to the others. Although the Gumstix is certainly capable of supporting either a Java or Python environment, should one desire to use them.

We will be attaching the Gumstix to the Brainstem via one of its RS232 ports. The Gumstix Waysmall board has 2 Serial ports, both running at computer logic. The Brainstem, however, is running RS232 TTL voltage levels. These will have to be converted using a separate adapter, either purchased or constructed. This leaves one open Serial Port on the Gumstix which can used for a wide variety of applications considering the Gumstix's power. Many other projects have used a Bluetooth wireless link or CMUCam in this port, but this is beyond our current scope.

Timeline

As far as order of priority goes, the first connection to be implemented will be the I2C connection to the Moto. This will provide a solid sensor backbone with which to work with as well as make the car mobile (always a fun event). With the Moto attached, the infrastructure for adding more I2C devices will already be in place, making the addition of the other sensors a simple wiring and programming task. After this, we will complete the connection of the Gumstix to the Brainstem and begin algorithm programming, while the chassis is finalized and all mounting positions are constructed. We expect the programming of the primary algorithms and its subsequent testing to be the longest and most difficult of our tasks and leave it as an ongoing process without termination since new developments might require a reevaluation of our sensor package.

Follow Up

Our actual implementation ended up differently due to difficulties encountered during construction. I will go through each component and describe any problems encountered using this module.

Gumstix

The most complicated component of our system predictably had the most difficulties in setup. I owe this to our team’s relative inexperience in dealing with Linux and the Gumstix’s specialized toolchain that is needed to cross compile any program for use with the arm-linux kernel used in the system. Compiling the toolchain is a time consuming and difficult process fraught with the many dangers of unknown errors that may occur in the automated process. But if you intend to do any development with the Gumstix, you need to have this toolchain compiled for your specific Linux environment. The instructions for creating the chain can be found on the Gumstix Wiki at http://www.gumstix.org/tikiwiki/tiki-index.php?page=development-kit.

Originally, I followed the instructions on the site, setting up Colinux on my Windows host machine. The buildroot completed compiling but not after many, many hours of horrible errors due to missing programs, lack of legitimate networking interface (Colinux NAPs into your existing Windows connection for internet access) and small swap file. Although the buildroot did work, I could not use many other useful Linux programs to help me develop on the system due to lack of space. Unlike other virtual Linux builds, Colinux does not use a partition on your hard drive. Instead, it uses a large swap file to which the daemon mounts as the home partition. This must be configured in the default.colinux.xml file. While this provides the convenience of not having to create a physical partition to hold the Linux install, it also limits your home drive to the size of the swap file, which can be restrictive if you are trying to install a large Linux program like the Gnome2 GUI and transferring data from the original mounted swap file to a larger one is akin to trying to move Windows to another drive by copy-paste. It may work, but is by no means as easy as it sounds. The other option was to increase the size of the swap file with out wiping previous data. Again, not an easy task, and I opted to simply recompile my work on an actual Linux host machine rather than this virtual one.

My second foray into Linux was to install on a fresh host machine provided by Zach. I chose the Debian-based Ubuntu install (http://www.ubuntu.com/) as my Linux flavor because of its very simple install process, small package size and impressive array of tools, including a skinnable Gnome2 GUI. After a relatively painless install, bugged network drivers notwithstanding, I attempted to build the toolchain on this clean install. A few hours later, I still hadn’t found all the proper versions of the programs I needed. The toolchain is very picky about its environment variables and gcc versions. After compiling the chain, I would meet with Makefile errors if I tried to compile simple HelloWorld programs. At this point, I had spent too much time working on this problem and many other programming components more essential to getting a demo running (motor/sensor control) needed my attention.

Given another chance to work on the Gumstix, I would buy a CF WiFi card to simplify access to it. I understand now that trying to get a program running on the Gumstix was the wrong way to go about this system. The power of the Gumstix is its incredibly easy connectivity to host PCs, not really its computational power. Despite having problems compiling actual programs on the Stix, I was able to SSH into it and run Linux scripts just fine. I would hook up and configure a WiFi card to the MMC slot and reconfigure the Gumstix to output digital high and low from the pins of one if its GPIO Serial ports. Then connect it to the Brainstem and control the Stem through its Digital Outputs.

http://www.scratchbox.org/documentation/general/tutorials/explained.html

Brainstem Moto 1.0

Sample Moto wiring setup

The Moto, at first, seemed easy to use. Driver support from the manufacturer was provided to interface with both a host computer for testing and the Brainstem GP for actual use. Wiring was done through simple PC board standoffs to its two prebuilt H-bridges. However, when I first tried to hook everything up, the motors wouldn’t turn. I found out the lantern battery I bought from Radio Shack was actually a 6V and not 12V as I needed. Upon wiring up some 9Vs to produce the required power, I found the amp draw of both motors was too much for these small alkaline batteries and the motors never hit a reasonable power band. I strained for a solution that wouldn’t require me to strap a large 12v Lead-acid battery to this small chassis. I tried two 7.2V High Amp batteries which did produce the power I needed (a little too much) but found the assembly too bulky to use in this car. In the end I settled for not using the Moto since I had found another motor driving solution. Instead of the Moto board, I would use two MOSFET-driven electronic speed controllers wired to the servo outputs of the Brainstem. An ESC switches the motor on and off very quickly to control a car’s speed. The on/off pulses are at minimum 60Hz, with switching rates as high as 4000Hz. This is not as fine a control as the PWM control on an H-bridge but it can operate with less voltage and Amp draws up to 5A under heavy load. The two speed controls could be wired in parallel to the battery, meaning only one needed to be mounted. The speed controls only required a PWM signal from the Brainstem GP, which the GP outputs through its 4 servo ports anyway. I chose the Airtronics Contender not for any performance advantages, but for cost and availability issues. It is a very cheap Reversible ESC at only 30$. However, the design was old even before I got into R/C cars, which was over 10 years ago. There are comparable low-end models available at any local hobby shop, again, these were chosen for availability.

Airtronics Contenter ESC

Brainstem GP

Brainstem GP 1.0 Pinout

If the car was a living animal, the Brainstem GP would operate at the primitive sectors of the brain, controlling movement and general reflexes that occur unconsciously within us. The Brainstem holds all the basic obstacle avoidance code as well as drivers to interact with the three primary systems on our bot. The two ESCs were connected to Servo ports 0 and 1 with the IR sensor servo on port 2. The IR sensor is connected to the GPD02 connector on the board. The Devantech Compass is connected to the I2C bus. A small buzzer for debugging and was attached to a digital port and a kill switch was attached to an analog port. The kill switch signal would be converted using built-in ADC routines.

A BrainStem module stores TEA files in an EEPROM. Older GP 1.0 modules (Firmware Build 6 and earlier) contain 8 file slots numbered 0-7. Newer GP 1.0 modules (Firmware Build 7 and later) contain 11 file slots numbered 0-10. Each file slot in a GP 1.0 module is 1K in size. Programs can run in any of 4 "virtual machine" (VM) process slots numbered 0-3. Each process has a private stack space of 128 bytes. These processes can run concurrently. A 32 byte scratchpad RAM buffer may be used for sharing data between processes.

There is additional space on the EEPROM dedicated to storing reflexes. The GP 1.0 stores 128 reflex vectors and 128 reflex commands. For simple tasks, it may be possible to use a reflex instead of a TEA program and conserve process slots and/or file slots.

The only problem encountered when using the GP was an error with the startup reflex. When the obstacle avoidance program was loaded into program slot 0, it would execute on startup but exit prematurely unless a warm up program was run first. This was merely inconvenience, as a computer would always be needed for the vehicle to start.

The Brainstem can be programmed to run program slot 0 on startup by programming a reflex. Typically, a VM program is run manually from the console during the debugging phase. Once a VM program is complete, it may be downloaded and configured as a bootstrap program. The Brainstem can start up to 4 different VM programs at power-up reset. The cmdVAL_SET and cmdVAL_GET commands provide access to the 4 bootstrap file ID parameters. At power-up, the Brainstem checks these parameters for valid file IDs. If it finds it, it will execute. Process slots will be assigned sequentially starting from 0. To configure TEA file 0 as a bootstrap program, enter the following two commands at the Console prompt:

2 18 15 0
2 19

To kill process 0, enter.

2 22 0

http://www.acroname.com/brainstem/ref/h/TEAvm/bootup.html

Devantech Compass

Typical Compass Setup

The BrainStem GP 1.0 reads a 2-byte reading from the compass module and displays the result in degrees. From testing, we found the compass readings to be accurate to within +-5 degrees and precise to the tenth of a degree. A large problem not expected was the sensitivity of this module. The compass must be at least 10” from any ferrous metal or its reading will not be accurate. We did not take this into account for our original mounting position. As a result, the compass had to be mounted on the top of an aluminum/tin antenna, high above the motor assembly. This eliminated the possibility of creating a flippable car. Also, the compass is very sensitive to metals around the area making it less ideal than originally assumed for indoor exploration as offices and buildings have large amounts of metal in its structure.

I2C bus wiring

Sharp GP2D02 IR Distance Sensor

This sensor takes a distance reading when enabled and reports the distance as a byte-value cooresponding to the distance between 10cm (~4") to 80cm (~30"). The interface is 4-wire and requires a JST connector which is included with each detector. Also included in the package is a diode required for interfacing the detector to TTL/CMOS logic. Controlling the detector is done by lowering the input line, waiting for ~70ms, and then clocking the detector 8 times to read out the distance measurment on the output line. Each package includes a booklet that describes plugging together the connector, interfacing the detector to logic and the protocol used to take measurements using the GP2D02.

Features

Impervious to color and reflectivity of reflected object
High precision distance measurement through output for direct connection to microcomputer
Low dissipation current at OFF-state (Typ. 0.3 uA).

Electro-Optical Characteristics

Parameter	Symbol	Conditions	Min.	Typ.	Max.	Unit
Distance measuring range	delta L	^1, ^3	10	-	80	cm
Output Terminal Voltage	V_OH	Output Voltage at High, ^*1	V_CC-0.3	-	-	V
Output Terminal Voltage	V_OL	Output Voltage at Low, ^*1	-	-	0.3	V
Distance characteristics of output	D	L=80cm, ^*1	-	75	-	DEC
Distance characteristics of output	delta D	Output change at L=80cm to 20cm, ^*1	48	58	68	DEC
Average dissipation current	I_cc	L=20cm, ^1, ^2	-	22	35	mA
Dissipation current at OFF-state	I_off	L=20cm, ^*1	-	3	8	uA
Vin terminal current	I_vin	Vin = 0V	-	-170	-280	uA

We encountered no problems with this module; it performed perfectly in all conditions. It was originally mounted underneath the chassis to give a stable platform as well as provide shade, but instead we mounted it onto a servo in order to give it a 180 degree forward view. The servo was controlled by the Brainstem. This proved to be much more effective than the static mount, since we only had the one distance sensor for obstacle avoidance. It worked out very well, allowing us to scan an area in front of us as well as to our sides when obstacles were detected. It is very accurate and is not affected by indoor or outdoor environments. Even though it was our only obstacle sensor, our robot was able to avoid any obstacles around it and navigate even the most complex spaces with its precision angle data from the servo and accurate readings.

Overall Performance:

Final Block Diagram

As a whole, I feel the robot was successful in its ability to autonomously avoid obstacles and navigate small offices. A few faults lie in the drive train as the car is still a toy and geared for speed rather than accuracy. In addition, the absence of the higher resolution Moto board makes this car very unwieldy to drive. The difficulty in control is a testament to how well the sensor systems perform to be able to detect obstacles early on and avoid collisions in small environments. During Design Day, the bot was able to autonomously navigate the exhibition floor which had many people walking around. It did this without bumping into a single foot. Its adaptability to different environments is impressive as well, as it can navigate off-road bumpy terrain with no problems. It is a very robust a diverse platform that can work in both indoor and outdoor areas equally well, something not easily accomplished with more fragile robots. Had the Gumstix been properly implemented and the robot given much higher brain functions, this would be a formidable exploration platform.

Deliverables