Re: Using an Operator Interface with the 2004 EDU RC wirelessly
 

I got it! It´s working know.

We have no AC adapter to our OI, so the used voltage was somehow making the communication between the Internal Radio and the RS-422 Data Modem fail.

I made an Y cable to turn on both EduRC at the same time.

I made some modifications to the code, just to test. But the code available to download works perfectly!

Thanks all for your help! You´re great!

Re: Using an Operator Interface with the 2004 EDU RC wirelessly
 

Could we not just plug in the 2003 radio modem directly into the 2004 EDU/Full-Size RC?

Of course, we'd need to know the 2003 communications protocol to write the receiving code in C. Is this documented anywhere? Better yet, is anybody working on this?

This would be a good engineering challenge for the students.

Re: Using an Operator Interface with the 2004 EDU RC wirelessly
 

The reason we chose not to solve the problem this way is that it would be significantly more complicated for other teams to duplicate. The radio modems use RS422, so a converter would be necessary to get either an RS232 or TTL signal to hook up to the 2004 EduRC. Additionally, the radio modem requires an input that toggles it between command & data modes, which would have to be hooked up to a digital output on the Edu. Finally, the OTA (over-the-air) protocol is only partially documented for RC->OI communication and entirely undocumented for RC->OI. Also, using the old Edu provides an easy way to set the team number =) (otherwise it would probably have to just be a constant in the software).

Re: Using an Operator Interface with the 2004 EDU RC wirelessly
 

We won't know until Saturday about the full-size controller, but as for the EDU...

The reasons that you can't plug the 2003 modem into a 2004 EDU are

1. It doesn't have a modem port.
You could create an external box that converted the serial signal of the modem to the inputs on the EDU. This would require a relatively simple microprocessor circuit.

2. You can't plug it into the serial port because the voltage levels are incompatible.
You could create an external box to shift the level of the modem signal, then plug into the serial port, and write some interface code to process the signal.

While both workarounds are good challenges, Dave's solution was designed to be a quick, low cost for teams that have a 2003 EDU, but do not have the resources to design the necessary interface circuitry.

I would imagine that at this stage in the game that most teams would be more interested in exploring how to write functioning C code than creating interface modules.

EDIT: Dave beat me to the punch in replying, sorry for the duplication

Re: Using an Operator Interface with the 2004 EDU RC wirelessly
 

Don´t forget that the 2003 EDU has an internal modem, so it´s not necessary to use the any other radio.

Just build one cable, inverting ports 2 and 3 as said in this topic, and it´s all set! Just download the code, turn on the Operator Interface with the radio, and the 2003 EDU will trasmit data to the 2004 EDU. Simple serial communication, that´s all.

Re: Using an Operator Interface with the 2004 EDU RC wirelessly
 

Why not connect the PWM outs from the '03 EDU to the '04 EDU PWM ins? Basically do the same thing you already are, just remove the programming hassle. The only thing I don't know is what wires to connect (Ins are 3, outs are 4). The volatages should be safe (The hobby recievers only use up to 6v, the IFI EDU motors are expecting 5.5v to 8.6v).

Re: Using an Operator Interface with the 2004 EDU RC wirelessly
 

According to IFI, connecting PWM OUTs to PWM INs may cause unreliable operation, and as of now they're not guaranteeing it.

I talked to IFI tech support about this last fall. The stated reason this may be unreliable is that the CPUs implement PWM OUT with separate hardware, and PWM IN by a scanning technique. IOW, the PWM outputs don't all come out at the same time, and the PWM inputs are checked one at a time.

AFAICD, the real problem is that PWM IN is NOT an interrupt based technique. The CPU has to wait for data input, and if asked to wait too long simply assumes the line is unconnected and ignores it.

According to IFI, the asynchronous nature of this CAN make things unreliable. It WOULD be OK however, IF your order of checking things MATCHES the order in which it is SENT. Otherwise, in certain input/output pairings, you COULD end up with either "old data", or consistently missed data on specific lines due to timeouts from asking it to wait too long and the '04 CPU assumes the line is unconnected.

There's a couple of ways this can become an intermittent problem:

1) The PWM IN on the '04 EDU scans the inputs in order (R/C radio decoders send out their pulses one at a time, in order), and the '03 PWM OUT does NOT send them out in order, causing missed data in SOME pairing cases.

2) We may hit INTERMITTENT timeouts in some data cases. Bear in mind that the data is encoded by pulse WIDTH (PWM = "Pulse WIDTH Modulation"). IOW, for example in a wiring that makes a marginal timeout situation on channel 6, if channels 1-5 ALL have long data (2ms end of the 1-2ms scale), the cpu may be waiting too long for input of data on channel 6, and timeout OCCASIONALLY. I don't know if this IS the case here, but it is a known potential problem with CPU scanned techniques of R/C systems, that would need to be verified by IFI.

Now IFI said that the solution was that THEY would need to tell us how to match the firing order of the PWM OUTS with the scanning order of the PWM IN. However, they refused to state what that WAS at that time, since they'd have to VERIFY it, and they were too busy right then trying to get ready for Kickoff. They DID promise me that "when they had time" they'd review the situation and put out an app note outlining the EXACT pairings to GUARANTEE reliable operation. <Checks IFI site> I see they still don't have that in their doc, whitepaper, nor FAQ areas yet, so either they haven't Gotten a Round Tuit yet, or it simply never worked for THEM.

