Robot Co-Processors

[JPruim]

I have heard like, 6 different thoughts on Co-Processors, i.e. an Arduino to handle other functions, ranging from an "Absolutely!" to a "Absolutely not.", and from what I gather, the Co-Processor has to

Not drive the bot
Talk to the cRIO about any driving
Disable when Kill Switch is hit
Be powered off the Bot's power supply

Is my list correct? I'm thinking about dealing with the Computer Vision on a Co-Processor and not get asked to remove it.

[Al Skierkiewicz]

J,
The rules are very specific on this subject and sometimes change from year to year so check the robot rules after kickoff. Yes you are correct under current rules. The computer if it is not a COTS computing device with it's own battery, must be powered from the PD board using appropriate wire and breaker protection. It cannot directly affect the movement of anything on the robot but must communicate with the Crio if needed for these actions. All other rules apply and will be checked during inspection.

[Daniel_LaFleur]

I have heard like, 6 different thoughts on Co-Processors, i.e. an Arduino to handle other functions, ranging from an "Absolutely!" to a "Absolutely not.", and from what I gather, the Co-Processor has to

Not drive the bot

Correct. A co-processor may not directly control ANY output (not just the drivetrain). It may issue commands to the cRIO to execute drive functions.

Talk to the cRIO about any driving

... or any outher output it wishes to activate.

Disable when Kill Switch is hit

Not entirely true. All motor outputs must disable when the e-stop is pressed. Since the outputs are all controlled by the cRIO, your coprocessor does not need to be disabled.

Be powered off the Bot's power supply

If it is a COTS item, and normally contains it's own battery (like a laptop, for example) it need not run off of the robots battery. That being said, it will be scrutenized closely for safety and other rules compliances.


Is my list correct? I'm thinking about dealing with the Computer Vision on a Co-Processor and not get asked to remove it.

One last caveat. All of my answers are based on last years rules. This years rules may be different. Check the rules, when they come out, for compliance.

[cbpetrovic]

So, one thought that we (T166) had regarding the use of Arduino-based coprocessors is to use them to provide sensor input to the cRIO either via the I2C bus or via the RS-232 comm port. The intent is to offload the cRIO, have sensor inputs processed by the Arduino and made available to the cRIO upon request.

It's not driving any motors directly, will be obtaining power from the +5V PD.

Thoughts?

[Tom Bottiglieri]

So, one thought that we (T166) had regarding the use of Arduino-based coprocessors is to use them to provide sensor input to the cRIO either via the I2C bus or via the RS-232 comm port. The intent is to offload the cRIO, have sensor inputs processed by the Arduino and made available to the cRIO upon request.

It's not driving any motors directly, will be obtaining power from the +5V PD.

Thoughts?
The cRIO provides hardware decoding of many sensor signals while an Arduino will need to handle them with software (ex: counting encoder ticks with a counter vs servicing an interrupt to increment a variable). I'm not sure if the Arduino lends itself to improving your robot unless you are tied to the Arduino environment or want to do something that the cRIO FPGA image doesn't support.

[cbpetrovic]

Understood.

But I should have been clearer with the posting.

Legal or not?

R65, as I read it, says a co-processor is allowed.

Further, with 19-20 s/w people working on code, it's rather difficult to provide platforms for them to work with.

Arduinos are cheap.

[JesseK]

Mr. P,

Arduinos may be cheap and a good way to write software in the offseason, but I think you'll spend much more time in integration than you'd spend in just writing C++ code for the cRIO.

You could write a layer between the robot logic code and the arduino-specific code such that the robot logic code can be transferred to the WindRiver environment and compiled for the cRIO directly. That's (essentially) what we do on much larger platforms (I program submarines) to isolate software from hardware. However, there will need to be a substantial amount of testing on the CRIO platform before you can call the code reliable.

As for the teaching side of things, if you have 20 kids in software then perhaps you can come up with other tasks for half of them to do. Tasks like custom dashboards written in Java that deserialize custom packets from the robot. There's a whole side of robot-human interaction that can be explored if done properly. There's also a very large set of tools these programmers can write for your robot so that tuning PID's, limits of sensors, debug levels of files, etc, become much easier for the other programmers in Week 6.

Good luck!

[joelg236]

I just had an idea related to this... Would a rasberry pi attached to the CRIO through the bridge be legal? Would vision processing on that be practical / better than doing it on the CRIO? (ie. not disrupting driving code)

[artdutra04]

So, one thought that we (T166) had regarding the use of Arduino-based coprocessors is to use them to provide sensor input to the cRIO either via the I2C bus or via the RS-232 comm port. The intent is to offload the cRIO, have sensor inputs processed by the Arduino and made available to the cRIO upon request.

It's not driving any motors directly, will be obtaining power from the +5V PD.

Thoughts?Compared to the processing power of the cRIO+FPGA, an Arduino is pretty wimpy. Offloading sensor inputs to an Arduino won't really free up any meaningful resources that would make an additional layer of system complexity (and potential problems) worth it, especially since a lot of the heavy lifting in regards to I/O is handled via the FPGA. (Imagine all the interrupts from multiple 39,000 count-per-second encoders that the FPGA prevents!)

The only reasons to use a co-processor are for computationally intensive tasks (like video processing) or if you need additional sensor input ports beyond what the cRIO can provide.

[JesseK]

I just had an idea related to this... Would a rasberry pi attached to the CRIO through the bridge be legal? Would vision processing on that be practical / better than doing it on the CRIO? (ie. not disrupting driving code)

I'm not sure about the raspberry pi specifically as far as "better". The setup is legal, so long as the board is supplied with power from a legal source. I'll also note here that if the vision system has a tendency to dump packets and cause high latencies on the field, then the FTA will come talk to you about why there's so much network traffic (not in the rules directly -- it's more a GP thing, which IS in the rules). So at least be aware of your network impact.

We're trying an offboard processor following the whitepaper 987 put out at the end of last year so we can offload Kinect processing from the cRIO. We also have some kids dedicated to the interfacing of the 3 systems (cRIO, pandaboard, & custom dashboard). This vision system will (at a high level) not receive communications from the cRIO, but rather be a standalone processor that spits out information which will override certain logic blocks of our autonomous code. That way, [when] the vision system crashes, the autonomous code still has a default set of logic to perform (probably dead reckoning).

[Al Skierkiewicz]

I just had an idea related to this... Would a rasberry pi attached to the CRIO through the bridge be legal? Would vision processing on that be practical / better than doing it on the CRIO? (ie. not disrupting driving code)

Could be...as long as you are compliant with all other rules. Among those, direct control, power supply, and protected ports.