Tether for new EduBot Controller

[gburlison]

Let me know If you think this will work!!!

The new EduBot Controller has Analog inputs that you might wire a potentiometer to.

The Joysticks have potentiometers for the X and the Y axis.

Make an adaptor cable to connect a Joystick to the analog inputs of the Edubot ( be sure it will be long enough to act as a tether)

Write your program to use the the analog inputs as you normally would use the joystick inputs.

[Matt Krass]

In theory that would work perfectly, I think. (Very assuring I know ) now we need a way to make that wireless and we're off to a start.

[gburlison]

now we need a way to make that wireless and we're off to a start.

That part has already been solved, get an R/C transmitter and receiver.

[Matt Krass]

I meant....ok I don't know what I meant, but it involved a simpler cheaper solution than a hobby R/C system.

[ZACH P.]

Originally posted by Matt Krass
I meant....ok I don't know what I meant, but it involved a simpler cheaper solution than a hobby R/C system.

unless you were used to constructing r/c circuts, a prebuilt r/c system is definatly the most simple way to go.

[Venkatesh]

Here is what I think about this,

We could connect the relay outputs of the old EDU-RC to the digital inputs of the new EDU RC. The old EDU controller could be controlled remotely with the OI. I would be careful with voltages (i dont know the signal levels for the Spike Control Pins), but this solution seems fair for those with old EDU robot controllers. Otherwise, I would use an old full-size robot controller for the task.

[gburlison]

Here is what I think about this,

We could connect the relay outputs of the old EDU-RC to the digital inputs of the new EDU RC. The old EDU controller could be controlled remotely with the OI.

The Relay Outputs only convey an on/off control, therefore only your joystick switches would work. If you could convert the PWM outputs from the old controller to the correct voltage levels, then perhaps you would have something.

[kmcclary]

Originally posted by gburlison
If you could convert the PWM outputs from the old controller to the correct voltage levels, then perhaps you would have something.

There is some serious misinformation going around here...

I've personally scoped some of the signals out of the 2003 RC, AND I talked to IFI last year about interfacing other things to PWM outputs, so I have an idea of what the output driver looks like electrically.

The old (2003) RC *is* using 5V PWM signals. Though the driver chip is CAPABLE of higher voltages independent of the logic supply, they've tied the "load" power AND the "logic" power BOTH to +5V.

We're not sure about interfacing the NEW (2004) RC to the EduBot CPU though, as they won't guarantee ANYTHING about IT other than "It will not be compatible at ALL"...

According to IFI, the problem with a 2003 RC and 2004 EDUBot CPU combination/interface lies in the TIMING of the PWM pulses.

The EDUBOT CPU assumes that you're connecting a standard R/C transmitter/receiver rig to it. That sends the pulses in a particular order, and the EDUBOT assumes that order when it is LOOKING for incoming pulses.

We're just not sure of exactly WHEN the RC generates it's PWM output signals RELATIVE TO EACH OTHER. In other words, PWM4 may NOT be generated after PWM3, and before PWM5 is sent out.

Tests at IFI have revealed that when you connect the 2003 RC to the new EDUBOT CPU, they CAN miss each other's pulses, causing erratic operation.

They're being coy about it, but I'm guessing that what is happening is a "beat frequency" problem between the RC's output sequence, and the EDUBOTs scanning sequence... I'll bet that a situation has arisen where at the time one channel of the RC is sending its PWM, the EDUBOT isn't looking at that input AT THAT TIME. So, by the time it DOES sync up and gets a particular channel, either the Victor or Spike already has timed out and shut down, or the EDUBOT input routine has timed out, assumed that there's no signal there, and starts sending a "127" or some such thing...

Either way, you'd get "glitchy" operation. Sometimes they catch each other and work right, and sometimes they're "syncopated" and won't see each other...

IFI says they WILL be coming out with an App Note shortly on their website specifying the EXACT order to connect channels between the two to help avoid this. But, THEY haven't debugged any particular combination yet, so even THEY aren't sure if it WILL EVER work right. Hence, the warning.

However, they HAVE said that the NEW (2004) RC will NOT be compatible at ALL with the Edubot CPU, but they refuse to say WHY.

So... If you want to get a JUMP on this, try THIS experiment: Scope out the 2003 RC's outputs with a dual trace scope, and post here the ORDER in which it sends it's PWM signals out. That's the first step in tying the two devices together.

Next, determine if that order is CONSTANT. If for example we have two "banks" of PWMs generated by separate PICs in the old RC whose timing are asynchronous to each other, the order may change with time, and we're toast.

The next step will be to INSURE there's no voltage incompatibility due to ground currents. That can be done with simple resistor / zener combinations on the PWM cables, but we can talk about that later.

I'll bet though, that IF the firing order is constant, and IF we connect the RC's PWM outputs in FIRING order to PWM Input 1-8 (or 8-1) respectively, it'll work as well as it ever will.
I don't know if that'll be PERFECT though, and may still be "glitchy". It may still require a PIC (or other logic) in the middle, to buffer the PWM signals' relative timing in some way to insure every pulse is recognized by the EduBot CPU, every time.

Now whether or not a complex interface design to sync them up is worth the effort just to save the cost of a $100 radio control rig, is an ENTIRELY different question.

- Keith

[Anthony Kesich]

our team has been working on developing a way to use the old controller as a sort of decoder for the new one for about a week now an we're getting failry close. We weren't going to post anything until we got it perfected though. It really isnt that much trouble to sunc them because the default new program waits for new inputs to come in before executing the code. the only problem is the way the PWMs word with sending the signals back and forth to correct. normally it is just a machine or chip and the processor, now it will be two processors, but we think that will work out fine. We're alos working on a way to splice thw wires so as to piggyback the signal out voltage on the gound in, or eve if we need the grounds, because both will be powered. All we really need is the signal cables, but as i said, we're still prototyping but it looks optimal.

P.S. we're talking about usind the 03 EDU cpu

[Guilherme]

We sucessfully made the link between de 2003 EduRC and the new (2004) EduRC. Check this link http://www.chiefdelphi.com/forums/sh...ad.php?t=22652

It works perfect, please let me know if you have any trouble.