Off Season Project - BallBa

Well, we’re just a few days from competition (week 4 at Bayou), and between checklists, my thoughts are already in “lessons learned” mode trying to figure out how we can do better next year on the things we have not been able to do this year.

The big disappointment for me this year has been our inability to use sensors.  We never have done much with this before, so it's not really a surprise.  That said, we are doing rather better with a fully driver-controlled robot than I expected; I just hope that the polycarbonate doesn't get in the way.  Last year's driver is a senior this year, and he was beat out by two new members, so maybe we've just plain raised our driver level.

Anyway, back to improvements.  We need an off-season project that is focused on using sensors, and not too dissimilar from what we'd expect in an FRC game.  And, OBTW, if it's something useful, perhaps even marketable, that's even better, no?  As I drove back to the house for lunch (and to print up a receipt  from this summer needed for the BoM), it hit me.  

Ball-ba: A totally automated robot that fits within an 18" cube. Ball-ba prowls the school’s tennis courts to pick up balls and return them to the ball bin. For convenience’s sake, I plan to use one of our 2015 yellow totes, with vision targets in place but the lids removed, as the ball bin. In line with being an appliance, Ball-ba supports exactly four human-controllable functions: skulk along fence, prowl the fields, return to home base, and emergency all-stop.

I plan to publish the full Ball-ba rules on CD when I get them together, but I have a few questions about the control system as I write them:

  1. We use java for our programming. I understand that the roboRIO is our only option if we intend to use the 2015 programming environment. Does anyone have contradictory information?
  2. Are there any issues with using the 2014 Power Distribution Board and 12V-5V regulator box with the roboRIO? OK, 1 issue we know of: we are not yet using CAN bus, though we would like to become smart on it, and using the 2014 PDB won’t help.
  3. Is there any issue (that is, a technical issue apart from FRC rules) with leaving the CAN connections on the roboRIO unconnected?

To answer your questions in order…

  • Yes, you’ll need to use the roboRIO if you’re using WPILib Java. However, if you use the CCRE, our custom Java runtime engine that our awesome software manager Colby built, the code is identical. Not sure if you’re interested in using it, but it would make it possible to write code that runs on both the cRIO and the roboRIO.
  • Shouldn’t be a problem if you just run it off the 12V supply - the roboRIO can handle anything from 7V-18V. You could/might/probably will see brownouts if you use 5V.
  • I’m not positive, but I don’t see any huge issues with it unless you ask for CAN input that (obviously) isn’t there. Someone else could chime in - I’m not the most knowledgeable about CAN.

That sounds awesome - and it would also let us use our cRIOs for our competition prototyping, sensor calibration, and the like. Another platform to run code is always welcome.

Thank you, and please thank Colby for me.