Here is an image of the output from the receiver. NOTE: The receiver really wants 5 Volts, but I am running it at 3.7 Volts at the moment(a single lithium battery) It works at 3.7V but has a considerably shorter range.

The nice this about this, is that all of the channels are on a single line. This makes it very easy to interface with a microprocessor. A quick review of the PPM format:

• 20 ms total before repeat.
• Each channel is sent as a high signal followed by a 1 ms low. The width of the high signal determines the value sent. A zeroed channel has a width of 1ms. A full positive channel is 1.5ms and a full negative channel is 0.5 ms.
• On the Vex there are six channel (The six peaks that you see) for a total of about 12ms buffered by approximately 8 ms.

To interface with a microprocessor, simply plug the output of the receiver into your microprocessor. Send 5V to Vdd and Ground to Vss.  Tie the output of the receiver to 5V over about a 10K resistor.  Start measuring pulses on that channel. If you measure at least a 6ms low(The buffer) start recording pulses. (These are your data pulses.) Record all six channels and then decode the length of each pulse.

Here is some Arduino code to do just this:

#define channumber 6 //How many channels on the radio???
int channel[channumber]; //Channel values
int output[channumber];
int PPMin = 4;

void setup()
{
Serial.begin(9600); //Initialize Serial/
pinMode(PPMin, INPUT); // Pin 4 as input
}

