search

CrossTheRoadElec / Phoenix-api

CTRE Phoenix language API (targets FIRST Robotics Competition, Linux, RaspPi, Windows)
Other
39 stars 28 forks source link

Raspberry Pi Stale CAN Frames #69

Closed J0hannB closed 3 years ago

J0hannB commented 4 years ago

I sent an email to support, but haven't received a reply so I'm also posting here:

I am developing an application that controls a Talon SRX from a Raspberry Pi 4, and I'm am struggling to read the integrated encoder position as quickly as I would like.

I need to precisely trigger an I/O when the integrated relative encoder connected to the Talon reads a specific position. The motor is running at a high velocity so I need position updates from the encoder at ~ 1kHz.

To accomplish this, I have set the Status 2 frame period to 1ms and poll GetSelectedSensorPosition() at > 1kHz. Below is a plot I generated of the sensor position vs time while the motor was running at a constant velocity (~4000 ticks/100ms). You can see that there are periods where position updates at intervals of 1 ms, but much of the time the position stair-steps at intervals of about 20 ms. However, If I set the Status 2 frame period to 5 ms or greater, position updates at the rate I expect.

My suspicion is that this is due to the high volume of CAN messages overwhelming socketCAN. Is this a limitation of socketCAN on the rPi? I have tried setting the frame period of Status 1, Status 10, and Status 13 to 100 ms to reduce traffic on the CAN bus, but it doesn't seem to help. Is there a way to drop stale frames and only use the latest? Is there another way to achieve reliable 1kHz encoder position updates on the rPi?

The Talon is connected to the rPi using a Canable CAN to USB board running the candlelight firmware. There are no other devices on the CAN bus. I'm running Ubuntu 19.10 64 bit, so I've been using the Phoenix libraries build for Jetson Tx.

I have also attached a text file containing the results of running candump -t z can0

candump.txt

image

JCaporuscio commented 3 years ago

Apologies for the late response - the initial e-mail/issue came during last year's FRC season which was then followed by the COVID breakout.

During the course of our testing, we've encountered limitations with SocketCAN and rapidly sending/receiving CAN frames. This typically isn't an issue unless you're trying to very rapidly process frames as you're doing. We haven't determined a hard cutoff so I can't give you a precise number.

I'm going to close this issue since it's old, however if you'd still like to discuss the behavior you're seeing please e-mail us at support@ctr-electronics.com. We'll be sure to get back to you ASAP.