Quick Reboot - is it possible?

[JohnGilb]

As part of another thread, I had a thought - is there a way to very quickly restart the main robot process?

Right now, you can

• Hard reset the robot (turn the main breaker off, then on). This often takes over a minute before everything is back.
• Soft reset the robot (from the driver station, reboot the cRIO). 30-70 seconds until robot is fully operational.

But is there a way to just remotely kill the robot program and restart it? I would hope that would be much faster than either option above.

[vgdude999]

Fastest way I know of is resetting the crio with either the driver station or the reset button like you said, but it usually takes about 20 seconds, not 30-70.

[joelg236]

I think you're looking for a way to "reset" your program without rebooting the crio. As far as I know, this isn't something built in. You could do this in software in a few different ways though.

[JesseK]

To give you an idea - I have yet to professionally work on a project with less than 500k lines of code.

"Quick" reboot is a myth in complex integrated applications, even in the OSGI framework. There is always something that forces a full application reboot.

[JohnGilb]

joelg236, could you elaborate?

JesseK, I think I don't understand what you're saying. I would like to restart the process (or process analogue on the cRIO, whatever that is) without rebooting the entire OS. When you say "application," what are you referring to?

[Aaron.Graeve]

For 99.9% of FRC teams, a quick re-loading of the code is not possible. This is due to the user code running in kernal space in VxWorks (the operating system for the cRIO). For thise not familliar with the term, the kernal is the core section of the operating system that mediates between software applications and hardware/drivers. Whenever the user code changes and needs to be restarted, the whole kernal needs to be removed from memory and reloaded. That takes time. It is the equivalent of rebooting your computer everytime you want to start Steam. This is not the best way, and is probably not the the smartest way, but it is the only way as of now. Rumor from the roboRIO alpha testers says the reboot time is very low now. Chatting with Greg McKaskle from NI a few months ago, he mentioned there was some thought of moving the user code from kernal space to user space (reloading only the robot code instead of the whole kernal everytime a code change ocurrs). My guess is that change is what is decreasing the reload time.

For the .1% the reboot is not nesessary. I trust some team(s) have figured out how to have a script file on the cRIO that contains the logic thand IO configuration they want to run in the robot. It would get a bit wierd with the FPGA and encoder inputs, but it would be possible. For these teams, changing code would be as easy as changing the file, FTP transfering it over to the cRIO, and sending a command to the cRIO to read the file and use the logic contained within.

This is just what I know. If any of the software giants of CD wish to elaborate on, correct, or discuss this post, feel free.

I did not expect the post to grow this large. My apologies about that.

[Jared Russell]

While it would be nice during debugging and integration to be able to just FTP a new executable and say "GO!", the seconds that this would save us don't justify the effort of making it so.

Many teams already use scripting tools for things like constants and autonomous modes. This lets you use a workflow of:

1. Edit on laptop.
2. FTP to cRIO.
3. Send reset signal (ex. a button press during Disabled) to re-load file.
4. GO!

This pattern lets you realize most of the benefits of a quick reboot (plus other benefits) without having to dive into system-level code.

[Fletch1373]

Originally Posted by Aaron.Graeve

For 99.9% of FRC teams, a quick re-loading of the code is not possible. This is due to the user code running in kernal space in VxWorks (the operating system for the cRIO). For thise not familliar with the term, the kernal is the core section of the operating system that mediates between software applications and hardware/drivers. Whenever the user code changes and needs to be restarted, the whole kernal needs to be removed from memory and reloaded. That takes time. It is the equivalent of rebooting your computer everytime you want to start Steam. This is not the best way, and is probably not the the smartest way, but it is the only way as of now. Rumor from the roboRIO alpha testers says the reboot time is very low now. Chatting with Greg McKaskle from NI a few months ago, he mentioned there was some thought of moving the user code from kernal space to user space (reloading only the robot code instead of the whole kernal everytime a code change ocurrs). My guess is that change is what is decreasing the reload time.

For the .1% the reboot is not nesessary. I trust some team(s) have figured out how to have a script file on the cRIO that contains the logic thand IO configuration they want to run in the robot. It would get a bit wierd with the FPGA and encoder inputs, but it would be possible. For these teams, changing code would be as easy as changing the file, FTP transfering it over to the cRIO, and sending a command to the cRIO to read the file and use the logic contained within.

This is just what I know. If any of the software giants of CD wish to elaborate on, correct, or discuss this post, feel free.

I did not expect the post to grow this large. My apologies about that.

