Our robot jerks and is unresponsive for short periods of time during operation. We have a week 2 event in two days, please advise!

Hi everyone, some of my teammates made a post on this a few days ago, I just wanted to make another post to add some information and for visibility. Our robot twitches and becomes unresponsive for short periods of time during robot operation. We have checked wiring (nothing apparent) and completely swapped out our radio and roborio to no effect.

As you can probably guess, this is a big issue as it can ruin an autonomous run and causes significant issues during teleop. Any help would be greatly appreciated, here is a link to the previous post with logs and a bit more information in the replies. We have to pack up the robot in two days and are still working on autonomous so any help is greatly appreciated!

Information on robot, will be updated with any other relevant info I can think of:
RoboRio 1.0
REV MAXSwerve and NEO-powered arm for 6 NEOs, 4 NEO 550s, and one Redline powered by a Talon SRX

Edit: Here is the log file during chattering, it shows 95-100% packet loss for around 5 seconds:

Have you tried a fresh battery? Do you have a camera on board? If so what is the frame rate set to?

1 Like

Battery makes no difference, we’ve been having this issue for at least a few days and have gone through quite a few batteries since then. We have a Limelight 3 and a Lifecam for FPV on board at 40 fps and ~15 fps respectively? I doubt this is a vision-related issue since motor controller status lights flash and arm movement which is not related to vision at all is affected

I’m no expert, but the way your status light goes on and off is quite… Suspicious. I don’t believe the status light should be doing that. Are you sure your robot is not regularly browning out?

The way it looked my guess is its a wiring issue, though I do not have much wiring experience. Although, an issue has been going around with the driver station, have you tried reinstalling it/trying a different laptop?

From the looks of it I would think it is something electrical. I would unplug all the motors and leave just the Rio, PDP, router, etc. such that you can connect on driver station. One by one plug components back in and see if they still work.

Make sure there is nothing contacting the battery leads, or that any of your connections are shorting. Putty will be a big help for this.

We thought the same thing, but it is very intermittent. Sometimes we will go 15+ minutes of testing without anything abnormal operating and sometimes it will happen a few times in a 5 minute time span. We also haven’t figured out how to trigger it and it appears very randomly so it is hard to test in ways like the one you suggested. The video I linked above is one we happened to be filming when the chattering happened

Here is a screenshot of the log file viewer over the time period the chattering is happening in:

Looks like Severe (>100%?) packet loss - #140 by chauser.
Try running without the IDE (VS code) open. That helped us in Utah.

3 Likes

This is something that I unfortunately cant provide much help with, but if this is still happening by the time you’re at your event, talk to a CSA (orange hat) ASAP, they should get you sorted out.

Good news/bad news:

  1. You’ve got company.
  2. They’re not sure why.

We replaced our laptop for a brand new one and have not seen the problem again, but I’m not at all confident that this is a permanent fix.

If the robot is up on blocks and you run your drive back and forth with out operating anything else, do you get the behavior?

What about disconnecting power to additional mechanisms, and connecting one at a time to isolate a faulty mechanism/ circuit?

You really need to figure out why you are losing signal. This is due either to brown-out or some other interference. You need to rule brown out vs some other intermittent like short circuit or bad connection.

Many years ago we had a robot misbehave because an older brushed motor was sparking badly next to the older radio modem. Fortunately, RF noise is unlikely, but needs to be ruled out.

For brown outs check to see if any motors are running hot, which means they could be working at cross purposes.

as the OP of that thread, yes, this is the same behavior we are having.

This is not a helpful response. They are trying to figure it out by posting here. Telling them they really need to figure it out is already known to them.

There are only 2 brownouts in the DS log.

We ran in to the same issues with CIMS…the problem was fixed when we coded it to .85 from 1.0 for speed. After that, any other issues were…our fault! We were running 2 Spark Max’s and 2 Victors. for comp we went to all Spark Max’s.

I would also look at the those…check all the settings…IF you haven’t already done so.

From this screenshot it looks like you are running DS 23.0. There was an update a little over a week ago to 23.1. We had similar issues to this and an update to the driver station fixed it for us. If you haven’t already, also try checking for updates in WPILib and device firmware because sometimes discrepancies between what the versions code expects and what is on the robot can cause system lockups.

The arm jerking is caused by the robot disabling whenever you lose comms. The comms loss can be caused by a large number of things: wiring, driverstation (as other teams have experienced), your computer’s wifi, background applications running, bandwidth (camera streams), the building you are in. Last year we spent hours upon hours trying to diagnose our comms loss only to realize it only ever happened in our temporary practice space.

Other teams have experienced this same issue with driver station, but we can still try rule out other factors; plenty of suggestions have been made above. I’ll try to add a few more thoughts here:

I see you are using a limelight. Are you using an ethernet switch or the second port on the radio? In the video, it looks like you are using the second port on the radio, which is a big no no. As I like to tell my students “Second port BAD”. There is a good thread on why you should use the ethernet switch:

The next item I’d like you to check is your bandwidth. Are you displaying both camera streams at the same time? Does closing the dashboards (shuffleboard or smart dashboard) help?
You can use these instructions to check bandwidth:

If none of this helps, I’d just do a few more checks. Check all your wiring to the rio, ethernet switch, and radio. Replace ethernet cables if you have spares.
On your laptop, you want to close all other applications while running driverstation. Make sure the laptop is plugged in and is in high performance mode.

Are you using CAN bus? Are you using the lever lock WAGO connectors? If so go through and check all of your connections. Our guys had one clamped on the insulation and while connected, it wasn’t well connected.

While your post is good advice for someone having CAN troubles…

The DS log OP posted doesn’t indicate CAN troubles as far as I can tell. CAN usage looks relatively stable, no dips or spikes. When CAN affects packet loss you will typically get CAN usage spikes.

1 Like

We had a similar issue, it had something to do with our computer having too many background tasks. Make sure you don’t have solidworks or other cad software on your drive computer

Checking in, was the solution found for this?