Using an Operator Interface with the 2004 EDU RC wirelessly

[Dave Flowerday]

I'm hoping this may be of use to some teams out there who'd like to be able to control their new 2004 EDU RC with a previous year's OI. What we've done is to connect the serial port on the 2003 EDU RC to the serial port on the 2004 EDU RC, and then modified the code for each so that the 2003 EDU RC simply acts as a forwarding device to send the joystick & button data from the OI into the 2004 EDU RC. Essentially, the 2003 EDU RC becomes a fancy radio modem.

There are only 2 pieces of hardware that you'll need to duplicate this setup. First is a special serial cable to connect the 2 RCs. This serial cable needs to only have 3 wires and connect the pins like this:

2003 RC 2004 RC
Pin 2 <------> Pin 3
Pin 3 <------> Pin 2
Pin 5 <------> Pin 5

Unfortunately one of the pins on the 2003 EDU functions as a reset line, so if it gets connected to the wrong pin on the 2004 EDU then the 2003 EDU will just stay in reset and not boot up. That's why the above 3 wire cable is best. I have not tested a standard null-modem cable though, so that may work as well depending on what's connected to what.

The other thing you will need to do is figure out a way to power both EDU RCs at the same time. We did not receive a new EDU battery with the 2004 kit, so I'm assuming noone else did either. The best option for this problem is probably to order a second battery from Innovation First. Otherwise, if you're feeling adventurous, you may be able to construct a Y power cable to power both RCs from the same battery pack.

Once you have figured out how to power both EDUs and made your serial cable, then simply download the code for each EDU from the zip file I'm attaching to this post. There's an OIPassthru.bsx file for the 2003 EDU and an MPLAB IDE project for the 2004. Your own code should still go in user_routines.c or user_routines_fast.c, just like with the default EDU code.

Well, hopefully this is helpful to some teams. Please feel free to reply with questions and we'll do the best we can to get them answered.

[Skabana159]

Sounds ingenious. Thanks for the input. What exactly did you do to the code?

[Rickertsen2]

You beat me to it.

[Holtzman]

So let me get this straight.
WE cannot use the operator interface from last year with the new edu controller? or have i got this totally wrong.

[Jeremy_Mc]

Originally posted by Holtzman
So let me get this straight.
WE cannot use the operator interface from last year with the new edu controller? or have i got this totally wrong.

You can not use the full-size OI no. It will put out too much voltage and kill your 2004 edu-rc.

That's a bad thing... :(

[Dave Flowerday]

Originally posted by Skabana159
What exactly did you do to the code?
Primarily I added functions to receive data over the serial port on the 2004 EDU. For some reason, IFI provided code to send data out but didn't provide any mechanism to receive data. On top of those functions I built another function to capture the data coming from the 2003 EDU to a structure. Beyond that I just modified the Default_Routine() function to use the OI data instead of the PWM in data.

[Andy Brockway]

Thanks Dave!

We are adapting the EduRC to our 2003 robot. We built the cable and have finished the user portion of the code. This has allowed us to run the 2003 OI controls without modification. Our drivers may not even know the difference!

Our plan is to use this robot as a test bed for 2004 software development

I encourage everyone to try this!

Andy

[Dave Flowerday]

Originally posted by Andy Brockway
We are adapting the EduRC to our 2003 robot.
Sweet! Glad to hear it. We're in the process of doing the same thing ourselves. Keep us posted on how it goes!

[KevinB]

Originally posted by Andy Brockway
I encourage everyone to try this!

Team #538 has also attached the new eduRC to our bot from two years ago. Works like a champ! Now the hard part -- teaching everyone to program C (arg!)

[Kautz]

Thank you Dave

Team 1008 hooked up the Edubots. Works great

We also try to control the pmw this work as well. So we will use this set-up to test and right code for our 2 speed 2 motor air shift transmission we our developing.

Thanks !!

[Guilherme]

I´ve tried to connect the edu´s, but I had some problems.

I downloaded the program into 2003 EDU and into 2004 EDU with total sucess.

After that, I tested the communication sending pwm_03 = 250 , and engaging a servo motor into pwm03, in the 2004 EDU RC. It moved. So I tried pwm_03=127 and the servo stopped. Great, it worked.

Now, we tried to turn on the 2003 Operator Interface, in order to send Joystick data to the 2004 EDU controller (note: using 2003 radio modens). But for some reason it went crazy, and the servos didn´t respond to the joystick, they just start running at top speed, without stopping.

