FRC hardware design

[Gdeaver]

I've been looking at the IFI FRC hardware and software and wonder if anybody else has questioned why they designed it as they did. What I don't like about the current programming model is the 2 threads of execution. We have the main loop and the fast user loop. This ties up a timer and results in a high priority interrupt. The 2 things that drive this are the processor to processor communications and the servo output refresh. The other thing is the I2c and SPi port are not available for our use. There are allot of sensors that could use this port. The whole programing model just seams to complex for what it has to do. I bet the easy c people had a good time making sure they could model it.
I've looked at some other robot controller designs. Nobody else has gone down this path that I have seen. Most are a master proc with a coprocessor bus.
Wouldn't the hardware software model be easier if the FRC had one main processor and a buss (rs485,can,rs232, etc.) There are 2 async. ports on the current processor. One port could be used for the programming and tether. The other would be for the coproc buss. There are several companies that have programed pic 16 or 17's as servo chips with 8 or 9 servo outputs. They are controlled by simple 3 or 4 byte commands and can be cascaded. The main proc doesn't have to generate the pulses or worry about timing. This would also open up the possibility of using a motor drive coprocessor with feed back Incorporated in the coprocessor. The other thing that would need to be addressed is the modem. If the modem has built in CRC error checking the main proc could just form the packets and send and receive them async. If necessary another small pick could be added to make a modem coprocessor. This would allow future coprocs to be added to the buss for other functions and the MSSP would be available for sensors. This would allow a single threaded control structure and I believe simplify the programming and make the FRC more expandable. Any body else have an opinion on this. Maybe there is a good reason IFI did what they did but, I don't understand why.

[Alan Anderson]

I'm not sure you have a good grasp of the "hardware software model", as you call it. You're asking questions that seem to assume things are not as they are. The IFI Robot Controller system is set up as a main processor with a coprocessor. The software isn't running a "dual thread" scheme with interrupts to switch between tasks; the fast user loop is the "main loop".

The system is set up with an amazingly useful feature: hardware inputs are automagically read and made available to the program as variables, and hardware outputs are automagically generated based on variables set by the program. The minor nuisance of having to call the get_data and send_data communication routines explicitly is worth it.

One thing you're leaving out is the cost of the system. Adding "just one more small PIC" for PWM outputs, and "just one more small PIC" for modem communication, and "just one more small PIC" for a motor drive system...it adds up.

[Gdeaver]

I'm suggesting that having 2 pic 18's and the interrupt for them to talk adds complications. Having 1 pic 18 and a pic 16or two on an expandable async bus would be less complex. The main processor would have a senddata getdata function and a set-pwm function. Off loading the PWM from the pic 18's would eliminate the critical timing that is needed in the current controller. As for cost, aren't pic 18's to pic16's about 1 to 3. I would rather send a couple high level commands to a intelligent motor coproc than have to fit the pid in the current FRC and worry about conflicts with a gyro, accelerometer, other time critical sensing.

[Alan Anderson]

Originally Posted by Gdeaver

...Off loading the PWM from the pic 18's would eliminate the critical timing that is needed in the current controller...

That is taken care of in the non-user-programmable PIC. It doesn't matter whether or not the timing is critical; it is neither exposed to nor under the control of the programming we are allowed to do.

(The four PWMs which are optionally controllable by the user processor would still have to be that way in order to permit the kind of immediate control possible under the existing scheme.)

[Alan Anderson]

Originally Posted by Gdeaver

I'm suggesting that having 2 pic 18's and the interrupt for them to talk adds complications. Having 1 pic 18 and a pic 16or two on an expandable async bus would be less complex...

I'm obviously not seeing what you are. How can having more processors and a more complicated communication bus end up being less complex? Even if the additional hardware is somehow easier, how can communicating between the user processor and multiple I/O processors be any simpler than communicating between the user processor and a single I/O processor?

I don't wish to sound like I'm trashing your ideas, but I honestly don't understand how they would make things any easier than they are now.

[Rickertsen2]

Originally Posted by Gdeaver

The other thing is the I2c and SPi port are not available for our use.

Would you rather both serial ports or the I2C/SPi? Personally i find 2 serial ports alot more useful.

Originally Posted by Gdeaver

Wouldn't the hardware software model be easier if the FRC had one main processor and a buss (rs485,can,rs232, etc.) There are 2 async. ports on the current processor. One port could be used for the programming and tether. The other would be for the coproc buss. why.

Well, technically speaking it wouldn't be that hard to do all of the PWMs from one processor. The main reason for having two procs is that the user processor is designed as a "sandbox" so that no matter how hard you try, there is no way to prevent the E-stop functionality from working, the team color lights from behaving oddly etc. With two procs, all the safety critical tasks are managed by the master processor and out of the programmer's control.

[Gdeaver]

AH, Rickertsen2 you said the magic 2 words - sandbox and e-stop. I've been looking at some other controllers and they are both simpler and more extensible. However the 2 above words explain IFI' s design. Thank you.