CRIO ghosting

[Thad House]

Yesterday and today, the cRIO on our robot was acting very strangely. Last night, we plugged in to pressurize our air, and the robot automatically enabled itself. Which was really odd, and I thought should never happen.

Then in our match after that happened, Our auto did not act how it should have. It instantly started running our catapult and not responding to our limit switch that stops it. It was like it started running a different part of the code. When looking though our error logs for this match, normally the catapult motor sends MotorSafety errors to the driver station when it is running the loop correctly. In that match, it did not, and sent no errors at all to the driver station, not even the ping status ones that usually show up. So we re imaged the cRIO and hoped that worked.

It worked through most of today, but then it happened again. As soon as auto started the code started not responding correctly to the inputs. Because this was in the finals, we didnt have time to reflash, but we were able to get it to work correctly by entering teleop before connecting to the field, and not reboot the robot between doing this.

The same code worked great on our practice bot, and for the entire competition last time, so its really weird why it would do this. it just seemed really odd, and was wondering if anybody had any suggestions on what would cause something like this to happen?

[Greg McKaskle]

When your compressor ran unexpectedly, I doubt that the robot was really enabled. Usually, this is either caused by an improperly wired compressor circuit or a faulty digital breakout board that has shorted.

The other symptoms sound like they could be caused by a limit switch that has stopped working. It could be due to wiring or code that doesn't read it often enough.

I can't speak for all engineers, but I don't believe in ghosts. Also, imaging the cRIO seems to have this mystical quality. It replaces the OS and libraries on the cRIO's file system. It is only necessary if the files have become corrupted, and a corrupted OS generally doesn't boot, run, and simply read limit switches differently.

I'd encourage you to debug and diagnose the symptoms independently. Fix what you find and develop good testing techniques for your robot. Things are almost guaranteed to break and become damaged in this game, so being prepared to diagnose and correct is a great skill to have.

Greg McKaskle

[Thad House]

Originally Posted by Greg McKaskle

When your compressor ran unexpectedly, I doubt that the robot was really enabled. Usually, this is either caused by an improperly wired compressor circuit or a faulty digital breakout board that has shorted.

The other symptoms sound like they could be caused by a limit switch that has stopped working. It could be due to wiring or code that doesn't read it often enough.

I can't speak for all engineers, but I don't believe in ghosts. Also, imaging the cRIO seems to have this mystical quality. It replaces the OS and libraries on the cRIO's file system. It is only necessary if the files have become corrupted, and a corrupted OS generally doesn't boot, run, and simply read limit switches differently.

I'd encourage you to debug and diagnose the symptoms independently. Fix what you find and develop good testing techniques for your robot. Things are almost guaranteed to break and become damaged in this game, so being prepared to diagnose and correct is a great skill to have.

Greg McKaskle

When the robot enabled in the queue, the DS actually showed enabled, and other motors started as well. It actually caused our catapult to dry fire in the middle of the queue, which made it really scary.

Also, when the issue happened in matches, it visibly was not running the correct code, even if we ignore the limit switch. We usually have a delay of about 2 seconds before anything moves in auto, but everything started moving immediately, instead of waiting.

The limit switch when tested was working correctly, and is running in a 10ms periodic tasks loop, where it is triggered for more then 100ms by the robot.

Where else should I look to see if there are problems?

[Greg McKaskle]

I'd like to focus on the robot enabled when you didn't intend it to be first.

If there is a way for this to happen, please try to give me steps. The DS shouldn't enable without a robot attached. The robot is told its state. I do not know of a way for it to coerce the DS to enable. The field can cause the DS to enable, but your DS must be connected to the field for that to happen. There are odd corner cases such as when you are developing on a cRIO and start new code while running existing code. As far as I've seen, when new code on the robot takes over from old code, the FRC Communication task tells the DS and the new program is disabled even if the old one.

Are you sure that someone didn't enable the robot from the DS? F1 is the shortcut to enable the robot, by the way. Enter key is the shortcut to disable, and space is the shortcut to Estop.

As for the other symptoms. If you attach code, I can give it a look and see if anything jumps out.

Greg McKaskle

[Thad House]

Originally Posted by Greg McKaskle

I'd like to focus on the robot enabled when you didn't intend it to be first.

If there is a way for this to happen, please try to give me steps. The DS shouldn't enable without a robot attached. The robot is told its state. I do not know of a way for it to coerce the DS to enable. The field can cause the DS to enable, but your DS must be connected to the field for that to happen. There are odd corner cases such as when you are developing on a cRIO and start new code while running existing code. As far as I've seen, when new code on the robot takes over from old code, the FRC Communication task tells the DS and the new program is disabled even if the old one.

Are you sure that someone didn't enable the robot from the DS? F1 is the shortcut to enable the robot, by the way. Enter key is the shortcut to disable, and space is the shortcut to Estop.

As for the other symptoms. If you attach code, I can give it a look and see if anything jumps out.

Greg McKaskle

When it enabled, it was sitting on the cart and we were in the queue. We were booting the robot into the loaded code. The laptop was sitting in the programmer's hands plugged in through an ethernet cable. As soon as the robot actually gained robot code, it enabled itself. We know about the buttons that enable the robot, and none of them were pressed. It was really odd, and I had never seen it before.

As for the code, if you PM me your email I will send it to you. PM won't let me send attachments, and we do not want to post the code publicly.