Thanks for posting these. A few things (that may have already been addressed by someone, but I couldn’t find anything):
-Now that the shells are more or less finalized, any idea when we might get CAD files or interface drawings to plan for fasteners and layout? Schematics, meanwhile, I can understand not being available until almost kickoff.
-Not sure if data on this already exists. Has anyone done testing on when the regulated VRM outputs drop out? Also, do I understand correctly that the rRio does not have a regulated supply, and therefore is sensitive to all battery fluctuations? Probably this isn’t an issue since it runs down to 7V, but any testing and data on this would be great, too.
Edit: nevermind, this isn’t really that important
[strike]-Any option for (regulated) 24V outputs? (for special sensors, etc. not just from 24V solenoids) I suppose the 2015 rules will dictate if it’s legal to use the PCM for this purpose (I suspect not). This has not been available in the past either, but it might be nice …[/strike]
There’s lots of good suggestions for tests over in this thread, in particular concerning I/O timing and how I/O performance depends on voltage outages, brownouts, etc., as well as other concerns about real-time performance. Does anyone know if there is data or testing on any of this posted somewhere?
is probably pretty close to what you are looking for. The cRIOs used by FIRST are very similar to the 9074, and the roboRIO is very similar to the 9068. There are other white papers that discuss the scheduler and other aspects, but this is the first one I located that had benchmarks.
Just saw your other question. I think it is more appropriate to say that the roboRIO doesn’t require an externally regulated supply. The supply of the cRIO and roboRIO were both internally regulated, but the cRIO levels didn’t match what was available on a FIRST robot. The roboRIO’s internal regulation was designed so that the roboRIO can be connected to any 12V PD circuit. I’m pretty sure the rules will specify that you use the blue circuit on the end of the PD, though.
Thanks for the link. I’ll give that a read. I’m sure the roboRio will be required to be on the 10A fused connection for protection.
I believe the old PDB kept the 24V supply up with a battery even as low as 4V (or maybe I’m making that number up). When it says the roboRio minimum is 7V, is that the same sort of bottom end for the regulator inside? The battery pretty much never drops below 4V, but can certainly get pulled below 7V if several things are going wrong at the same time, and I’d hate to add a controller reboot to the list of consequences. How does roboRio brownout/reboot compare to that of the regulated supply on the old PDB?
The brownout behavior and voltage levels were a major testing area of the alpha. I’ll let the alpha teams describe the details.
The goal is to keep the controller from rebooting for as long as possible. This includes having the motor controllers and possibly other components shut down when necessary to keep power to the roboRIO. It may be tweaked further during the beta, and again, I’ll let the teams describe their experience with it.
Any reason a backup battery wasn’t implemented for this? I believe this was the exact reason it was included in the old IFI control system. I understand why it wasn’t included with the cRio, but the RoboRio is a custom unit.
I hated the IFI backup battery.
It was another thing for teams to keep track of and charged without an easy indicator of when it was depleted or the contact was bad.
They always seemed to be dead for 50% of the teams I helped at events.
Everything is a solvable problem. It’s the perspectives that differ.
From one perspective the best solution was to be rid of the added operational complexity and make the system more tolerant to low voltage conditions.
When the voltage gets that low, the robot is not going to be going anywhere anyway.
Seconded for truth! That backup battery was a big pain to keep track of… One of our mentors ended up designing a charging circuit for it our second year, so it could stay charged off the main robot battery during competition.
I wouldn’t necessarily say the robot wouldn’t be going anywhere. It could simply be because of large current draw from drive motors, not that the battery is dead. Waiting for the roborio to reset after that is a real killer. Could the solution be to just add a good sized capacitor across the power inputs?
If you really have this problem then an easier solution might be to have your software check voltage and limit your power draw as it approaches the low end.
Both the cRIO and roboRIO designs cut your motor draw when the voltage drops too low, but if you have really severe power problems then you can implement your own smart power management.
The alpha teams at the second weekend event were actively trying to reset, pushing walls for extended periods of time. We were happy with how it behaved, but they decided to tweak a few things in the FPGA. I’m anxious to see how the beta teams do.