Offboard coprocessor!

[Ben Englert]

I am hell-bent on using an offboard coprocessor with the FRC next year because I'm sick of lookup tables that need to be regenerated every time hardware changes (although perl does expedite that process).

I've read the documentation for the Gumstix series of Linux single-board computers, as well as all of the Adambots' "Delta Force Coprocessor" material, and the FIRST rules regarding custom circuitry. I am about ready to take home an RC and order a Gumstix and get going.

I'm just wondering if anyone has any experience with this that they'd like to share.

[mogunus]

I am hell-bent on using an offboard coprocessor with the FRC next year because I'm sick of lookup tables that need to be regenerated every time hardware changes (although perl does expedite that process).

I've read the documentation for the Gumstix series of Linux single-board computers, as well as all of the Adambots' "Delta Force Coprocessor" material, and the FIRST rules regarding custom circuitry. I am about ready to take home an RC and order a Gumstix and get going.

I'm just wondering if anyone has any experience with this that they'd like to share.

I used a gumstix to do binocular vision this year. They're AWESOME, and they work great. I'm putting together a wiki page on the gumstix tikiwiki, explaining everything, and I'll have my code up on their subversion repository soon. I'm also developing a wifi positioning system, using gumstix. All that info will be there too.

[Mike]

Unless you're really doing some hardcore stuff, I don't think a gumstix is necessary. Look at the Atmel AVR series, specifically the ATMegas. An STK500 development kit can be had for $80 and includes everything to get started. Someone likened it to a Swiss Army knife for microcontrollers, and I agree.

Atmel STK500 (http://www.atmel.com/dyn/products/tools_card.asp?tool_id=2735)

[coldabert]

I would love to know what sort of programming you have that requires that much additional circuitry and time. Dont forget rules about using items from previous years, you wouldnt want to have it rejected by inspectors after that much. Not to mention the costs of development hardware.

[Joel J]

There is a $50.00 demo board from microchip that actually includes the 18f8722.. its fairily small, and very useful..

http://microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en022480&part=DM183022

[Greg Marra]

Don't forget, those EDUBot controllers run pretty much the same hardware as the pre-06 RCs. They can be hooked up in parallel to your main RC to do some computations.

[Dave Flowerday]

Don't forget, those EDUBot controllers run pretty much the same hardware as the pre-06 RCs. They can be hooked up in parallel to your main RC to do some computations.
...except that the EDU-rc is illegal for use in FRC competitions, since it is a COTS electronic item costing more than $200.

[Greg Marra]

...except that the EDU-rc is illegal for use in FRC competitions, since it is a COTS electronic item costing more than $200.

Whoops. I take that back :o .

[Billfred]

So is there any way to hack a Vex controller? At $149.99, they're suddenly legal under every rule I could find (provided you powered them legally).

[devicenull]

So is there any way to hack a Vex controller? At $149.99, they're suddenly legal under every rule I could find (provided you powered them legally).

Sure.. it's basically the same code running on the normal RC.. but it's the 8520, so you aren't gaining that much power for what you would have to do to interface with it.

[Ben Englert]

I used a gumstix to do binocular vision this year. They're AWESOME, and they work great. I'm putting together a wiki page on the gumstix tikiwiki, explaining everything, and I'll have my code up on their subversion repository soon. I'm also developing a wifi positioning system, using gumstix. All that info will be there too.

Am looking forward to seeing that - I'm already in contact with the Adambots who are successfully using a Gumstix this year, and they have pointed me to their SVN repository as well. Their programmer mentioned that it would be really cool to have all teams using this collaborate on it. I definitely agree!

Please do post us a link when you have one.

[ericand]

Team 1425 uses a PIC processor to controll the speed of the ball shooter this year. The shooter has two impeller wheels that give the ball its velocity. Our aiming depends on the shooter having a constant velocity as close to the limit as possible.

The PIC processor uses digital I/O to provide 2 bits of info for each impeller. The code on the robot controller uses 3 of the 4 possible
combinations to tell if the impeller is {too slow, on speed, too fast}

The robot controller uses this info to determine if/how to adjust the PWMs controlling the impeller motors.

[Doug G]

Team 1425 uses a PIC processor to controll the speed of the ball shooter this year. The shooter has two impeller wheels that give the ball its velocity. Our aiming depends on the shooter having a constant velocity as close to the limit as possible.

The PIC processor uses digital I/O to provide 2 bits of info for each impeller. The code on the robot controller uses 3 of the 4 possible
combinations to tell if the impeller is {too slow, on speed, too fast}

The robot controller uses this info to determine if/how to adjust the PWMs controlling the impeller motors.

We do the same thing with our shooter, but just simply use a couple of encoders connected to the RC and Watson's velocity PID code with some tweaking of the constants and are getting pretty good results. So why use the separate PIC?

[Gdeaver]

I'm curious as to why there is a need for a powerful coprocessor. I can see using a small PIC for a sensor that requires I2Cc or SPI interface since we don't have access to the hardware on the robot controller. This year the camera certainly didn't overwhelm the processor. There are more limitations in the actual camera hardware and firmware. So why the need for a powerful
coproc? Are our games complex enough to justify one?

[fowlerm]

We are using a 400MHz Gumstix running Windows CE 5 for our drivetrain/positioning system and target acquisition, but we didn't have it on the robot at UCF. It will certainly be there for Nationals.

[ericand]

We do the same thing with our shooter, but just simply use a couple of encoders connected to the RC and Watson's velocity PID code with some tweaking of the constants and are getting pretty good results. So why use the separate PIC?

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.

[devicenull]

I'm curious as to why there is a need for a powerful coprocessor. I can see using a small PIC for a sensor that requires I2Cc or SPI interface since we don't have access to the hardware on the robot controller. This year the camera certainly didn't overwhelm the processor. There are more limitations in the actual camera hardware and firmware. So why the need for a powerful
coproc? Are our games complex enough to justify one?

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?

[lupjohn]

We do the same thing with our shooter, but just simply use a couple of encoders connected to the RC and Watson's velocity PID code with some tweaking of the constants and are getting pretty good results. So why use the separate PIC?

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.

[lukevanoort]

I'm curious as to why there is a need for a powerful coprocessor. I can see using a small PIC for a sensor that requires I2Cc or SPI interface since we don't have access to the hardware on the robot controller. This year the camera certainly didn't overwhelm the processor. There are more limitations in the actual camera hardware and firmware. So why the need for a powerful
coproc? Are our games complex enough to justify one?
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.

[mogunus]

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)