Alternate Controller

[davefowler]

Has anyone come up with another way to control the vex? I want to control it with my laptop instead of having to use the remote control. This way the vex can get into autonomous development. The people of vex should make some kind of usb connection to the microcontroller. If someone has an oscilloscope or a logic analyzer you could test the signal comming out of the back of the remote control. I wish I had a scope at home... Anyway, if someone does analyze the signals and makes up some kind of chart post it here, it'd be very helpful.

[foobert]

i think it's pwm. 6, 1 for each channel, 1 to 2 ms pulses such that 1 ms is full reverse, 2ms is full forward and 1.5ms to stop. near as i can tell this is how cheaper rc controllers work.

not something your laptop will put out unless you want to try some low level stuff on the parallel port. might want to be running some sort of low latency OS on the laptop.

of course, you can order a programming kit and write a little something to get the vex controller to listen on its serial port for instructions from your laptop. nice plain ascii human readable instructions at that.

[Billfred]

I can see how this is a different topic, but you might want to look into this thread for some insight on some folks' work on making the controller programmable (before RadioShack releases the programming module, that is).

If someone can figure out the signals coming out of the tether port on the Vex controller, I could imagine them being replicated...but for programming autonomous behavior, the things they're talking about in that thread is right up your alley.

[BrianBSL]

The cable that goes between the reciever and the vex controller is 4 conductor, so it isn't PWM. (PWM would require atleast 7 conductors (6 signals and one refrence)). I haven't really looked into it enough to know what its actually doing.

[billbo911]

Originally Posted by BrianBSL

The cable that goes between the reciever and the vex controller is 4 conductor, so it isn't PWM. (PWM would require atleast 7 conductors (6 signals and one refrence)). I haven't really looked into it enough to know what its actually doing.

True that it would require at least seven conductors to transfer 6 PWM signals, but that is only true if they are sent discretely. If they are sent via serial, it is quite possible that they could be sent over a four conductor cable.

After reading this thread last night, I decided to look into the default code for VEX. Now understand, I am NOT a programming guru (yet), but I can figure a few things out by examination. It does look as though the signals sent from the Radio Controller to the micro controller are in fact PWMs. There appears to be no signals being returned to the Radio like there are on the FRC OI for things like LED's and Hex display.

BTW, I just ordered the programming kit yesterday , it should be in this week, I hope, or early next week. I am also hoping the kit includes more info, like the other kits do. I'll post up what I received once it comes in.

[foobert]

i downloaded the default software posted at vexlabs this morning and scanned it over lunch and on the train home. it seems the master microcontroller posts pwm data to the user microcontroller every 18.5 ms. this is plenty of time for six one to two ms pulses. the fact that the variable names have the letters p, w and m only increases my confidence in my theory.

unfortunately the source code for the master controller is not posted so i can't claim absolute certitude.

anyone interested can download http://www.vexlabs.com/docs/VexStartupCode.zip

for now i'll be hiking to the vet for medicine for my hypertensive cat.

ta-ta

[billbo911]

Originally Posted by foobert

unfortunately the source code for the master controller is not posted so i can't claim absolute certitude.

I hope you are more versed in figuring out code than I am. If so, you may be able to look at the MASTER SOURCE CODE already and just not know it. If you are referring to the Master code *.bin file, then it is included with the default code. In fact, there is a v4 and v5 version. VEX_MASTER_V4.BIN and VEX_MASTER_V5. BIN are included when you unzip the file.

If I'm off base on this, sorry. As I said, I'm new to programming and still trying to reach Grasshopper level. Guru will take a while, 'till then, I deffer to those more knowledgeable.

[fowlerm]

Originally Posted by billbo911

I hope you are more versed in figuring out code than I am. If so, you may be able to look at the MASTER SOURCE CODE already and just not know it. If you are referring to the Master code *.bin file, then it is included with the default code. In fact, there is a v4 and v5 version. VEX_MASTER_V4.BIN and VEX_MASTER_V5. BIN are included when you unzip the file.

