CAN frame not retrieved/too-stale AbsolutePosition()

I’ve exhausted my options, what do I do about this error?

CTR: CAN frame not received/too-stale. CANCoder xx GetAbsolutePosition

It seems to be disconnecting our robot from driving. To be clear, it does not disconnect, but the drivetrain stops randomly while driving. I made this work, and I’m frustrated because I put so much work in to make this swerve drive work. Any ideas at all? CANcoders are fully updated with firmware; in fact, when I update the firmware (to the same version) the drive works fine but after 10 minutes starts acting up again. What can i do to even start diagnosing this?

Here is our code: https://github.com/RedThunder7166/Swerve_Drive_WPI_2022

What is your CAN utilization?

It looks like the code you posted was last updated in December and is using the 2021 version of WPILib. Is that the correct code?

Fixed it: https://github.com/RedThunder7166/Swerve_Drive_WPI_2022

What do you mean by CANutilization? I have SDS Mk4 swerve drive, CANcoders are all reporting this error. The CAN bus is set up in a loop around the robot. Why wouldn’t the 13 Falcon’s be reporting this error as well if there was an error on the CAN bus?

Check on your driver station diagnostic tab. The CAN utilization will be shown as a percent of total bus capacity. Anything above ~80 is problematic and should be addressed

1 Like

Say it is above 80%, what does it mean to “be addressed”? I copied the WPI example swerve drive as much as I could, I assumed this would work.

Edit: and it did in the fall on our practice chassis. Transferring it to competition bot seemed to just completely screw it up.

We experienced similar CAN issues and it caused us to lose a drivetrain motor intermittently. We found that reducing CAN bus utilization of our robot solved the issue. If you have any follower devices, and you don’t care for its telemetry, you can reduce the rate at which those messages are sent. This can be done on CTRE devices as such: Common Device API — Phoenix documentation. Similarly on REV devices, follow: Control Interfaces - SPARK MAX.

It’s important to reduce the can utilization everywhere, not just the problematic CANcoder.

2 Likes

Meaning…it would help to remove devices off of the CAN bus? Run it on PWM instead?

No, you can have all your devices on CAN, what you need to do is configure your devices in software to reduce the frequency of CAN messages you don’t care about. For example, if your shooter has a lead and follower device, there isn’t much point in sending position data frequently on either device, and there isn’t much point in sending any telemetry data related to the follower.

This makes sense. We have only 8 motors for the swerve (“only”) and the rest are for intake/indexer/climbing, and other parts of climbing. All those don’t matter about frequency so I can reduce their update timer to reduce messages on the CAN bus?

We had this issue also, dropping CAN utilization was helpful

Got to our workspace and it is indeed bouncing back and forth between 78 and 100 when disabled. I’m going to try to reduce CAN bus utilization of other subsystems and see what happens.

I shall report back.

So I went through and set status frames of every motor except the drivetrain and see no noticeable difference. Could someone check my index/intaker and climb subsystems to see I’m doing this right?

This may be out of budget but we bought and overnighted a canivore before our last comp. this added a second bus and dropped our can utilization dramatically. it installed easily and required few code changes (had to name the bus in Phoenix and call the named bus in code as a second argument after the can port designation for each motor).

We also had the cancoder issue and resolved It in code as well with the help of a few talented developers in similar threads on this forum. Code is here https://github.com/team6637/FRC2022/blob/5b14e4c5ba1141c7b836a7f23bb7a07deb8fde55/src/main/java/com/swervedrivespecialties/swervelib/ctre/CanCoderFactoryBuilder.java#L54

You changed to update rate of you CANcoders on a swerve drive to 250? That didn’t affect the drive?

No, I see it is 10. 250 is the timeout.

I should be seeing SOME change in this but I see nothing from the CAN bus utilization. No matter what I change, CAN bus is still maxing out at 100.

Many teams only grab the absolute angle on start-up and then use the Falcon encoder for everything relative to that. In that case after you get the angle from the CANCoder you can change the status rate to the maximum.

Read this on how to get a better estimate of CAN utilization.

If this is the case, what is the advantage of using CANcoders at all?

Edit: Because the magnet gives you a “real world” thing to measure the angle of the wheels to on startup?

That’s a great question. They have higher latency and lower update rate then the falcon encoders, so they aren’t the best for running all your control through. You do need an absolute sensor, but you could use a non CAN absolute sensor. The only real advantage I see is simpler wiring, but it seems enough people have trouble with the soldering that it just trades one wiring problem for another.

Meaning, if I somehow use the Falcon integrated sensor to get positions, it frees up the CAN bus a bit? CTRE shows that the Falcon has a 4.6% usage on the CAN bus whereas a CANcoder has only 1.8%. Wouldn’t this make the whole situation worse?