Re: Offboard coprocessor!
 

2 reasons to use the PIC

1) The student who did it had some PIC experience and wanted to add a bit of interesting control circuitry. This also provides an example for future robots.

2) We were worried about the interrupt overhead from the impellers spinning at over 2000rpm. We did do a pass through mode so that (if there was a problem with the sensor PIC) we could hook the sensors up to interrupts 5 and 6 and do everything in the RC.

The off board PIC can determine the speed on every revolution by measuring the pulse width. The sensor
sees one high and one low every revolution.

We also thought about routing the GTS signals (from our robot drive system) through the PIC (or a similar device) to get the drive rotational direction since measuring the GTS pulse width is difficult to do in the RC. However, we ran out of time to do that.

Re: Offboard coprocessor!
 

If your going to go through the effort of adding one, why not make it forwards-compatible? Sure, you might not need 400mhz of computing speed now, but what about in two years.. Wouldn't it then be a waste to have to redevelop everything?

Re: Offboard coprocessor!
 

If you use the camera you are using a peripheral controller. In the 80S there was one controller chip in your car. Now, in the next century, I am sure there are at least 6 or more through out the new cars that communicate using the CAN networking protocol. My team has not utilized all of its computing power yet but ideally this would have been the way to go. Such as to off load some of the computational load for the shooter/camera combo to keep the master RC reasonably stressed. It is complex from the software standpoint particularly if you have several development environments ( IDE's, compilers, assemblers, etc.) to work with but the robot may be more effectively controlled by breaking down the control tasks and distributing the workload to peripherals closer to the effected component. Someday. LRU.

Re: Offboard coprocessor!
 

Omni style drive systems can be. Also this year, if you threw PID loops on shooters and drivetrain, exponential joystick smoothing, pots on turret elevation and rotation, light sensors for ball indexing, accelerometers for traction control and auto, camera running a turret constantly, had a killough omni drive, and tried to run it all really fast without using any look-up tables, you might run out of power. (Or have to slow down response times) Hence, the offboard processor. In fact, if you learned to use it in the offseason, the offboard processor might speed up your programming, by letting you do quick and dirty solutions instead of having to optimize.

Re: Offboard coprocessor!
 

I use an offboard coprocessor for ease of programming and added horsepower. The PIC18 C is really too troublesome to write stereoscopic vision routines in, never mind powerful enough to execute them. For Manchester regional, what I got working was a really simple trig-based binocular vision scheme, a complete and total hack using two cameras, the light, and a gumstix. The reason I could use such a trig-heavy approach was the gumstix, you need lookup tables for that on a PIC, and using the actual functions would really slow you down.

For nationals, I'm working on implementing true binocular vision on the gumstix/cmucam array, along with the "light hack" for easy aiming. I might end up adding a third cmucam, I'm not sure. But this opens up all sorts of fun possibilities... In auto, stereoscopic vision combined with a good positioning system can lock on to, track, and ram an enemy bot. When I'm done and it doesn't look stupid anymore, I'll post the code for that.

(Also, the gumstix runs linux. Linux programming environment = wonderful. You can only program a PIC using clunky wine wrapperthings in linux. This way, there's the one PIC code that works and then you're done messing with that, its just easier to work with two linux systems and two REAL implementations of gcc, not PIC18 special C)