Unfortunately the .bin files that IFI uses to upgrade the master processors are actually encrypted hex files, so you can't just disassemble the bin files. There are a couple of ways that you could get at the decrypted hex if you are determined to disassemble the master code, but will take some extra effort.

I think the best solution for finding a way to use another controller would be to analyze the data being sent across the tether cable, not to disassemble the master code. My guess is that the tether uses a serial protocol, but I haven't looked at it. I'll check it out when I get home today and let you know what I find out.

[billbo911]

Originally Posted by fowlerm

Unfortunately the .bin files that IFI uses to upgrade the master processors are actually encrypted hex files, so you can't just disassemble the bin files. There are a couple of ways that you could get at the decrypted hex if you are determined to disassemble the master code, but will take some extra effort.

I think the best solution for finding a way to use another controller would be to analyze the data being sent across the tether cable.......

What's really funny is, I realized shortly after posting my last reply that I was talking about a .bin file, as in BINARY. Hello Bill, you know this!! (Don't worry, I talk to myself like that occasionally, I never take it personally)

Your right, without the correct software tools, it is VERY DIFFICULT to decode them. I agree that the link between the remote and the micro controller is probably serial. That seems to make the most sense to me. I'll do a little more digging once I get the programming kit. UPS has it scheduled for delivery on the 14th.

[foobert]

i got tired of wondering and posted a query to the forum at vexlabs.com. the output of the r/c controller is indeed a pwm pulse train. abandon hope of controlling this with a pc. talk to the serial port instead.

[fowlerm]

I was looking at the transmitter over the weekend and found out the same thing. It may be possible to use a PIC or a basic stamp to take the serial output from a computer and use generate the appropriate PWM pulse for the desired analog value. The only thing that you would really need to find out is what the timing is for the different PWM outputs. The pinout for the tether port (for those of you that are interested) is from right to left if you are looking at the port on the transmitter is:

1 - Tether detect - used to enable/disable the radio transmitter
2 - Gnd
3 - PWM output
4 - +5v

[foobert]

thanks. can you tell us anything about the timing of the pulses?

seems like using pulsout and pause on a stamp would be kind of hairy given the millisecond resolution on the pause instruction, but i guess it depends on what the signal looks like.

and if you're going to program a pic, you might as well program the one that's on the robot already. of course, that's 100 bills for the programmer. might not be such a far fetched idea, at that.

[fowlerm]

The answer I got from IFI regarding the timing of the signal is:

The channel data is adjusted to get values from 0 – 255 and the channel data spacing is 2ms.

Meaning the signal that is sent out is basically the analog output from the different pots and switches in the controller using an 8-1 analog mux to select one channel at a time. Each output is transmitted for 2ms, and then they switch the mux to the next channel. I'm assuming that they go in order when switching channels, but I haven't looked into it. I'll scope the mux control lines just to make sure of the order.

This probably isn't going to be that hard to do. I'm going to use a PIC instead of the Basic Stamp (too slow). I'll look into this some more during the weekend, as I've got a lot going at work right now.

[foobert]

fowlerm, what say you scope the output of the controller and take a picture for us. might be worth a thousand or so words. maybe even more to my addled old brain.

[fowlerm]

Originally Posted by foobert

fowlerm, what say you scope the output of the controller and take a picture for us. might be worth a thousand or so words. maybe even more to my addled old brain.

When I said I'm going to scope the control lines on the mux, what I'm going to do is take an oscilloscope (scope) and watch the different control lines on the multiplexer (mux). In the picture that I attached, the small 16 pin chip near the top right of the green pcb is a Rohm BU4051BCF 8 channel analog multiplexer/de-multiplexer. There are 3 control lines (A, B, C) that are used to select channel that will be output from the multiplexer. For example, if A-C are low, the output channel is channel 0, if A is high and B-C are low the output channel is 1. Think of A-C as 3 bits in a number, with A as the least significant. The maximum value of a three bit number is decimal 7. The multiplexer's channels are 0-7, so the decimal value of this three bit number is the channel that is selected for output.

Also, there is a high-res picture here if you want higher detail. It's 1.8 megs, so dial-up users have been warned.