I am current stuck by CAN communication with ODrive. So my ODrive is on 24 volt. The firmware is the latest (v0.4.11). I read the code in https://github.com/madcowswe/ODrive/blob/master/Firmware/communication/interface_can.cpp, and found that there is a sever_thread that keep sending out heartbeat without checking message. So I hook a CAN module to ODrive (H to H, L to L), but the can didn’t hear anything, while it can work with the exact same code if hooked to another active CAN transmitter. Are there anything I did wrong? How could I find heartbeat of Odrive’s CAN module? So I need send any message?
I’m not sure the ODrive master firmware’s CAN implementation works or not. I’d check out CAN Interface Available for Testing
I ended up found that Odrive’s latest firmware doesn’t contain CAN support. I tried your firmware and it worked. Thank you so much!
However, right now I am stuck by CAN communication itself. I used FlexCAN (https://github.com/collin80/FlexCAN_Library) running on Teensy 3.6 to listen to ODrive and attempted to send RTR commands, like getting voltages. Although Odrive can send back messages with correct header that set RTR bit off, command sender cannot find that its request has been responded. My TxMailBox on teensy is fulfilled eventually. So how did u configure message sender and Odrive for those CAN communications that contain RTR operations?
ODrive completely ignores RTR bits.
Could you re-confirm that your fork ignores RTR bits? I found in the can_simple.cpp
file of the fork you linked that the callbacks for call/response messages check for the RTR bits, for example line 152:
void CANSimple::get_encoder_error_callback(Axis* axis, can_Message_t& msg) {
if (msg.rtr) {
can_Message_t txmsg;
...
odCAN->write(txmsg);
}
}
I did check in the interface_can
files as well to make sure the RTR bits were getting read/written and it does seem like they are.
Err… I don’t remember adding those. But evidently I did. I don’t know why - I don’t know how RTR even works or why someone would use it.
I believe the protocol is using RTR as a flag, as if it were just an extra ID bit. There is no hardware remote frame support being used