Introduction

This page is dedicated to host LSCBOT photos as well as a detailed description of its adventures. I also discuss its construction and upgrades. I try to improve LSCBOT in my free time with the help of friends from my lab (LSC - Institute of Computing from Unicamp). People who contributed for this project include Mario Hato, Thiago Falcao, Divino Cesar, Leonardo Piga and Rodrigo Faveri.

LSCBOT is a toy car adapted to work with a microcontroller. In its current setting, it uses a GHI FEZ Spider starter kit to run a small webserver that serves a very simple page with the latest camera picture and basic motor controls (forward, backward etc.). To control the car, the user needs to open a browser and type in the IP address of the car (it serves the page on port 80).

History

The car is an experimental platform that was rebuilt many times. It began with an FPGA, but it was too heavy for the toy car that I bought: to support the FPGA, we once had mounted on the car a thick steel platform. Needless to say, the car could barely move. Since the FPGA is entirely digital, we still needed to provide custom analog circuitry, mainly the power amplifiers to control the two motors. To do this, the car had two H bridges and a few other companion circuits to aid the digital end to read simple sensors (See Fig.1). To detect frontal collision, an LDR detected if the light of a bright white LED was returning to it by reflecting on the nearest wall, while one of the wheels had a photodiode and a infrared LED, as in an old mouse circuit, to detect the current speed of the wheel.


Fig.1. This was the first attempt at a motor driver. Yes, we did it without ICs, just for fun. No, it was not a good idea (the black marker is reminiscent of a desperate debugging session). Mario freaked out when he saw this board and immediately threw it away.

Improvements and design

The first change was in removing the FPGA in favor of a much lighter ARM microcontroller (mbed), plugged in a breadboard on the car. The mbed was programmed through its own compiler toolchain on the web, which, on my opinion, is quite irritating because you don't have local access to your files and binaries. I was uneasy to spend a huge amount of time in an online toolchain that, if went offline, I could lose everything.

The second change happened when we (finally) removed the heavy steel platform and also the mbed. Afterwards, we used the GHI FEZ mainboard, which implements the .NET gadgeteer stack. To program this microcontroller, you can use Visual Studio with .NET. Of couse, this is a restricted edition of .NET that was tailored to adequately run on very simple devices, so don't expect to have access to the entire .NET BCL when coding with the .NET Micro Framework. The huge advantage is the time invested. It can't be easier: you just allocate a socket in the FEZ mainboard to plug a daughter board, and the software stack already has drivers implemented to handle this board. With this, we easily added a camera to the car and an ethernet module, and in less than a day implemented a simple webserver to display the user control page. The main problem, of couse, was the Ethernet, which required a huge cable connected to the car to work.


Fig.2. This is the FEZ Spider mainboard mounted on the car. There are a lot of sockets and possibilities for extensions. The 72MHz ARM processor from the LPC SoC IC that powers this board is on the other side of the board and is not visible in this picture. Curiously, the position of the screws matched perfectly the toy car (below), allowing it to be firmly mounted on the car.

Also, we finally removed the buggy board from Fig.1. To replace the H bridges, Mario plugged the control signals directly into the original H-bridge circuit from the toy car, which was less powerful but much more compact, gaining a lot of space and reducing weight of the car. The original toy circuit still had an RC FM transmitter, but we discarded it. However, replacing the motor controller from Fig.1. to use the original toy circuit was not easy. We spent some nights trying to debug the circuit - the motor controller started with a nasty habit of shaking the wheels without any input. We would later discover that the output transistors were failing, requiring a painfully long process of desoldering a transistor and replacing it for a good one from the board from Fig.1, which used a similar H-bridge configuration, but with more powerful transistors. Eventually, we ended up replacing all output transistors (8) until everything was OK. Afterwards, the only problem remaining was the dependency on the ethernet cable, which surely sacrificed mobility. You can see how the car looked like in the following video.

The third change gave real freedom to LSCBOT: the wifi. Again, with the .NET gadgeteer framework, changing the ethernet for wifi was as simple as plugging the wifi and type 5 or 6 lines of .NET code to start an AdHoc connection. With this last change, the car was very light and with wireless, allowing it to run as well as you can see in the following video. Perhaps it ran too much:

