How to determine root cause of robot dropping from Teleop to Disabled during match.

[tr6scott]

Alan,

Yes, those fuses were included in the "All fuses" were checked. We experienced a disconnect at our Waterford event (Week2), and when we were alerted of the problem, we found one of the ATM fuses to not be completely seated. Having already been through this scenario once this season, that was the first thing I had instructed the pit crew to confirm as they were fixing the elevator after the match.

But I am now going to go back to those logs and review that match too.

[notmattlythgoe]

We actually had a match at VA that our robot code just stopped running. FTA said the rio never disconnected from the field. No errors on the DS stating any code errors that crashed it. It just stopped. Never figured out what the issue was and it didn't do it again.

[tr6scott]

Alan,

Follow up on Waterford event.
Video: https://youtu.be/Ai4AiWz7680

at 57 second on video you see the stacklight flash.

You also see our drivers struggle with that stack after restored.

FTA came to us with the issue, and mentor said one of the ATM fuses was not seated completely, he felt the fuse move, and seat when he pushed on it.

As this was Finals Match 2, not much done after this to diagnose the issue.

[billbo911]

Originally Posted by Greg McKaskle

....

I wouldn't worry about the radio or radio placement. I'd check the laptop ethernet retention and speak with the drive team to see whether they think the cable could have been the issue. I'd look at the code a bit for the joystick output error, and perhaps even pull the cable to see if the error shows up in the log when the DS and robot reconnect.

Hope this helps.
Greg McKaskle

Greg has a very strong point here. RJ45 connectors, while normally reliable, can become fairly unreliable. Many factors can contribute to this issue. This is a big issue on my team. We have managed to damage beyond repair a few laptop's Ethernet ports.
The repeated connecting and disconnecting that takes place with most Driver's Station laptops can easily contribute to their early demise. There are a couple things that can be done to help reduce this wear and tear. One of the simplest and easiest ways to do this is to use an Ethernet Port Saver. Install it and tie it down so the end attached to the laptop doesn't move WRT the laptop.

Another issue I have personally seen giving lots of teams grief, and may apply to this thread directly, has to do with the design of the Ethernet port on the laptop used for the Driver's Station. This design can easily cause intermittent connection failures as well as the cable completely coming out of the laptop.
Here are a couple pictures of my personal laptop that has been used as a Driver's Station and has also completely lost the cable when bumped just a slight bit. This is an Acer laptop, but I have seen this same configuration on several different manufacturer's laptops.




In the second picture I am pulling down on the small cover plate that opens up when the cable is inserted. This cover rests right on the latch clip for the cable. Any pressure on the cover causes the cable latch to release. Believe me, it happens A LOT!!

The resolution to this is to make a relief notch in the Driver's Console assembly so that no contact with the cover plate can be made unintentionally.

[Tom Line]

Originally Posted by billbo911

Greg has a very strong point here. RJ45 connectors, while normally reliable, can become fairly unreliable. Many factors can contribute to this issue. This is a big issue on my team. We have managed to damage beyond repair a few laptop's Ethernet ports.
The repeated connecting and disconnecting that takes place with most Driver's Station laptops can easily contribute to their early demise. There are a couple things that can be done to help reduce this wear and tear. One of the simplest and easiest ways to do this is to use an Ethernet Port Saver. Install it and tie it down so the end attached to the laptop doesn't move WRT the laptop.

Another issue I have personally seen giving lots of teams grief, and may apply to this thread directly, has to do with the design of the Ethernet port on the laptop used for the Driver's Station. This design can easily cause intermittent connection failures as well as the cable completely coming out of the laptop.
Here are a couple pictures of my personal laptop that has been used as a Driver's Station and has also completely lost the cable when bumped just a slight bit. This is an Acer laptop, but I have seen this same configuration on several different manufacturer's laptops.




In the second picture I am pulling down on the small cover plate that opens up when the cable is inserted. This cover rests right on the latch clip for the cable. Any pressure on the cover causes the cable latch to release. Believe me, it happens A LOT!!

The resolution to this is to make a relief notch in the Driver's Console assembly so that no contact with the cover plate can be made unintentionally.

I have an acer laptop as well, and I'm convinced whoever designed that ethernet port was paid to find the most contrived, poorly engineered way possible to design it. Of course, I didn't realize it until FIRST season started, because how many other times do you plug your laptop into ethernet except at competitions?

Bleah.

[MrRoboSteve]

Other options:

Buy an old Thinkpad like this, and put a small SSD in it.

Use a USB2 to Ethernet adapter.

[Monochron]

We had a very similar situation in our quarter finals match. The first one we exhibited similar behavior all throughout teleop (autonomous went fine). The second match we only dropped out for about 30 seconds or so. The DS logs showed that we lost communication with the FMS for the duration of those times. CSA's suggested that this was caused by our radio losing power, but it looked like they couldn't investigate the issue further than that.

I'm eager to see if you can resolve this, and I'll see if I can make any progress on evidence for what caused our problem.

[plnyyanks]

Originally Posted by Monochron

We had a very similar situation in our quarter finals match. The first one we exhibited similar behavior all throughout teleop (autonomous went fine). The second match we only dropped out for about 30 seconds or so. The DS logs showed that we lost communication with the FMS for the duration of those times. CSA's suggested that this was caused by our radio losing power, but it looked like they couldn't investigate the issue further than that.

It sounds like the CSA was on to something - a radio reboot typically takes between 30 and 40 seconds to come back (the DS logs tell you exactly how long your robot was down). In contrast, a roboRIO will take around 25 seconds to reboot.

Common causes of radio reboots:
- Brownouts due to your battery being low. These events correlate to large current draws
- PDP Fuses. Push them in all the way
- Multiple things plugged into the radio source on the VRM
- The barrel connector not being plugging in all the way, especially if it's an older one

[Monochron]

Originally Posted by plnyyanks

It sounds like the CSA was on to something - a radio reboot typically takes between 30 and 40 seconds to come back (the DS logs tell you exactly how long your robot was down). In contrast, a roboRIO will take around 25 seconds to reboot.

Common symptoms of radio reboots:
- Brownouts due to your battery being low. These events correlate to large current draws
- PDP Fuses. Push them in all the way
- Multiple things plugged into the radio source on the VRM
- The barrel connector not being plugging in all the way, especially if it's an older one

Yeah we didn't notice any unusually large voltage spikes in the logs but I'm still checking different possible causes.

[MrRoboSteve]

Also make sure you are using the appropriately sized barrel connector. If the outer diameter is too small, intermittent power is possible.