Search This Blog

Sunday, October 24, 2010

Now remotely controlled via IP

After some hobby time spenditure, the result meets the expectations. While it is a functional and simple (and a good fallback solution), controlling the car via a regular RC radio is not the most interesting scenario. Having a device that is mostly digital, being controlled by an analog receiver isn't quite the nicest thing one would want to showcase. With that in mind, and taking into account that all the necessary hardware was already there and working, I have decided to take a little bit of time implementing the necessary components to be able to control the car from a remote peer in a wifi network. As such all I had was to:
  • Select the transport: TCP or UDP;
  • Design the protocol for carrying the control messages;
  • Design and implement the server application (running in OpenWrt linux);
  • Design and implement the client application (running in Windows or desktop linux);
(1) For the first point I have chosen UDP. In this type of use case, a connection oriented transport would not be optimal, compromising the realtime requirements of the communication. Occasional packet loss, in this scenario, can be well handled by the receiver, which includes timeouts to handle loss of communication, by taking the appropriate measures. As the data flow doesn't have to be acknowledged, the power consumption of the car can be further reduced.

(2) In the second point, a very simple protocol for carrying the control messages have been defined. Each packet has the following:

  • CSEQ - (2 bytes) a field containing a sequential number for each message. It helps keep track of message order and rate of packet loss;
  • CODE - (2 bytes) describes the type of the message (can be CONTROL, STATUS, or KEEP_ALIVE);
  • LENGTH - (2 bytes) indicates the size in bytes of the payload (the field that follows);
  • DATA - (0 - 18 bytes) the data itself;
  • CHKSUM - (2 bytes) a simple 16 bit check sum of the entire packet.
The DATA packet of a CONTROL message has the following structure:
  • CHANNELS - (16 bytes) each channel is a 2 byte value which corresponds to the pulse width to be applied to the corresponding servo;
  • BUTTONS - (2 bytes) each button in the joystick is represented by one bit, which contains its status.
(3) For the third point, implementing a C application to handle the incoming control UDP packets wasn't such a big challenge. All I had was to use the OpenWrt kamikaze toolchain, and compile the code with appropriate gcc cross compiler. The application would use the previously implemented library for handling the serial communication with the PIC based servo control and acquisition board (Droids MuIn). Configure it to run as a service and wouldn't have to bother launching it while booting up the Fonera.

(4) For the client I have given preference to implementing it in Java. The only challenge however was that Java doesn't natively support Joystick devices, so I had to find a library to take care of that. After a bit of searching I have found JXInput (, which seemed to be a decent library, with reasonable documentation and examples. All I had to do was using this library in my application (in the form of a Jar), and have the necessary windows dll in my application folder. This dll establishes the bridge (through JNI) to the Windows Joystick (or any other HID) API. Here is a screenshot of my application:

It connects to the car, passing steering commands from the joystick device. The user can select the joystick to use, and enter the IP address and port of the car.

A few photos of the car, during a maintenance task. In the aileron is the battery pack for the control electronics (the Fonera and the MuIn):

A bottom view of the sensor and control block (the heart of the robot), with all the necessary components:

Now controlling the "beast" is as simple as playing a videogame :)

Don't need the big 41 MHz antenna anymore, great! It's now easier to get under the table and under the skirt :)

Thursday, October 7, 2010

Booster circuitry up and running

Running digital equipment has the drawback of requiring tight voltage ranges in order to operate. In the case of my robot, I had the need for powering the Fonera 2100 from a pack of 4 AA batteries. While the batteries can deliver 4.8 Volts once fully charged (which is barely sufficient to power this wireless appliance directly), once the voltage drops further, the Fonera ceasses to operate. In this situation the batteries still have remaining energy that is not possible to use.

This type of problem calls for a voltage booster or charge pump device. These prodigious devices can take a given input voltage, and produce an output voltage that
can be lower, equal, or greater than the input voltage. They can even behave like voltage regulators, ensuring a steady output voltage.

I have chosen a simple to install voltage booster, already assembled in a tiny PCB. I went for the Pololu Adjustable Boost Regulator:

