My team is working on implementing a Nvidia Jetson TX2 into our vision processing system, and we are working on making sure it shuts down cleanly at the end of the match, or beforehand.
My question is: Is there a WPILIB Java function which reliably finds out when the match is done? I believe there is a match time function, but what if we wanted it to shut down just as the match ended? And then legality wise, can the roborio send a shutdown signal to the Jetson after/instantaneously being disabled at the end?
I’m assuming using capacitors to delay the Jetson losing power is against the rules, as are battery packs on the robot, so we want to make sure the eMMC storage doesn’t get corrupted.
That’s a bad assumption to make! R39 this past year states:
COTS USB battery packs with a capacity of 100Wh or less (20000mAh at 5V) and 2.5 Amp max output per port, or batteries integral to and part of a COTS computing device or self-contained camera (e.g. laptop batteries, GoPro style camera, etc.) may be used to power COTS computing devices and any peripheral COTS input or output devices connected to the COTS computing device provided they are:
A. securely fastened to the ROBOT.
B. connected only using unmodified COTS cables
C. charged according to manufacturer recommendations
So that would be a completely viable method to allow you time to safely shut down the board after you got back to your pit.
If the Jetson is on a motor controller or relay (controlled through CAN, PWM, or the relay port, that is), it will automatically have power cut at the end of the match.
I would consider implementing a button on the dashboard which sends the shutdown signal to the Jetson. My concern with an automatic system would be that it could shut down in the event of a field fault at or before match start. Assuming that the only way to boot the Jetson is with a power cycle*, it would then be out of service for the match. You’d just have to train your drive team to hit the Jetson shutdown button before closing the driver station laptop or powering off the robot.
Another possibility would be to mount the Jetson’s filesystems as read-only. As long as there aren’t any in-progress writes, unexpected poweroff shouldn’t be much of a problem. Of course, if you wanted to e.g. write to log files, they’d need to be on a separate, read-write filesystem (flash drive?)
That being said, it’s entirely legal to use the RIO to send an automated shutdown signal to the Jetson after the match ends. AFAIK, the RIO user code can do whatever it wants; I think the enable/disable logic is deep in the FPGA somewhere and can’t be affected by user code.
*However, I’ve given thought to controlling the Jetson’s power button signal from a DIO on the RIO…
I would not rely on this behavior. Driver Stations automatically execute a DHCP release at the end of every match effectively disconnecting them from the robot.
ext4 is pretty good about not being corrupted due to ungraceful shutdowns, and afaik, the only data you’ll lose are things that haven’t been flushed to disk yet. It’s possible that you don’t need to worry about it at all.
Alternately if you want to be uber-sure, you could keep track of the transition between teleopPeriodic and disabledInit, then hook up a Runtime.getRuntime().exec('ssh user@jetson “shutdown now” ')
Thank you for pointing this out! I was reading a 2016 Cheif Delphi article which was discussing a, apparently outdated, rule banning external power banks. I should have looked more closely at the rules. Sorry about that.
As to the other replies, thank you. I’m glad to know its perfectly fine. I know the Jetson is a little more robust than a Raspberry Pi, as team 254 has talked about having to have extra SD cards to replace corrupted ones.
I can’t think of a reason why anyone would power a Jetson (or any COTS compute device) off of a motor controller instead of just wiring right to the PDP or VRM.
It’s certainly not common, but I we have put custom circuits on spikes and I once saw one on a motor controller. It is also possible to use that automatic cutoff to start an orderly shutdown. Not the best way imo, but a viable one.
Don’t feel too bad, it just changed this year, and even though lots of folks thought it would have been super useful in previous years, my feel was that the change went fairly unnoticed and underutilized.
Watching for the transition from IsOperatorControl()==TRUE to IsDisabled()==TRUE is probably pretty robust. Remember most matches have a short blip of disabled between auto and teleop, so you probably shouldn’t just look for IsDisabled().
Also remember that when doing this on your practice field, you will get shutdown at the end of every match - you may need to just enable this on the field to prevent annoyance reboots.
Another idea- leveraging the battery pack rule, keep the jetson on its own USB battery pack power source. Feed the battery voltage from the robot through a resistor divider, and into a digital IO pin on the Jetson. You’ll probably want a pull-down to the Jetson’s ground too. Read this pin in some loop on your software. If the pin goes low for more than a second or so, you can assume the robot was powered off, and the Jetson should do so as well, from a software initiated command. Bonus: Keep said USB battery pack charged up off of robot power with something like this. As far as I can tell it should be legal?
This will also trigger if your robot is disabled for any reason during teleop, even temporarily (e.g. if your radio loses power, or possibly if the roboRIO browns out). You might be able to check the remaining match time as well to avoid that, but if your robot loses communication near the end of the match, that could fail to trigger.
Maybe you could have a (fallback?) physical way to control this - there’s an way to get the state of the User button on the roboRIO, for example (under RobotController in at least C++/Java/Python). You might be able to connect a physical trigger to the Jetson as well.