As a CSA at champs, I had plenty of opportunities to play with the roboRIO that NI had set up. One of these tests was a boot time test. With a stopwatch app, we discovered that it still takes approximately 22 secs to boot to a state where the networking process is running, and an additional 3-4 seconds(totalling ~25s) for user code to finish loading. This was done with 2014 cRIO firmware ported to the roboRIO, and as such, isnt a perfect representation of how it will work next year.

[Aaron.Graeve]

Originally Posted by Fletch1373

As a CSA at champs, I had plenty of opportunities to play with the roboRIO that NI had set up. One of these tests was a boot time test. With a stopwatch app, we discovered that it still takes approximately 22 secs to boot to a state where the networking process is running, and an additional 3-4 seconds(totalling ~25s) for user code to finish loading. This was done with 2014 cRIO firmware ported to the roboRIO, and as such, isnt a perfect representation of how it will work next year.

Was this test run with the roboRIO powering up or was it already on (i.e. hard reboot vs soft reboot)? Did the test you see require a full reboot after loading code? My message was more directed at the time to load and run code after the roboRIO is already running and was based on what I have heard. I wanted to be at Champs this year so I could talk to some of the alpha testing teams in person, but college work prevented me.

Even considering, a ~25 seconds from boot to code running is very nice and better than what we have now. I have hope the roboRIO firmware will reduce this time even further. (Keeping my fingers crossed for user code in user space)

[vgdude999]

Originally Posted by Aaron.Graeve

Was this test run with the roboRIO powering up or was it already on (i.e. hard reboot vs soft reboot)? Did the test you see require a full reboot after loading code? My message was more directed at the time to load and run code after the roboRIO is already running and was based on what I have heard. I wanted to be at Champs this year so I could talk to some of the alpha testing teams in person, but college work prevented me.

Even considering, a ~25 seconds from boot to code running is very nice and better than what we have now. I have hope the roboRIO firmware will reduce this time even further. (Keeping my fingers crossed for user code in user space)

During one match our power wire for our crio(8 slot) became loose. It rebooted several times because the wire kept making and breaking contact. I noticed that it was somewhere around 20-30 seconds reboot time. 25 seconds isn't really an improvement, so I hope that time was strongly influenced by the fact that the test was done using ported firmware.

[Fletch1373]

Originally Posted by Aaron.Graeve

Was this test run with the roboRIO powering up or was it already on (i.e. hard reboot vs soft reboot)? Did the test you see require a full reboot after loading code? My message was more directed at the time to load and run code after the roboRIO is already running and was based on what I have heard. I wanted to be at Champs this year so I could talk to some of the alpha testing teams in person, but college work prevented me.

Even considering, a ~25 seconds from boot to code running is very nice and better than what we have now. I have hope the roboRIO firmware will reduce this time even further. (Keeping my fingers crossed for user code in user space)

The test was run as a hard reboot with existing code on the robot.

[tech2077]

Originally Posted by Aaron.Graeve

Was this test run with the roboRIO powering up or was it already on (i.e. hard reboot vs soft reboot)? Did the test you see require a full reboot after loading code? My message was more directed at the time to load and run code after the roboRIO is already running and was based on what I have heard. I wanted to be at Champs this year so I could talk to some of the alpha testing teams in person, but college work prevented me.

Even considering, a ~25 seconds from boot to code running is very nice and better than what we have now. I have hope the roboRIO firmware will reduce this time even further. (Keeping my fingers crossed for user code in user space)

From research on the new roboRIO, as it runs a linux distro with real time extensions, in addition to the changes in the programming environments to be fully user level (such as now using Java SE) the robot code will be running as a userlevel application under the linux kernel, now allowing for fast software soft-loading which is as simple as restarting an application.

[Cel Skeggs]

Originally Posted by tech2077

From research on the new roboRIO, as it runs a linux distro with real time extensions, in addition to the changes in the programming environments to be fully user level (such as now using Java SE) the robot code will be running as a userlevel application under the linux kernel, now allowing for fast software soft-loading which is as simple as restarting an application.

I went to one of the booths at the World Championships, and they had a bunch of the roboRIOs there. Brad Miller (the person in charge of WPILib) showed that with the new version, it would take ~5 seconds from pressing download to having the new code running. It's MUCH better than it previously was.

[JohnGilb]

This has been a really productive and interesting conversation - thanks to everybody for the valuable feedback! I was under the mistaken impression that our code ran in user space - to learn otherwise was valuable.

Looking forward to the 2015 control system!