What are all of the socketCAN settings required to communicate with CTRE CAN FD devices?
We are using a waveshare 2 channel CAN FD hat and we are unable to read CAN FD frames from any device on the bus.
We tried to use the canivore usb package to auto configure the bus, but don’t receive any CAN frames.
We also tried to configure it with the following command
sudo ip link set can0 up type can bitrate 1000000 dbitrate 8000000 restart-ms 1000 berr-reporting on fd on and didn’t receive any CAN frames.
Finally we tried sudo ip link set can0 up type can bitrate 1000000 dbitrate 8000000 restart-ms 1000 berr-reporting on fd on sample-point .8 dsample-point .8, but this only allows us to receive normal CAN frames and not FD.
I see the number 8. Doesn’t ctre’s fd run at 10 megabit?
3 Likes
When we looked into this from other teams who have run socket can in FD mode, it seems that their busses are running at 8Mb/s for the FD bitrate and not 10Mb/s like they suggest in their marketing material. I will confirm with our hardware platform later today, but I seem to remember using the canivore-usb package to auto configure the bus also set the FD bitrate to 8Mb/s.
Either way, it would be nice to get some clarity from CTRE on this, as they only have configs for CAN2.0 in their Linux example repositories.
(edited to remove the comment about 971’s config since it wasnt relevant)
That CAN interface was used for a non-motor-control CAN FD bus; the settings should generally not be assumed to how CTRE manages their CAN FD bus.
Thanks for the heads up. I’ll update my post.
For reference, this off-season we have got things set up to be able to use a CANivore plugged into USB to talk on the CAN FD bus; I don’t think we’ve gotten all of the configuration for that pushed yet, though.
On the topic of how to best operate on the CAN FD bus without a CANivore, I do not believe we ever ended up having an actually working solution (the CAN FD configuration you found was originally intended to allow some of that, but we ended up using it for other things, and the CAN FD board we were using was giving us some trouble, so using the CANivore was a reasonable solution for the time being).
Interesting. do you still happen to have the configuration that was working but having issues? We were initially trying to do the same by starting with the CANivore, but are running into serious issues with its stability on a Raspi 5.
The behavior we see right now is after a short period of time, the software on the Pi will raise an error about the connection to the CANivore being lost. The only way that we seem to be able to get communications re-established is via restarting the CAN network (usually via restarting the program). This error seems to be related to something going on with the Pi internally, as we can reproduce it with the bot sitting disabled on a table top, but are unable to reproduce it when we switch the CANivore to be connected to the RoboRIO.
Now that it is set up, we haven’t been having any noticeable issues with the CANivore on our Orins, although the runtime we’ve had is pretty minimal so I’m hesitant to vouch for it. I didn’t do the work on that myself, and the student that did most of that is busy getting us ready for Madtown, but we should have all the relevant configuration public on our various github repositories at some point in the near future as we get things cleaned up & merged.
1 Like