I have a sample V.05 robot kit, so far I program the robot using EASYC.
I want to build a control system which would control the robot wirelessly.
When the control board is micro - processor sample PIC18F452 using basic commands (right, backward, forward, left. Stop)
I wanted to know if I need to buy additional parts such as transmitter / receiver or I can use what I received the kit?
And if I need to buy what you recommend me?
I believe what you want to do is possible with the kit parts, but you will have to slightly modify the 75MHz transmitter to take a signal from your control board.
Inside the transmitter, there are two main circuit boards: One that generates the PPM signal, and one that transmits it as a 75MHz FM signal. Those boards are connected by a few wires, one of which carries the PPM signal. You will have to intercept that wire with a switch so you can turn off the internal PPM signal. You can then inject your own PPM signal into the tether port on the back.
When I get home from work, I’ll post some pictures of the wire that you need to mod, and how to connect your control board to the tether port.
As for generating that PPM signal, you will have to write a program for your PIC18F452 control board that can generate a repeating series of 7 timed pulses. The time delay between each pulse determines what value the robot will receive for each of the 6 control channels. For instance, if the delay between the 1st and 2nd pulse (ch1) is 500µs, the robot will act as if the right joystick was moved fully to the left. If that delay is 1,500µs, the robot will act as if the right joystick was moved fully right.
That series of 7 pulses must repeat about 60 times a second.
There is some MPLAB code for generating a PPM signal located here. It is designed to work on a V0.5 Vex Microcontroller, but it shouldn’t be too hard to adapt to your control board.
There is also a whitepaper (pdf) that describes how to decode the PPM signal as received from the yellow receiver module. Reading that may give you some more information as to what the signal looks like.
Actually looking at it a bit closer, the modification to the transmitter will be slightly different than I described above. The signal going to the tether port is carried on a separate wire than the signal going to the modulator/transmitter. That’ll make the hack just a bit harder, but it should still be possible.
Here are some pictures that will help show what you need to modify.
First, you need to open the transmitter. To do this, unplug the crystal (if present), then remove the battery cover (and battery, if present). Then remove the nine phillips-head screws that hold the back cover in place. The back cover has wires going to the battery compartment, so when you open the case, treat it like it has a hinge at the bottom. You should see something like this:
You’ll notice the rectangular brownish board in the middle. This is the modulator/transmitter board. Carefully lift this board off of its posts and turn it over.
You can see there are 5 wires going to solder points on the back of the board. These points are even labeled:
*]GND (Black) Ground for signals and power
*]VCC (Red) Battery power, +9V typical
*]ANT (Yellow) Antenna output
*]MOD (White) Modulator input
*]SIG (Gray) Tether input
To transmit a control signal that you generate, you would cut the White wire (MODulator input) and feed your signal there. Your signal should be an Open Collector output without a pull-up resistor. The transmitter will pull this up to about 2V, so this should be compatible with 5V or 3.3V logic.
If you want to get fancy, you could mount a switching jack like this one, which will pass the internal signal if nothing is plugged in, or use the external signal if something is plugged in.
The signal you generate will be a positive PPM signal, meaning that this signal is at low most of the time, but with brief high pulses. The 7-puse train will need to be repeated about 54 times per second.
Don’t forget, the ground of your microcontroller needs to share a common ground with this board. Just solder a ground wire between the Black (GND) signal on this board to a ground contact on your microcontroller.
If you need a smaller solution, you could extract the modulator/transmitter board from a spare Vex Transmitter and use it by itself. You’ll need the antenna, a 9V power source, a crystal, and the PPM signal I mentioned above to get this board going outside of the controller enclosure.
Thank you for your efforts in response you gave me,
Unfortunately the robot does not belong to me personally (of my college) so when I asked for permission to open the box and play with the wires, my teachers have not confirmed this.
I can thank you a lot for the help.
Wish you lots of success
If you want to create a remote computer control for the Vex system without modifying any of the parts, you could make your own RF serial link. The programming is a bit different than regular radio control since EasyC doesn’t help you out quite as much. A serial link can be more flexible (you decide how many channels you need), and you can even make a 2-way link if you need it.
You can assemble a simple 1-way wireless serial link for as little as US$10 in parts: TX + RX
There are many existing threads on the Vex forum that discuss wireless serial. Check out here, here, here, or here. There are even more if you search for combinations of terms like “wireless, radio, remote, serial, PC”.
Until I figured out which transmitter / receiver to buy I try to connect the microprocessor - a wired controller to the controller of the robot.
I connected the exit of the micro - controller (tx) to one of the digital entry of the robot’s controller, but I managed to send only 0 or 1.
But I want to send more bits (decimal 255 or 8 bits) How I do it?
I tried to connect it to Port rx which is located on the i / o (not through the back entrance which is serial controller) and did not pass the data(I tried to send 255 in decimal).
What do you think should be done, is it possible to transfer information of more than one bit through the ports of the i / o?
Hi, dear Dean
I tried to connect a wired out of the pic18 I have into the rx of the robot but without success, he shows me 0 all the time on the robot rx (I did print screen)
When shortened between the tx of the robot and the robot’s rx is able to transfer the information,
I also know I have no problem at the exit of the pic18 because when shortens between the rx and tx of the pic18 information can pass.
So right now I have no idea what to do …
I would be happy if you could help or advise me what to do.
(By the way I wrote you yesterday I was able to employ a single bit but I was wrong it takes “1” all the time and takes “0”).
The pic I use is: pic18f452
It looks like you’ve got a good logical approach to this.
You’ve verified that loop-back on the Vex microcontroller works
You’ve verified that loop-back on the PIC18 works
Now you are stuck getting them to talk to each other
Usually, problems like this are caused by the two ends not using the same bit-rate. This won’t effect loop-back tests, since each unit will receive at whatever speed it is sending. But when you hook the two units together, one could be sending at 19,200 bps, but the other could be listening at 9,600 bps.
Also, you should make sure the two ends are operating at the same voltage. The Vex operates at 5V. What voltage are you using for the PIC18?
If you want me to help further, you’ll probably have to post your code. I am not deeply familiar with PIC micros (I prefer Atmel) but I’ll have a look and see if I can spot the problem.
I don’t quite follow what you are saying here, but ultimately I don’t think it matters for getting serial working.
Hi Dean, First of all thanks for all your help.
Without you I was not advanced at all
I wanted to update you what is happening with me, and ask you a number of questions:
I managed to link the pic and the robot’s controller in wired and I can send commands.
I did it by wire connecting the white and black wires only, as shown drawings you uploaded to the forum.
But when I send say 10 decimal, is getting it as a different number on rx of the robot (say 152 decimal), is that acceptable? Is that OK? Of course it changes the values to everything I send from the pic18 to the robot .
I have version easyc v.2 I got from my college.
To use the program you sent me I had to download a free version of easyc pro (it is valid for one week only) Do you know where to get free student version of let’s say six months or so?
Thank you for all your help,
Next, I need to find a rf transmitter and receiver
No problem at all. You are doing all the hard work
Excellent. This means you are 99% the way to a fully functional solution. I think I can get you the last 1%…
To debug this, lets first convert 10 and 152 to 8-bit binary, since that is what is sent over the serial link:
TX: 10 = 00001010
RX: 152 = 10011000
Now, lets have a look at what gets sent over the serial wire for these two values. To do that, we have to know a few things:
First, async serial adds “framing” bits to help keep the transmitter and receiver in-sync. That means it adds a ‘0’ Start Bit before the first bit, and adds a ‘1’ Stop Bit after the last bit.
Second, async serial sends the data “lsb-first”. This means that it sends the ones-place first, followed by the two-place, then the fours-place, etc. This means bits are sent in the reverse order from the way we write numbers where the ones-place is written last.
So, over the wire, the following bit patterns are sent:
TX: 10 = 0010100001
RX: 152 = 0000110011
The first thing I noticed when I did that is that 152 has all of its bits doubled up; The zeros and ones are appearing only in pairs. This usually means that the receiver is receiving twice as fast as the transmitter is transmitting (each bit that gets sent over tx from the pic is being sampled twice on the rx side). Lets stretch the 10 out and see if it transforms into a 152:
TX: 10 = 0 0 1 0 1 0 0 0 0 1
RX: 152 = 0000110011
It does! The rest of the bits will be discarded if they don’t form a valid byte with framing intact. In this case, they appear to form a valid 2nd byte; I think the Vex would receive a 128 after the 152:
So, to sum it all up, you either need to double the bit-rate of your Pic, or halve the bit-rate of the Vex. That should get your serial link working perfectly.
Sorry, I’m not aware of any such trial licenses. However, if you are programming the PIC microcontroller, you are using some kind of PIC development tools. That probably includes the Microchip compiler. If so, you could download MPLAB for free and use that to program the Vex. It isn’t as easy to use as EasyC, but it would work for free. Details are here.
Glad to help. The cheapest RX/TX link I know of is the SparkFun radios I pointed out in an earlier post: TX + RX
I’m experimenting with those now, and I can describe how to wire them up if you are interested.
I’m going to buy the transmitter and the receiver as you recommended.
As I mentioned before, I intend to transmit the information from pic18F452 to the robot, I also saw the rate of transmission in the data sheet i think its good for me (I need transmission rates of 4800 bps).
I would be happy if you could give me some information or any tips on connecting the wires to the robot and to the pic, until the shipment reaches me.
I’ve just posted a pair of diagrams that show how to wire the receiver module and transmitter modules to a Vex. They can be found here.
Since you will be hooking the transmitter to your PIC board, you’ll have to handle that wiring yourself, but it is extremely straightforward. There are only four pins and they are well labeled.
When I wired my receiver module up, I noticed that the pins on the module were just wires soldered to pads on the module. To make the whole assembly more compact, I decided to remove these pins and solder the wires directly to the PCB.
So I carefully unsoldered the pins and cleaned the pads with some solder wick:
Then I soldered the wires as shown in the drawings:
And then covered it all up with some clear heat-shrink tubing:
Here is the whole module ready to plug into the RX port:
I’m not sure what your soldering skill level is. You could do it the way I did, or you could solder the wires onto the pins. You could also solder the module to a prototyping PCB such as sold at Radio Shack and then hook the wires to that.
If you want to avoid soldering entirely, you could plug the module into a small breadboard (these fit the receiver perfectly) and wire it up using some of these prototyping wires (they fit into the breadboard, and into the VEX Microcontroller ports).
Here is some EasyC Pro code that I wrote to test this setup. It simply receives bytes on the RX port and sends them back out on the TX port. It also updates the display once every second with the number of bytes received in the last second and in total.
void main ( void )
unsigned char rx = 0; // Byte we received
unsigned int rx_count = 0; // Bytes received this second
unsigned long rx_total = 0; // Total bytes received
unsigned long time = 0; // Screen update timer
OpenSerialPortTwo (BAUD_4800); // Set up the RX/TX Port for use
StartTimer ( 1 ) ;
while ( 1 ) // Loop forever
while ( GetSerialPort2ByteCount ( ) )
rx = ReadSerialPortTwo() ;
WriteSerialPortTwo ( rx ) ;
rx_count ++ ; // Count each byte we receive
time = GetTimer ( 1 ) ;
if ( time > 1000 ) // 1 sec has elapsed so update the screen
rx_total += rx_count ;
PrintToScreen ( "+%d" , rx_count ) ;
PrintToScreen ( "=%ld\n" , rx_total ) ;
rx_count = 0 ;
PresetTimer ( 1 , 0 ) ;
While you are waiting to receive them, lets talk through your command protocol. The wireless link won’t behave exactly like a wired link, and there is some programming you will want to do to make the link reliable.
You will have to code defensively for bit errors, and to make sure the receiver stays in sync with the data stream. This shouldn’t be too hard, but it will probably effect the structure of the data you actually transmit.
What did you have in mind for your command protocol?
Are you going to send one byte commands, or do you plan to design a multi-byte packet protocol?
Just describe the type and amount of data you were planning to send over the link and we can work out the most reliable way to do it.
Others on this forum may be able to offer better advice on this, since it isn’t something I’ve personally written code to handle. I think the problem with “simple” code for this is that it generally focuses only on wheel speed. In other words, it will react to one side going slower than the other side, but the damage has already been done and the robot has already veered to one side by the time the correction is applied.
To make it work reasonably well, you need to think about correcting your position rather than just correcting the relative wheel speed. You would need code that uses the encoder feedback to figure out where you’ve moved to relative to your starting position. Then figure out what wheel motion is required to get you to your target position. You will want to be constantly re-evaluating your position and re-planning your motor motion.
You will need the floor to be flat and level, and to be covered in a material that the Vex wheels work well with. Hard floors and very low-pile carpets will work well. Heavy carpets or rooms with uneven floors will make navigating with any accuracy almost impossible.