Robot Reboot?

Hello, We have been having a major problem with our robot’s performance in competition. In last year (2013)'s competition as well as a local competition, we had the problem of our robot losing power on the field. When i go into the driver station log, it appears as if the voltage going to the cRIO is spiking and causing it to crash. But we have been told that the cRIO and/or the power going to it is probably not the main issue. In last year’s competition it would mainly happen when we were driving our robot, then activated our shooting mechanism. But at the local competition, it would happen even though we were just driving (albeit with four motors). Does anyone know what is happening/ why its happening/ how to fix it? Thank you all!

I asked one of our mentors, and he has not seen that problem, but he did suggest a few things;

  1. Check all power connections to the cRIO.
    – All connections are torqued.
  2. Use an external, handheld DMM while driving to see if there are any surges in voltage.
  3. Note any error codes before the cRIO crashes.
    – And feed them back to NI, if possible.

Why do you think the robot is “losing power”? Does it eventually come back to life, and if so, after how long?

Just to get one simple thing out of the way, describe how your D-Link router is wired to the power distribution board. There are a couple of ways to do it wrong that will result in a long-lasting loss of control when battery voltage droops.

Can you post a screen shot of your driver station log, showing an example of the problem?

Better yet, post the actual log file so we can look at it carefully.

Not sure about posting the log files, as there are so many and i didn’t keep track of the ones in which it happened, but as for the wiring of the Dlink, I think that is a good contender for what the problem may have been. It was wired into a 12 volt connection on the power distribution board, and i did some research and apparently a part that we could not identify was actually a 12 to 5 volt converter, who’s purpose is for the Dlink. Am I wrong about that? Would that not be the problem?


The 5V is specifically made for the D-link to make sure it doesn’t lose power.

OMG yes :slight_smile:

The dlink is supposed to be powered through this

Everyone receives one in the Kit of Parts

Also read this before doing any electrical work

Make sure your DC Converter to your D-Link is plugged into your dedicated 12V slot on your Power Distribution.

We had this problem on our off-season robot and it plagued us during Calgames, because there would not be enough power going to the DLink and it would just reboot itself

The D-Link router is a 5 volt device. Connecting it to 12 volts will break it. It won’t necessarily fail immediately, but it will fail.

…and i did some research and apparently a part that we could not identify was actually a 12 to 5 volt converter, who’s purpose is for the Dlink. Am I wrong about that? Would that not be the problem?

That would be a problem.

The robot rules specify the required electrical wiring for the router. The electrical layout Graham linked to will show you exactly how to do it.

Just to elaborate a bit on how the logged info can help identify the culprit.

The Log File Viewer should appear in your Start menu and can be launched from your DS on the Charts tab. After you experience a reboot, a dead bot, or some other confusing event on the robot, I’d encourage you to note the time of the event according to your DS laptop. Then you can locate the log file that contains the info.

In the log file, you’ll see a plot of robot voltage. If the voltage dips at about the same time as the communications loss, it is a reasonable guess that they are related and worth investigating if low voltage condition was the cause. If you let the robot reconnect, the cRIO will actually tattle on the radio if it was up the whole time but also saw that the radio was unreachable. This shows up as a event marker when reconnection takes place. Hover your mouse over the events and their text will show up in the lower left text box. If the event doesn’t exist, then it is likely that the cRIO was also rebooting due to low power. By the way, the cRIO also logs an event each time it boots, so that helps to determine if one, the other, or both devices rebooted.

It isn’t always a problem with power, so the log will also show CPU usage. It is quite easy, especially with C++ to crash the cRIO, and all languages make it easy to get hung in a loop. If voltage is normal, the red CPU trace may offer insight into why the code wouldn’t respond.

Finally, the green and blue plots are for communications quality. In some circumstances it isn’t power or code, but external conditions like an arc welder, a microwave oven, or a super-crowded network. The cRIO doesn’t reboot, it simply can’t talk to the DS well enough to operate safely.

If you are struggling with issues like this, please ask. The tools can always be improved, and many folks do not know how to read the logs that we have.

Greg McKaskle