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

Yes, this is possible. If you want, I will come up with some step-by-step directions of how to do this in MPLAB.

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

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.

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

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.

[EDIT]
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...
[/EDIT]

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

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

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!

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

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