If IFI isn't going to document this, and you DO wish to try this technique, what we'd need to do is to figure out if such a matching is possible, or if the '03 CPU changes the PWM OUT firing order with time because of multiple pieces of asynchronous hardware driving the PWM OUTs, introducing the POSSIBILITY that things would run fine for a WHILE, yet may suddenly flake out on you LATER. (I hate those kinds of "bugs"..)

A test for you: Has anyone 'scoped the '03 PWM OUTs with a multitrace oscilloscope yet, to get a sense of the order in which they fire? If so, please comment on that.
If you decide to try this test, put the EDU on a power supply, reboot it a few times to see if the order changes, and also leave it running for a few hours (or days) to see if the order changes over time (both tests help detect two or more asynchronous pieces of hardware sending data out on different ranges of PWM OUT lines).

*IF* a consistent firing order can be determined, simply match it. I'd assume the '04 CPU most likely scans the PWM inputs in order. That's the simplest case.

If the firing order is NOT consistent (changes with time), the ABSOLUTE worst case scenario I can think of is it will take a piece of hardware to capture all PWMs regardless of order sent, and either "regenerate" them in an order that the '04 CPU is happy with, or simply sends the data in via the serial port to the '04 EDU. (IOW, another PIC in between them...) I hope it won't come down to that, though...

But, is this even worth the time? Short of reverse engineering the interface and firmware (IFI won't release schematics nor internal code), if IFI won't even guarantee consistent operation, I'm not sure this is a smart way to interface them. You could have a robot that goes out of control on occasion.

Didn't someone get a '03 EDU / '04 EDU combination running RELIABLY last fall with a serial technique? I thought someone tied the two serial ports together and ran a small program in the '03 that shoved the data out the serial port to the '04 EDU serial port, but I never saw the code posted for it. If so, let's stop wasting time with this whole PWM OUT/IN interface technique.

Can someone simply please point us to the wiring AND the code required on both CPUs to go serial?

Thanks!

- Keith

Re: Using an Operator Interface with the 2004 EDU RC wirelessly
 

Dave Flowerday published the code and interface in the first post of this thread.

Re: Using an Operator Interface with the 2004 EDU RC wirelessly
 

Ah, thanks Sean! I didn't spot the code link when I read it last fall. (Duh... 4 months back, but same thread no less.) I'll need to try it.

Now *I* am confused... If Dave's serial method is working, why oh why are people still attempting PWM interfacing??? That's messy, more wiring, special connectors, prone to noise, AND may have timing problems.

As long as the data rate is decent (and the CPU overhead to service it is low), serial is a much more reliable method, AND less wiring is required.

Is there some drawback to Dave's way that I'm not seeing that's prompted more experimentation?

- Keith

Re: Using an Operator Interface with the 2004 EDU RC wirelessly
 

Simple: Dave's method requires special coding (as he says: there is easy way to read what's coming in from the port), not to say we can't get used to it. If the PWMs can be connected correctly, we can bypass that.

Is the fourth wire (orange) related to timing? or is it another power source?

Re: Using an Operator Interface with the 2004 EDU RC wirelessly
 

It's another a battery power lead.

Black = Ground
Red = +Battery (not required for Victors)
Yellow = PWM Control (1-2 ms positive going PWM signal)
Orange = +Battery

See page 8 of the the "2004 EDU Robot Controller Reference Guide" for a pictorial of the pinout.

I simply assume the orange lead is most likely a higher current capacity "Raw Motor Power" lead for the servo (vs a low current "Logic Power" wire or PCB trace that may or may not be regulated), but I haven't broken any seals nor set up any voltage and current inline tests yet to confirm that.

- Keith

Re: Using an Operator Interface with the 2004 EDU RC wirelessly
 

Thank you!

Re: Using an Operator Interface with the 2004 EDU RC wirelessly
 

Well, now that we know what the real code looks like, it should be easy to redo my code so that it's transparent to the rest of your code. At the time though I didn't know what the real code was going to look like. Unfortunately, I don't have time to do this right now, but maybe someone else could. Basically, I'd just override the Getdata() function that goes and grabs the data from the '03 EDU and returns it in the same struct as the real 04 controller uses. It shouldn't be hard to do this so that the same code will work on either the EDU or the real controller.

Also, the advantage of using this serial method is that you can get the OI digital switches, enabled/disabled bit, etc. as well. If you just use the PWMs, you'd either have to settle for no buttons from the OI or you'd have to make software changes to send the button values over a PWM.

Re: Using an Operator Interface with the 2004 EDU RC wirelessly
 

Good point.

Re: Using an Operator Interface with the 2004 EDU RC wirelessly
 

Oh ick, that's right, we also need those switches.

It's sounding more and more like short of simply buying another 2004 RC, the serial hack is the best way to approach this one.

Well, as long as one can keep the support software "canned" in its own area/module (or via block commenting out), and/or can hook a few places, it'll be fine. This could get hairy though if you have to keep tweaking a lot of lines buried in the code to keep the two versions in sync. You just don't want "support" to imply "two completely different versions".

Forgive me if this is a dumb question, but I've been swamped with other areas this year, and haven't looked at the MapLab environment yet (nor had a chance to wade through Dave's code yet...): Does the MapLab/C18 compiler environment support any kind of "conditional compilation", so you can easily maintain one piece of source for BOTH the EDU and RC targets? If so (and it hasn't been done yet), can we simply get around this potential "two version problem" before MAKE, with one combined piece of code, and a single IFDEF style switch somewhere???

Comments, from the guys that know the environment better?

- Keith