This device is based on a Semtech SC4501 (2 Amp, 2 MHz Boost Switching Regulator with Soft-Start).It can accept an input voltage between 1.5 and 16 Volts, and produce an adjustable output (via a potentiometer) between 2.5 and 9.5 Volts. With the average output currents of the Fonera of 0.5 A, this booster operates at around 80% efficiency.

While testing the device, I had the "surprise" of verifying that the input current once the fonera had completely booted, had raised to 2.1 Amps.
Without reading the input voltage, I was confused because the Fonera would only draw a maximum of 1 Amp. Then I checked the voltage at the battery pack, and these were measuring 3.3 Volts (without load these would normally be steady at around 4.8 Volts). The Booster output voltage was a steady 6.5 Volts like initially adjusted without load. With this I realized the booster was actually doing its job right, making it's best to maintain the output voltage constant. The batteries on the other hand were nearly depleted. This had the consequence of demanding massive input currents to compensate for the voltage drop. The 2 Amp limit of the booster means that in these circumstances the booster can barely handle the load. Fortunately this is the borderline case, to which the booster is only exposed for a small ammount of time (after this the batteries can be declared dead and must be replaced). On the other hand this booster has a thermal shutdown and current limiting feature, protecting the hardware from damage.

As a curiosity on charge pumps and ultracapacitors, here is a link to an interesting 9 Volt battery based on a 2.3 Volt ultracapacitor:

Tuesday, October 5, 2010

Drastic Improvement: new Mobile Platform

After a lot of stress tests with the original platform, it was time for something better. The original platform was no more than a toy RC car (entirely made of plastic) with some hobby RC parts on top of if, such as refurbished steering system (with a real servo) and a home made ESC (Electronic Speed Controller) for the original toy car motor. During a demonstration with my 4 year old nephew, showing him how fast the roving robot would go in an open area, suddenly something happened: it started running full speed, totally out of control, both forward and backward (in my mind I immediately tought one of the ESC FET's had fried). I rushed to grab it, and suddenly smoke started coming out of the motor. Worried about the LiPo battery, with the motor still running and smoking, I centered all effort in disconnecting the battery. My nephew started to cry with the stange situation. After making sure no fire would occur, I had a confused infant to comfort.

Obviously, the motor was completely fried. The home brew ESC had at least the two FET's burned (I hadn't spent more time doing a thorough diagnosis so far). Other than this there was fortunately no more damage. In spite of the full throttle collisions against the wall, everything else survived the event.

Given the accumulated ammount of effort dedicated to this robotic vehicle, I decided to instead of trying to repair the current version of the car, to move to a more decent roving platform.

After some searching in the robot and hobby RC markets, I found a reasonable solution, with all the conditions to ensure durability and stability: an electric hobby RC car - the HPI Maverick Strada XB. With 4 Wheel Drive, a 200 A Brushed Motor ESC, 540 size brushed motor, and 7.2 Volt 1800 mAh NiMh battery, this solution meets the conditions to perform better in demanding terrains:

Besides being cheaper than equivalent platforms for robots, it comes complete, whith everything necessary to run: steering servo, ESC, motor, and a radio transmitter and receiver (the later being redundant, given the fact that I already had another transmitter/receiver kit).

The integration with the existing robot core module (the board with all the electronics, including sensors, computer, camera, and digital/analog I/O controller) was relatively smooth, with the exception of the modifications needed for adapting to the lower main battery voltage: 7.2 Volts instead of 11.1 Volts.

Given the ammount of necessary changes, I took the opportunity to improve the computer (Fonera) power supply. Instead of powering it directly from a pack of 4 AA batteries, I added support for another 4 batteries to optionally connect in parallel, and booster circuitry to extract more energy from the batteries (the Fonera would not like when the voltage would drop below 5 volts), ensuring the correct voltage supply for as long as possible.

With all the mechanical changes required to adapt to the new frame, the final result is the following:

In spite of the aesthetics not being the high point of this project, I have to say that in my opinion it looks a lot better than before.

The AA battery packs are located in the replacement aileron. In spite of not being the optimal location considering the center of mass, it was the only adequate location, considering the fact that the sensors and camera could not have the corresponding field of view compromised.