Search This Blog

Saturday, December 25, 2010

Merry Christmas

Christmas is a great time for parents and kids to experience engineering with the inspiring cheerfulness of eating turkey, cakes, and looking at the fireplace while it's snowing outside. Offering the right gifts is a good way of bringing up the excitement that building artifacts can cause. While, of course, not all infants have the same thirst for scientific knowledge, for those which we find to have potential, the choice of technical gifts is not to be disregarded. While in my personal view, reminding myself as a toddler brings the memories of how vibrant and exciting it was to receive a chemistry kit, a microscope, an electronic device ready to be disassembled, etc, in the mind of a modern kid this might not be quite so satisfying. A Gormiti castle, a bunch of Ben Ten toys or any other sounding brands will certainly trigger more "processes" in a toddler's cognition.

A discussion about how today's television and toy industry affects children and youths is of little impact, but it is a fact that it is now in the hands of the parents and educators, to control the degree of exposure of their offspring to these elements, as the sole regulating factor seems to be profit generation alone.

Like with many other aspects of our world, let's hope some sense will grow out in the desert and guide those who deserve.

And of course Happy Holidays and fruitful engineering. Don't worry letting your kid become an engineer :)

Sunday, December 5, 2010

Quadrature Encoder

One of the essential things an autonomous rover must have (which mine didn't had) is one or more quadrature encoders. In fact even some non-autonomous vehicles have these devices. Most regular cars these days feature this type of sensor as part of the ABS system (see http://en.wikipedia.org/wiki/Anti-lock_braking_system). Very reliable and high-resolution sensors can be found in these (featuring 90 steps or more).

For this autonomous rover I found that 16 steps would be the bare minimum, and easy to implement with common components.

As I didn't want to modify the RC car itself (drill holes, cut parts, etc), I looked for a solution that would minimize the impact on the car. As such I found that a good option would be to use the inner ring of the wheel as a surface for sticking an encoder band. This band has 16 steps, and looks like this:



Once glued to the wheel we had this:



On the other hand putting the sensors (two IR emmiter/sensor combos are necessary) would not be an easy task as well. As I have chosen the CNY70 (these are approximately 8 mm cubes), room for
the entire thing would be limited. Anyway I managed to fit the two sensors in one of the suspension ball link support holes. The result was this:



Another view with the wheel fitted in:



With a bit of effort, I managed to place the two sensors on a small PCB, and carefully aligned these with the encoder band and ensuring that a 90 degree displacement would be obtained (this is fundamental for proper detection).

There was obviously no room for more components or even for a conector to the main board. As such
I soldered thin wires from the sensor board to the analog interface board, which is the following:



The quadrature decoding board was mounted on the main fixture like most other electronics.



The role of this board is to receive the analog signal from the sensors, run it through an LM358 setup as a level comparator, clean the resulting square waves from impurities by passing it through a schmitt-trigger gate, and finally provide the signals to the decoding logic, taken care by an Atmel Attiny45. The contained firmware results from the work of Adriaan Swanepoel, which can be found here: http://www.auv.co.za/blog/attiny45quadraturedecoder. This microcontroller counts the pulses from the encoder, and allows the count to be obtained through I2C, via its slave interface. This is a very handy solution, as it offloads any of the other computational modules of the robot from the quadrature decoding. The main logic only has to poll the count on a regular basis, and perform whatever calculations are necessary with the data (speed, odometry, etc).

A hand made schematic diagram describes the solution:



Like with any non-trivial design before the veroboard version of the hardware, I put together the entire circuit on breadboard, and tested against the remaining hardware (autonomous vehicle):



A few aspects are worth mentioning: First I had no trouble building the FW project with AVR Studio 4. To program the Attiny45 I used the simplest possible programmer:


To build it you just have to link the following pins:





















Parallel Port Attiny45
1 (/STROBE) 7 (SCK)
2 (D0) 5 (MOSI)
3 (D1) 8 (VCC)
11 (BUSY) 6 (MISO)
16 (/INIT) 1 (RESET)
18 (GND) 4 (GND)

It is recommended to put a 1 KOhm resistor between the MOSI (Pin 5) and PPort pin 2, and another 1 KOhm resistor between SCK (Pin 7) and PPort pin 1. This will offer a certain degree of protection to both devices.

To actually flash the device I used "avrdude" under linux. It's a nifty little piece of software that allows programming with just about any type of hardware.

At first I could not communicate at all with the Attiny45. Using the I2C master routines from the PIC, I tried to issue the appropriate commands to the expected default address (0x3E). After googlig a bit and reading some forums, I found that certain I2C slaves expect the address shifted left by 1 bit. I tried this, and by analysing the SCL and SDA lines on the oscilloscope, I found that the device would react. Write commands such as reset (0x01) would apparently be successful. But the read command would fail most of the times. Without having deep knowledge about AVR architecture I started to consider all possible options. By looking at the fuse settings I found that the Attiny45 was running at 1 MHz:


avrdude: safemode: lfuse reads as 62
avrdude: safemode: hfuse reads as DF
avrdude: safemode: efuse reads as FF


Among other things lfuse maintains the clock divider bit (CKDIV8).This divides the 8 MHz clock by 8, slowing the device down to the speed I verified.

Well, given the fact that my I2C master was clocking out at 100 KHz, it was clear that a 1 MHz clock was not going to be enough to support a bit banging I2C slave device. Without hesitation I
put the device in the programmer and changed the fuse setting:


$ avrdude -v -p t45 -c dapa -P /dev/parport0 -U lfuse:w:0xE2:m


Put the Attiny45 back in the circuit and..Eureka! It was working flawlessly. Signals on the oscilloscope also looked more solid, without gaps in the clocks and responses.

After a few tests it was time to assemble everything in veroboard and add to the car. Final tests revealed the encoder to be pretty accurate, with Fonera software calibrated for measuring speed and distance in metric units. A very happy ending.

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 (http://www.hardcode.de/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 say...watch 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:

http://hackaday.com/2005/12/06/supercap-9v-battery/

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.

Thursday, July 1, 2010

Power pack!

While the rear wheel traction motor provides plenty of power for normal operation, the curiosity of obtaining some extra power through a different propulsion method is appealing. Since I had some parts from a unfinished airplane project, the materialization of another exclusive idea became real: to build a special trailer for the car, with a single purpose - to push the car even faster, with the help of a propeller instead of traction wheels. Featuring a 9x6E propeller, a 150 Watt brushless motor, an 18 A ESC, and a 1300 mAh LiPo battery, this trailer provides the closest one can ever get from raw rocket power, with controller propulsion.



The following video demonstrates the car in action, with wheel traction and with propeller exclusively.




The module features a small pcb just for preventing the +5 volts power provided by the propeller ESC from being fed to the car's circuitry. As these devices use linear regulators, there is the risk of damage due to reverse current to one of the regulators.

Wednesday, June 2, 2010

Sensors are never too many




While it is important to design a autonomous rover capable of performing even under the worst conditions and with the least available information from the surrounding environment, if we can provide good information, it will certainly lead to better results as long as we have a good software implementation behind it.

As such a sweeping sonar as single sensor is not enough for proper navigation, even at the smallest speeds and using the best navigation algorithms. In order to compensate the sensorial weakness, in this step I have added two infrared distance sensors. I have chosen the Sharp 2Y0A21 (http://document.sharpsma.com/files/gp2y0a21yk_e.pdf), which can measure distances from 10 to 80 cm. While not being as powerful as the sonar (15 to 600 cm), it is a useful reference for dodging obstacles in realtime.

I have added one servo to each of the two IR sensors, allowing the angle to be adjusted, and to point the sensors to the back while maneuvering in reverse.

Tuesday, May 4, 2010

System override

Unlike some other domains, with robot software bugs can have expensive outcomes. In order to avoid unpleasant mishaps, I have decided to implement a hardware solution for preventing software originated problems that could cause a calm, boring robot to become a runaway beast hitting hard against walls, people, animals and anything that is in its way. To achieve this I have built a PWM control source multiplexer:



This board enables the user to select through an RC radio channel, the source of control. Up to 4 servo channels can be multiplexed, from 2 different control origins. In my setup, I can select if the input of 4 channels should come from the 41 MHz RC receiver, or from the MuIn (PIC18F2520) board.



In case the robot starts doing something that is not correct, the user can immediately toggle the source of control, and prevent a crash from occurring.

The solution simply consists of a salvaged servo control circuit, and two TTL 74 series IC's.



One is a 74LS157, which is a 4 bit 2 input multiplexer. The second one is a 74LS14, which is an hex inverter, with schmitt trigger inputs. It is intended to help clean the signals from the control pin, in order to avoid intermittent operation. As the TTL multiplexer cannot directly understand the PWM signal from the RC transmitter's channel dedicated to switching the source of control, it is necessary to have a circuit capable of getting the PWM signal and output 0 or 5 volts, depending on the length of the input signal. As I had (mechanically) broken servos, I took advantage of the control circuit of one, for doing this translation. In order to ensure a steady output (the output signal is a waveform between DC and a pulse width modulated signal that powers the motor) I have added a 22uF capacitor, sufficient to smooth out the signal. The schmitt trigger gates help to provide a clean signal to the multiplexer.

Sunday, May 2, 2010

Almost autonomous

With all the hardware prepared (except the quadrature encoder on the wheels, which is still to be implemented and installed), all conditions were met in order to be able to write some code and make the car finally move on its own.

I have first added the sonar module (the previously mentioned SRF02). This implied making a small aluminium support to fixate the sonar to the servo, while still being able to slightly adjust the tilt:



After installing it, made a quick check and read the ranging data directly through the MuIn original Windows application:



Every thing was fine. It was time to add more code to the MuIn PIC, implenting useful functions for the robot. A singe command returning both range data and the servo position would be useful, so I implemented it. It essentially consists of the following structure:


'@''F''S'I2C addrservo nr00'#'


Each element is 8 bytes long. The PIC responds with the following answer format:

'@''F''S'I2C addrservo nrRange HBRange LBServo HBServo LB'#'Checksum


This allows a measurement to be taken, while the servo is sweeping.

A small video of the car in action:

Sunday, April 25, 2010

More stuff on the pipe


The good work goes on, and the objective of achieving a fully autonomous rover is closing in. In this article I present 3 hardware additions:

First I found that the 1300 mAh LiPo battery could not be enough for long endurance roving activities. So I decided to add a pack of 4 NiMh AA batteries (2500 mAh each) dedicated to the Fonera. With this extra power, control and communications autonomy is guaranteed even if the powertrain pack becomes depleted. Additionally the efficiency is improved, because considering the fonera input voltage (5 V), and the voltage of the main pack (11.1 V), a regulator would be necessary, to properly drop the voltage. A linear regulator would not be a very efficient solution, and a switching regulator, in spite of being more efficient, is more complex and expensive. So with this separate pack, which provides around 4.8 V when fully charged, is enough for the Fonera (in fact the Fonera can be powered to a minimum of 3.5 V thanks to its internal low dropout regulator).



As I already had more than one power source, and several distinct systems onboard, in order to avoid the clutter of connecting and disconnecting sockets every time I wanted to turn the components on or off, I decided to add a control panel with 4 different switches:



The function of each is:

* MAIN - cuts the power to all systems;
* CAM - turns the camera on or off;
* CTRL - turns the Fonera (the control computer) on or off;
* ESC - turns the ESC (Electronic Speed Controller - it controls the speed of the powertrain motor) on or off;

A LED under each switch indicates if there is current in each circuit, and if its turned on or off.

The switches provide a way of quickly turning the devices off in case of malfunction.

The last item is a turret for mounting a sonar ranging sensor (an SRF02). At the top, a microservo is mounted. It will provide azimuth variation for the sensor, allowing the area relevant for navigation to be swept continuously.



In order to minimize the computational load and I/O for the host machine (Fonera), the PIC 18F2520 had it's original firmware (which is opensource - see http://www.robot-italy.net/roboforum/showthread.php?t=1600) modified to accomodate the ability to automatically put the servo sweeping continuously. The host in the case only has to use a sonar command that will return both the range in cm, and the angle of the servo (in us of control pulse witdth - it ranges between 850 and 2350 us for approximately 110º of amplitude). The original sonar commands were modified to provide the position of the servo associated to the sonar. Another command was added, for reporting the position of all the 8 servos that can be connected to the MuIn.

The next step will be to mount the sonar on the turret, and once this is done we have the minimum hardware for implementing autonomous control of the vehicle.

On the Fonera the control software is written in C, and is programmed like any linux application. So far I have only implemented a small application used mostly for testing the MuIn functionality (servo control, ADC channels, I2C, EEPROM, etc):




Thursday, March 25, 2010

Cognition on Wheels



Last, but absolutely not the least, is adding intelligence to the beast. Considering the budget constraints and simplicity of integration I decided by using a Fonera 2100 router as the workhorse for processing data. Equipped with a single chip Atheros solution, the integrated 32-bit MIPS R4000-class processor runs at 183.5 MHz, and is tipically enough for most network processing that is required. Additionally the IEEE 802.11b / 802.11g WiFi interface provides the means for remote communication with the vehicle. For local communication it features both an Ethernet interface, and a 3.3 V serial port.

On the other hand I also needed a way of controlling the servos (other than manually through the RC radio)from the Fonera itself. So I considered several serial and I2C servo control solutions, and found this. Besides having 8 servo outputs, it also features 5 analog inputs (10 bits), I2C bus, 2 PWM outputs for controlling motors, and a TTL serial port. This is all thanks to the PIC18F2520 in which it is based. This is essentially all the I/O I need for getting the robot car doing something useful.

Here is a picture of the car already with the fonera (just the bare PCB), and the Droid MuIn board (the multi I/O card I was talking about):



I also had to get a solution for powering the control systems (the Fonera and the MuIn) from the salvaged 10 V lead acid battery (at least for now). So I added the following switching power regulator from a car lighter cell phone charger:



The Fonera communicates via serial port with the MuIn. I had to make a small cable connecting both modules with each other:



The Fonera GPIO pins could be useful. Made a small circuit to buffer and translate levels from 3.3 V to 5 V for these GPIO lines. It might be useful in the future:

Thursday, March 11, 2010

Let there be light!

One of the most pleasant situations is when can execute an idea without using any of your budget. It occured to me that having some onboard lightsource could be useful for the car, specially if you plan on doing night driving. Well I took a look at my repository of electronic junk, and found a pcb with 9 white leds from a broken flashlight, and a bunch of broken 9g microservos.



So I thought, well...if I could get the leds to be turned on and off through a free channel on my radio, it would be sweet.. And then took a look at one of the servos, and thought: I remove the motor, replace the encoder pot with a set of resistors, connect the leds in series with a small value resistor, and it should do the trick.

And so I did it: first analysed the servo operation in its original form. Connected the motor to an oscilloscope, and verified that a PWM signal that varies in duty cycle is fed to the motor. The further you move the stick, the more the duty cycle approaches 100%. Without surprise the peak voltage would be 5 V at the motor terminals (the same voltage that powers the servo).

Measured the pot resistance, which was 2 KOhm. Measured the current consumed by the leds while being fed with 3.1 V (minimum voltage for enough luminosity). It would draw 60 mA.

Then all I had to do was applying Ohm's law to find the appropriate resistor to drop the voltage, given the current that we know the LEDs consume. Found that the ideal value was 52 Ohms (V=RI <=> R = V/I <=> R = 3.1 / 0.060 = 51.66 ~ 52 Ohms).

I did't had this value (the closest resistor is 51 Ohms), so I used the closest resistor I could find at hand. Found a 47 Ohm, which in spite of being slightly smaller, it shouldn't harm the leds as I was being conservative with the voltage in the first place (these were being used in a flashlight powered by 3 AAA batteries - meaning that the voltage could be up to 4.5 V). The typical voltage to which white LEDs are rated is 4 volts.


With a bit of experimentation found an appropriate value for the resistors replacing the pot. One 2 K resistor between pin 1 and pin 3 of the pot terminal, and a 1 K resistor between pin 1 and pin 2.



By doing this I trick the servo controller into thinking that the motor is always in the same position, while the user commands it to go to a different position. This causes the controller to continuously provide current to the motor, in an attempt to reach the desired position. Here instead of the motor we put the LEDs. The result is the LEDs being constantly lit while the stick is in a given region, and off in the remaining positions (because a negative voltage is fed to the LEDs - if a motor would be present instead, it would cause it to move in a different direction).

A little bit of soldering, and it was done! This way I had the cheapest possible RC headlight without spending a single cent.



And finally, after putting heatshrink around the PCB, the work was done:

Wednesday, March 3, 2010

Intelligence on wheels

Robotic vehicles are not a novelty. Initial attempts to create autonomous roving machines date back to the 1970's, with examples such as Stanford cart in 1961 and Shakey, Moravec in 1979. These were simple machines. Digital computers were not yet miniaturized to the point of enabling interesting computing power onboard a vehicle, regardless of its practical size. Even so, the state of the art of the technology at that time proved sufficient to allow the mankind to explore new fronteers of a universe never before crossed by human artifacts. Two such examples were the NASA Voyager I and II missions. Having passed the 30 year mark in space, these prodigious machines still beam back health reports to earth, and should continue to be up and running until the energy generated by the plutonium based RTG (Radioisotope Thermovoltaic Generator)is insufficient to power the essential electronic systems onboard (of which one of the most important ones is the radio transmitter). This should occur anywhere in the next 10 years.

Today we have the result of tremendous technological improvements since the time the Voyager spacecrafts had been created. However, achieving the same degree of reliability is a milestone not always achieved in every case, regardless of how much extra knowledge the humanity have been gifted with.

While trustworthiness is not necessarily a consequence of innovation, it must be in the agenda, as long as the outcome is intended to be a dependable solution.

Anyway, the focus of this post is more on innovation itself rather than discussing trustworthiness and reliability. I am presenting a small part of what one day will be with us everywhere.

We are surrounded by automatic machines in our daily lifes. Even where it's less obvious. The small capsule called elevator, that takes us from one floor to another is one such example. While it doesn't look like a robot, it is a very autonomous machine. Equipped with clever microcontrollers, elevators are capable of making logical decisions, while multiple users request its attention. It's a simple example of a machine that in its current state of evolution is driven by an electronic computer, has sensors, and is capable of triggering actions (e.g.: activate a motor) based on a predefined plan, or in response to external input (e.g.: pressing a button). It can be enabled with useful optimizations such as having the ability to position itself automatically in different floors, depending on the selective demand at diferent times of the day, within a building.

Robots are intended to be useful for the human being, not to replace him. Through automatic machines we moved from one point to another in our ability to produce more and better artifacts, and to provide better services to people.

In this blog post I am presenting you with a machine that, while functional, is still the first step for achieving a helper robot, the hopefully will be the base platform for making very interesting household applications for machines this size.

I started from buying a cheap supermarket toy RC car. It called my attention the fact that besides its low cost, it was large (1:10 scale), had very nice looking wheels, and featured a 850 mAh 10 Volt lead acid battery (so most likely it also had a motor rated for 10 Volts or more):





Of course the lead acid battery would not be very interesting as my future power solution, but we'll return on that later on. I decided to buy this car for the features managed to discriminate.

After fully charging the lead acid battery, I tested the car, still in its original form. I noticed that it really had nice torque and plenty of raw power. However, it lacked the ability to harness the beast. Like with most toy R/C cars, it's circuitry only allows zero or full throttle to be applied, both in forward and reverse directions. This, of course besides being very limited, also translates to prematurely worn and damaged gears. On the other hand the steering was also very poor. It was also zero or full travel in both directions. Of course we cannot expect proportional controls for a 25 Euro car! Well, I tested the car for, say, 1.5 minutes, and the battery soon started to gradually drop the delivered power. I was admired, either the battery had very poor quality or the motor was an animal.

I decided to start the transformation. I had a few spare hobby R/C parts such as a few microservos, a Art-tech 41 MHz 6 ch. receiver used in model helicopters and planes and a 11.1 V 1300 mAh battery (the stock battery from my Falcon 3D heli).

I started by removing all the crap out of the car, until I got this:



Here is the circuit board with the receiver and motor control. Here I had already removed the two SPDT relays used for reverse. Take a look at the big resistor (feer):


The original steering motor:



It hardly had torque to turn the wheels, specially after 1 minute of battery use.

The transmission motor yes, had quite a punch. I measured it's current while connected to the fully charged battery, it draws 1.5 A free running, and 13 A under full load (zero RPM on the shaft). So it consumed 130 Watts of power. The output power should therefore be around 100 Watts, assuming it's a reasonably efficient brushed motor.

I still needed a brushed motor ESC and better servo for the steering. I searched the web for DIY ESC solutions, and found this, which seemed interesting:

http://www.designsoft.com.au/ahome/rc/PIC-ESC/ESC.html

It featured design variations for both cars and planes. It seemed exactly what I needed, and I calculated that it shouldn't be hard to build and expensive. I had the option of choosing the relay or the H-bridge reverse. As I still had the two SPDT relays from the original circuit, I decided to try this version, as it would be slightly cheaper. Already in an advanced stage of the assembly:



And the top view, with the two white relays:



After building the hardware it was time to program the PIC:



I had to build a small board with the ICSD socket for the PIC, as the ICD 3 is not provided with one:



Mounted the 41 MHz radio and the LIPO battery. Both fitted nicely into the original
battery compartment:



Mounted the 43 g standard servo (it has 6.5 kg of torque). Replaced the original links with ball links. Adapted the steering bar in order to attach the servo arm through a ball link:



After a few more assembly iterations, mounted a virgin pcd board to be used as a plate for scientific instruments, and attached a gymballed support for a 1.2 GHz wireless camera. The gymball was assembled manually with aluminium. It uses two microservos to provide pitch and yaw for the camera. This is the result:



A detail view of the camera, which is also powered from the LIPO battery, through a regulator board I have also assembled (located in the bottom of the virgin pcb). It provides +5 V and +9 V necessary for the camera (camera and transmitter respectively):



The car is then controlled by a standard PPM 6 ch transmitter (41 MHz):



After the assembly, it was time for a test drive! Turned on the camera, connected the 1.2 GHz analog video receiver to a home made patch antenna, and time to hit the road..errmm...the wooden pavement..

As the car moved away from the place where I was controlling it, signal weakening and multipath interference became apparent. Some servos glitch violently under signal interference...dumb radio... The ESC on the other hand doesn't react because it properly filters occasional glitches.