We plugged both RC in a main power source with 7,2 V, so it should power then at the same time.

We are trying to use TTL communication using Parallax RF modules, did anyone try to use something like this? What about the 3 pins for TTL communications, I read that there´s no custom code in the default program for it, is that true?

We have a lot of thing in mind such as: pluging joysticks in parallax boards of education. After that we plug one RF transmitter, and we use another Parallax board to receive the signal. Finally, we program the receiver board to convert the signal (in value) to PWM signal (used in the 2004 RC). This is a little harder, but it works in theory.

[Andy Brockway]

Joe,

First are you using the 2003 EduRC with its internal Modem? The cabling goes between the two EduRC's to link them serially through the DB9 ports. The RC modem is not used.

The user_routine.c file is specific about which joystick controls which pwm_out.

================================================== ==========
pwm01 = pwm03 = Limit_Mix(2000 + OIData->p1_x + OIData->p1_y - 127); /* LEFT WHEELS */
pwm02 = pwm04 = Limit_Mix(2000 + OIData->p1_y - OIData->p1_x + 127); /* RIGHT WHEELS */
pwm01 = pwm03 = 255 - pwm01; /* reverse direction of left side */


/* ------ Other PWM OUTPUT Mapping (can be used for two-joystick drive ------*/
pwm05 = OIData->p3_x; /* limited by digital inputs 1 & 2 below */
pwm06 = OIData->p3_y; /* limited by digital inputs 3 & 4 below */
pwm07 = OIData->p4_x;
pwm08 = OIData->p4_y;

================================================== ===

Plugging into pwm03 may be giving you the strange actions. The default program uses it with the mix routine. The syntax is also very picky for OIDATA->___. Also if the modem on the 2003 EduRC is not firmly seated into the motherboard you wil get erratic motion up to and including basic run and init errors.

We have successfully adapted our 2003 code and can run our 2003 robot with this setup and our 2003 OI.

Andy Brockway
Team 716

[Guilherme]

I plugged the 2003 EDU RC with the 2004 edu RC with the cables, I didn´t use the internal modem.

So the two RC are plugged with the 3-wire cable, and the OI sends data to the 2003 edu, just like you said.

Any idea of whats is causing this problem?

I just plugged a servo in pwm03 to test communication between the EDU´s.

[Guilherme]

...

The 2003 Edu RC receives data from 2003 Operator Interface. Then the 2003 Edu RC, witch is serial connected to the new Edu throught one cable (with the three wires like you said), sends the data to the new Edu RC.

Now... Is this correct? I guess so, 'cos it´s exactlly what we did.

The main question is: why can´t we control the servos attached in the pwm outputs located in the new Edu RC ? When we move the joystick we get no light blinking in the Operator Interface...

Thanks for your help, we´ll work harder in the assembly to try to figure it out our mistakes. Just let me know if you found any difficulties like ours, so we can share solutions.

[Andy Brockway]

Joe,

I am still a little confused on your set-up. What are you using for the modem on the 2003 EduRC? For your test, plug the servo into pwm08 and test with py_4, this is a direct link.

The setup that we are using is as follows:

2003 OI with its Radio Modem, Team Number set (ours is 716) per IFI instructions.

2003 EduRC with its interal modem (this is the black box with two sets of multiple pins and plugs into the bottom of the motherboard) and motherboard, Team number set to 716, switch set to 'program'. Do not use the full size RC radio modem. I think you are using the internal modem because you said you had no problem programming.

2004 EduRC

Cable between the 9 pin connectors of the EduRC's. Note- must be per this thread, note crossover between pins 2 and 3. Do not use a standard serial cable!

All pwm cables attached to 2004 EduRC.

Good Luck!

Andy Brockway
Team 716, The Who'sCTEKS

[Guilherme]

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!

[Neal Probert]

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.

[Dave Flowerday]

Could we not just plug in the 2003 radio modem directly into the 2004 EDU/Full-Size RC?
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).

[Dave Scheck]

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

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

[Guilherme]

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.

[Astronouth7303]

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).

[kmcclary]

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).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

[seanwitte]

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

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

[kmcclary]

Dave Flowerday published the code and interface in the first post of this thread.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

[Astronouth7303]

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
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?

[kmcclary]

Is the fourth wire (orange) related to timing? or is it another power source?
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

[Astronouth7303]

Thank you!

[Dave Flowerday]

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.
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.

[Astronouth7303]

Good point.

[kmcclary]

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.

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