Battery

A challenge apart is the battery selection. The microcontroller circuit and the electric motors cannot share the same battery, otherwise everytime you activate the motors, they drain enough current to pull Vcc down by a few tenths, enough to reboot the microcontroller. I had all of this reported in a nice oscilloscope graph, but unfortunately I don't have a picture to show you. Bottom line, the spare batteries that I had to use in this project were terrible and ordering one via DealExtreme would take forever to arrive (which it actually did and when it arrived, it was defective and I had to order another one). For now, we are living with a terrible battery that can hold 30 minutes of microcontroller activity. It is this giant white case that comes next to the FEZ mainboard, in Fig.3 below.


Fig.3. The white battery that powers the entire microcontroller ecosystem (WiFi, camera, ARM processor etc.). Our circuit consumption is around 200 mA, and the battery barely lasts 30 minutes. Pitiful. We'll soon replace it (where are you, dealextreme?)

The car has two simple electric motors: in the front, one motor controls direction, in the back, the second motor controls whether the car goes forward or backward. The current consumption is, on average, 1A for the rear motor when the car starts accelerating, but decreases as speed increases. However, the front motor always consumes 2A, since it has no movement once the direction is set. To supply all this demand, we use 4 rechargeable NiMH Sony cycle energy batteries (see Fig.4), and they do it very well. In fact, we never recharged it since the first use and the first charge. There are a few reasons to this, though: (1) the motors are not in constant activity as the microcontroller circuit is and (2) the microcontroller battery typically dies very fast, so we can't play around enough to drain the battery of the motors :)


Fig.4. Motor batteries.

Web interface

The web interface loads a picture from the on-board camera and displays to the user as in Fig.5 below. It also provides a variety of buttons: to turn on or off the front lights (two bright white LEDs), reload the camera image (it is not streaming, otherwise it would be slow and power-hungry), directional controls and my favourite one: the software reset button. Since the gadgeteer didn't provide a software reset, we "implemented" it the hard way. If the user asks for a reset, the microcontroller activates an output pin that goes directly into the base of a power TIP transistor that simply short circuits Vcc with ground. By doing so, similar to the motor and microcontroller in the same battery effect, Vcc is pulled down by a few tenths of volts, enough to power down the microcontroller and start the reboot. But when rebooted, the microcontroller immediately de-asserts this output pin, turning off the power transistor. I know, it is stupid and costs a few coulombs to reboot this machine, but trust me, during our first debugging stages, we needed a SW reboot BADLY, and "http://10.0.0.1/reboot" HTTP GET request will do it with no remorse.


Fig.5. The web interface.

Camera

The camera initially was mounted on the front, right on top of the front motor that controls the direction. However, a funny side-effect forced us to move the camera. Every time the direction motor was activated, the electromagnetic field corrupted some random bits in the camera nearby, making it simply die, waiting for a reboot. Now, the camera is mounted on the breadboard in the rear side of the car.

Exploratory Mission #1

With the car setup and WiFi working, we were ready to go out on a mission without supervision. The challenge was to control the car by using only the web interface, which provides camera pictures upon requests and takes, on average, 2 seconds to deliver the image. I put the car in the corridor that our lab share with another (rival) lab, and walked back inside my lab and closed the door - it is important for the enemy to do not see who is controlling the car. If you are curious, enemy lab does image processing. The goal of this mission was to sit waiting in front of the enemy lab door, wait for someone to open it and penetrate enemy lands, take pictures of hostile territory (ironically, pictures are their expertise area) and go back to HQ untouched.

The artifact drew quite a lot of attention from passersby, thinking it was too cute to do any harm - which is good. Unfortunately, once outside, direct sunlight tampered camera settings and the image was almost always very bright. Fig.6 shows the first interaction of the car with the enemy.


Fig.6. Interacting with the enemy.

Fig.7. Interacting with the enemy.

Fig.8. Interacting with the enemy.

Fig.9. Interacting with the enemy.

Fig.10. Interacting with the enemy.

Fig.11. Interacting with the enemy.

The mission ultimately failed after 31 minutes of operation and the death of the main battery. I tried to knock the door with the car, but I couldn't find an opportunity to run inside once it was open.