void loop()
{
//waits until synchronize arrives > 6 miliseconds
if(pulseIn(PPMin , HIGH) > 6000); //If pulse > 6 miliseconds, continues
{
for(int i = 1; i <= channumber; i++) //Read the pulses of the remaining channels
{
channel[i-1]=pulseIn(PPMin, LOW);
}
for(int i = 1; i <= channumber; i++) // Process the input
{
//enter output processing here
}

After driving it around for about 10 minutes I decided to test the camera. The camera works immediately with my 2.4 Ghz Wireless to USB box. The channels that Vex assigned are non standard 1=4 etc! However with a bit of fiddling it works. Unfortunately the camera included on the Vexplorer is about the worst quality I have ever seen. Terrible low light performance, lots of interference etc. I have bought inexpensive cameras, but never had a NTSC camera this bad. Still it should be workable in Roborealm.

Here are some snaps that I took from Roborealm:

Now on to hacking the remote. Here is a picture of the backside of the remote. There are two structures that have circles in the middle. These are the backsides of the joysticks. The large surface mount chip is the microprocessor.

The remote operates at 27 Mhz. There are four analog channels and two digital channels. Each pair of analog channels is fed by a very nice joystick which controls a two ~1K pots. When the joystick is moved, the resistance between the central terminal and one of the outlying terminals decreases. This is hooked up with a voltage divider network. The microprocessor uses an ADC to measure this voltage and encode the appropriate signal to transmit. I removed one of the joysticks and wired into it. I am not sure what I did (I think I just shorted power to ground) but the remote stopped working for about 20 minutes. It did eventually recover after I soldered the pot back in (Phew!) It seems like interfacing to the remote this way will be tricky!

The microprocessor outputs some kind of modulated pulse on one of its PWM outputs. I left my oscilloscope probes at work, and all I have are a pair of alligator clips soldered to a BNC connector. Needless to say all I see on the PWM output is noise right now. When I go into work next, I will bring the probes home so I can look at generating the appropriate PWM output.

The microprocessor on both the transmitter and RX is an ELAN 78P458. Here is the data sheet for this microprocessor. elan78p458.pdf  Unfortunately, it doesn’t support rewritable memory, so we can’t get at the toy that way!

For now I will breadboard up a Picaxe controlling a set of 4 hbridges to drive the robot. I will use an XBee module to provide serial communication with the PC. This is an expensive way to do this, but it will work for now. I would prefer to just use a Picaxe on the transmitter side and use all the vex electronics on the bot.

Sure enough there were two pins that controlled each motor. Now interfacing was dead simple. De-solder the RC chip.

Solder 4 wires to the holes identified earlier. (Sorry about the quality of the picture. You can see where the chip was removed. The wires are potted in hotglue to provide stress relief. Run those wires to the PicAXE outputs with 4.7 K resistors to limit the current. Program the PicAXE, add batteries and wallah instant robotic platform! I did add a piece of expanded PVC as a top platform.

The car has a dc motor connected to a two speed switchable gear train that drives the rear wheels. There is basically a solenoid up front that shoves the front wheels hard right or hard left. There is no ratiometric control on this car. One final feature is the two curving metal pieces connecting the front of the chassis to the rear. These not only act as giant bumpers and strengthen the chassis, but one of them acts as the RX antenna.

The remote control operates at 27Mhz and appears to use an amplitude modulation scheme. I decided to interface the remote control to the PC.

After some false starts here is what works. There are a set of metallic contacts that the switches on the RC controller make and break. This controller is not ratiometric, so I just drilled a hole in the middle of each contact and wired into it. The middle is tied to ground on the microcontroller board and each of the outside contacts is tied to the output of a ULN2803 darlington array. The strategy is that the microprocessor will have the darlington array connect each of the contacts to ground. You need four microprocessor outputs to do this. (With clever logic you could do it with three outputs, but that would increase the part count.)

Now the microprocessor receives serial commands and interprets those to turn on the appropriate channels on the RC car. The RC transmitter provides its own power which is isolated from the microprocessor. (This means that you need to keep batteries in the transmitter.)

The transmitter seems to have a range of about 10 meters.

symbol forw = 2
symbol back = 3
symbol right = 4
symbol left = 5
setfreq m8

main:’Get a value from the terminal

serin 4,N1200,b0
’serout 0,N1200,(#b0)
if b0 = 56 then goforward
if b0 = 57 then goforwardright
if b0 = 55 then goforwardleft
if b0 = 51 then gobackwardright
if b0 = 50 then gobackward
if b0 = 49 then gobackwardleft
if b0 = 53 then gostop
low back
low right
low left
low forw

goto main

gostop:

low back
low right
low left
low forw

goto main

goforward:

low back
low right
low left
high forw

goto main

gobackward:

high back
low right
low left
low forw

goto main

goforwardright:

low back
high right
low left
high forw

goto main

goforwardleft:

low back
low right

high left
high forw

goto main

gobackwardleft:

high back
low right

high left
low forw

goto main

gobackwardright:

high back
low right
high left

low forw

goto main

Next a simple Roborealm interface was written to take keyboard commands as input and output the appropriate serial commands. The car can now be driven from Roborealm. Here is a picture of the picaxe based interface board. The process of making this board deserves a page of its own.

I adapted the Picaxe based Robosapien Control unit by just changing the IR header from 0011 to 0110. I finally found a set of Roboquad IR commands at AiboHack. Later that same day Robert from Robosapien Dance Machine emailed me an even more complete set of codes. roboquadircodes.txt

I initially got the RoboQuad responding to simple commands and then moved to interfacing it with RoboRealm. It turns out that the RoboQuad is a lousy platform for computer vision because it jerks around so much. I mounted a camera on the top of the RoboQuad and spent some unsuccessful time trying to do something useful with it.

Finally I decided to implement voice control for the RoboQuad. I used the microsoft speech SDK through roborealm to detect voice commands and then on those send IR commands through the PicAXE based IR transmitter to the robot. Right now the RoboQuad only understands Forward, Right, Left, Backward, Stop and Again. Here is a video of the RoboQuad walking around under voice command. roboquad.MOV It isn’t quite as smooth as what Robert achieved with his demonstration video, but I suspect that I need to mess with the timing in the speech recognition. There is about a second delay between recognition and sending out the command.

Here is a first stab at embedding a YouTube video:
Here is a video from the camera mounted on the RoboQuadA final video of the Roboquad navigating under voice control using “smoother” voice commands

If you are new to HID devices, you should check out Jan Axelson’s page. Jan’s books have been inspirational for me for years! (Starting with the serial port book years ago)

I started with a program called SimpleHIDwrite which will let me write raw values to a HID device.

On opening SimpleHIDWrite the Dream Cheeky USB car shows up as a device called the “Rocket Baby” Pretty funny.

The device returns the following information from a info request:

PID 0A81
VID 0702

When the car is in the charger and the car is charging the driver returns:

RD 00 05

When the car is fully charged the driver returns:

RD 00 85

When the car is out of the charger the driver returns nothing.

Writing a 01 to the driver causes the car to go forward (That was a surprise!)

Here is a table with the rest of the commands in HEX

$01 Forward

$02 Right

$20 Left

$04 Backward Right

$08 Backward

$10 Backward Left

$00 STOP!

Thats it! Now if I can talk the roborealm folks into changing their Dream Cheeky driver to include this I will be set. Otherwise I will have to start coding……

Ok, so I started coding a little bit. I downloaded Jan’s VB6 HID module and got it working with the USB car. I have to stop working on this or I will be up all night!

So I wrote a simple windows program to control the Car. It uses Jan Axelson’s HID module and has a simple mouse interface to drive the car. There really were other things I should have been doing tonight! Download the program here! usbcar.exe

I then took the car apart. There are a couple of transistors used to drive the motors. There is a small pot that can adjust the receive frequency. The steering is done by energizing a small electromagnet that drives the front wheels and there is a small gear motor in the back which drives the rear wheels. A small battery provides power and is wired to the two contacts in the back for charging. The cars antenna is wound up inside the top of the car. I unwound its antenna and ran it up a drinking straw. Now the range increased to about 2.4 meters. These seem like small changes, but they dramatically effect the performance of the car.

The next task is to figure out how to control the car from some application other then the provided dream cheeky software. The driver uses the USBHID dll so it should be pretty easy to take over. There is some amount of documentation on the net about another dream cheeky product “Dream Cheeky USB missile launcher” so that might be a starting point for writing software for this device.

Ultimately I would like to control this car from Roborealm.

Here is a short video of the car driving controlled from the computer station several meters away.

USB CAR.MOV

Here is a picture of the finished product.

H

Here is a video of the Robosapien moving under roborealm control. robosapien.avi

There is an excellent tutorial on path planning on the Roborealm website.

There is much more work to be done on this.

I setup the pwmout to provide close enough to 39.2 kHz and feed that into an AND gate. The other input of the AND gate is an output from the picaxe. I send T1200 signals out from the output and into the AND gate which results in a 39.2 Khz carrier modulated at 1200 baud. Great so far!

BUT! The Wowee protocol wants a header that looks like this %11111111 followed by a time spaced pattern where a high is 0001 and a low is 01. If I code up a typical pattern for say “Walk forward” or $86 it looks like %11111111,%000101010,%01010001,%00010100

It took me the longest time, but I think I know what isn’t working. Looking at the output on a scope there is a single low to high transition between each 8 bit transmission. This is messing up all my timing. I assume this is the “1 stop bit” in the 8n1. I don’t know where to go from here. Maybe if I sleep on it I will have some ideas in the morning. Otherwise, I will have to give up on the Picaxe for this project.

UPDATE:

After learning that the V2 protocal is 12 bits long, (From building a receiver and tying it to a scope) and getting an idea from Hippy on the Picaxe forum the project is now working. Here is the code

• ‘RoboSapien IR control using picaxe 08M
  ‘Pass commands at 4800 baud 8N1 from your terminalsetfreq m8′IR is modulated by channel 1
  symbol IR = 1
  ‘This is a dummy variable to make pulsout work
  symbol dum = 4′These are values to make the timing work
  symbol duration = 88
  symbol start = 1203
  symbol highbit = 560
  ’start the pwm module
  pwmout 2,50,100
  main:
  low ir
  ‘refresh the pwm module
  pwmout 2,50,100
  pause 50
  ‘Get a value from the terminal
  serin 4,N2400,b0
  pause 10′Init and WAKEUP sequence
  high IR
  pulsout dum,start
  ‘RSV2 header is always 0011 0
  low IR
  pulsout dum,duration
  high IR
  pulsout dum,duration
  ‘This bit is low 0
  low IR
  pulsout dum,duration
  high IR
  pulsout dum,duration
  ‘This bit is high 1
  low IR
  pulsout dum,highbit
  high IR
  pulsout dum,duration
  ‘This bit is high 1
  low IR
  pulsout dum,highbit
  high IR
  pulsout dum,duration
  ‘END HEADER

  ‘logic

  if bit7 = 0 then
  gosub lowsignal
  else
  gosub highsignal
  endif
  if bit6 = 0 then
  gosub lowsignal
  else
  gosub highsignal
  endif
  if bit5 = 0 then
  gosub lowsignal
  else
  gosub highsignal
  endif
  if bit4 = 0 then
  gosub lowsignal
  else
  gosub highsignal
  endif
  if bit3 = 0 then
  gosub lowsignal
  else
  gosub highsignal
  endif
  if bit2 = 0 then
  gosub lowsignal
  else
  gosub highsignal
  endif
  if bit1 = 0 then
  gosub lowsignal
  else
  gosub highsignal
  endif
  if bit0 = 0 then
  goto finallowsignal
  else
  goto finalhighsignal
  endif

  goto main

  highsignal:
  ‘This bit is high 1
  low IR
  pulsout dum,highbit
  high IR
  return

  lowsignal:
  ‘This bit is low 0
  low IR
  pulsout dum,duration
  high IR
  return

  finalhighsignal:
  ‘This bit is high 1
  low IR
  pulsout dum,highbit
  high IR
  pulsout dum,2
  goto main

  finallowsignal:
  ‘This bit is low 0
  low IR
  pulsout dum,duration
  high IR
  pulsout dum,2
  goto main

A quick note on the IR transmitter stage. I adapted this from the robotroom. He has a nice writeup on using a 555 to drive a IR transmitter. However, the PicAxe pwmout gives a reasonable alternative.

Finally just for fun I tried taking pictures of the oscilloscope screen with the digital camera. This is not of any particular signal, but it works better then I expected! I remember using a special adapter to take Polaroids of Oscope screens back in the day…..

Because this project was such a pain, I bought a new scope written about elsewhere. I love it! Here is a wowee signal on the new scope. Where was this a few weeks ago! Note that the 0011 header followed by the device command. In this case it is 10010000 This corresponds to the master program command (Or the D button on the remote)

Not pictured are advisors Ben Chu and Profmason.

The competition is supposed to run five rounds with the best win/loss and point ratio being ranked into the top eight at the end of the competition. This competition had 46 teams! This meant there were approximately 250 people actively competing! The large number of competitors made it difficult for the event organizers, but the did a great job of keeping the event moving and organized.

Each round consists of four robots in two teams of two. The round starts with a twenty second autonomous navigation period, is scored and then there is a two minute remote control period. Rules for the competition are available here.

Here you can seem Team Wacbot with their alliance partners. Their alliance partners was one of several all girl teams mentored by the Girl Scouts of America. I can barely wait to sign my daughter up for girl scouts!

Unfortuately, during the autonomous navigation round, WacBot got caught up on a ring and wasn’t responding to controls. It spent the entire round sitting stuck on the ring.

The students did a terrific job of problem solving and ended up tearing out, rebuilding and reinstalling the stripped motor in less then twenty minutes! The students decided to make some substantial design changes to the robot to prevent this problem from happening again!

Unfortunately their chief programmer didn’t make it to the competition. (He had been up all night the night before coding the autonomous mode!) The vex control box with the program installed had stopped responding on two channels. The students swapped in a different control box, but this lacked the autonomous programming.

After the modifcations, Wacbot was hot! With Kevin driving they racked up ring after ring on the high tower, setting the competition record for rings on the high tower! They triumphed their next two rounds and ended up in 9th place out of a field of 46!

Then they were struck by disaster again. The arm pivot had been doing such yeoman work hoisting rings that it stripped out in the middle of a match! The students tore the pivot mechanism apart and rebuilt it.

They finished the rebuild and rushed to the competition stand. Then they found out that the last rounds had been canceled due to time constraints! The organizers had done their best, but there were so many teams that they couldn’t run five rounds.

Here is a picture of the winning robot in the individual rankings.

Despite being getting zero points the first round and loosing the arm in another round, the team still finished 27 out of a field of 46!

Here is a picture of a championship round to give you a feel for what the competition looks like. Four robots battling it out!

Overall the team did a terrific job, especially of diagnosing problems on the fly and finding appropriate solutions. This is a great competition and the organizers, Marty and Ralph from the Small Manufacturers Association deserve major Kudos for putting on an event that inspires so much creativity, ingenuity and hard work!

Team WacBot is hoping to get a spot in the finals at Cal State Northridge in December!