[KevinB]

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?
Yes, this is possible. If you want, I will come up with some step-by-step directions of how to do this in MPLAB.

[Astronouth7303]

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

I've considering doing this for awhile. It's quite possible. You just have to mess with the ifi_*.h files. :Gasp!: Combine them with #ifdef's.

[kmcclary]

I've considering doing this for awhile. It's quite possible. You just have to mess with the ifi_*.h files. :Gasp!: Combine them with #ifdef's.

Yes, [combining the EDU<->EDU serial code with the standard RC code]is possible. If you want, I will come up with some step-by-step directions of how to do this in MPLAB.
Please do! I'll then pass it on to our programming staff.


I think an excellent whitepaper would be to create and document a COMBINED "Full RC Default" AND "2003-4 Edu-to-Edu via serial" emulation of the FULL RC's DEFAULT CODE.

I'll be happy to work with someone this summer on the hardware side of it.

Let's flesh this out fully. My proposed emulated rig would consist of THIS chain:

OI board:
= 2003 OI, with joysticks, and switches
= 2003 OI eWave RF Modem

Practice Robot:
= Standard kit battery, and power distribution
= A new "kit 12V gel cell to 7.2V EDU" power supply (already designed)
= 2003 EDU with internal modem, and canned code
= EDU/EDU Serial Cable (defined earlier in this thread)
= 2004 EDU, with above defined "dual" code (and same PS)
= Standard Victor cables, and custom Spike cables
= Standard Victors & Spikes
= Standard Kit motors, valves, air pump, gumball or LEDs.
(Am I missing anything???)

If you wish, for simplicity assume:

1) Solonoid Outputs => Three Full Spikes. Treat each Solonoid Output in the emulated code as a simple Spike FWD or BACK logical output. I can easily electrically convert the Solonoid outputs into three additional "simulated FULL spikes" with some cheap high current SPDT relays and kickback diodes (30A max), or better yet add a simple circuit to correctly drive three REAL Spikes from the Solonoid Outputs without damaging them.

2) LED/Gumball driver: Treat one of the Solonoid Outputs or a Digital Output as the Robot ON indicator. Your choice. I can show the interface for a simple "2004 LED Light Cluster Driver" circuit, how to drive some cheap blinky LEDs, or even add a relay driver for an old Gumball...

3) Instead of a wasting the EDU battery, both EDUs will also be run via a simple power supply, dropping down a full kit 12V gel cell to EDU voltage levels. This gets you darn close to the kit hardware, and helps avoids downtime...

Again, the above software's development goal is to create a FULL SIZE RC "Dual Default Code", where the above emulator module is PACKAGED (NOT inline edited all over the code!), and you simply change ONE 'ifdef' flag statement to toggle which hardware you'll target. Your now ONE piece of code should then be able to run either a REAL robot, or this practice bot that uses REAL kit hardware leftovers, with an EDU emulated *FULL RC*.

Yes, the EDU has limited I/O, but if done right, this SHOULD emulate anything short of a full RC with saturated I/O. IMHO, a VERY worthwhile project.


4) If the 2003 EDU's "canned code" requires customization (ex: for what vars need to be passed), it should also all be in ONE place. IMHO though, it would be nice if we could avoid that, as it requires maintaining the old Stamp environment as well...


Consider this an 'off season software development challenge'... :D

Any takers on this software assignment? I'll help write up the hardware specs (including 12V -> 7.2V power supply) if someone will fill the above software spec.

- Keith

[KevinB]

Keith, I would be willing to work on the software side of things -- I really don't think it woudl be too hard; but it would have to be sometime after this week -- too much school work!

[kmcclary]

Keith, I would be willing to work on the software side of things -- I really don't think it woudl be too hard; but it would have to be sometime after this week -- too much school work!

No rush... The crunch is over, and we can all take our time now. As I said, this can even be a SUMMER project.

Also, the more the merrier! If anyone ELSE wishes to write THEIR concept of a "combined EDU/RC Full Size Default code" for this hardware spec, go for it! There's LOTS of ways to approach this one. I'm "modularizing" the hardware (as defined above), and can support several configurations.

Besides, I wouldn't mind seeing SEVERAL approaches to this, just to see WHICH software approach turns out to be the most flexible, easiest, and/or most intuitive to use. There may not even BE a single, optimum way to split the limited resources on the EDU between analog, digital, interrupts, and spikes in software. So just because one person is taking a crack at the software, it doesn't mean that all you other bit jockeys should leave the field!

- Keith