Interoperability with other CAN protocols

I’m wondering if I can share a UAVCAN bus with another CAN protocol? This one specifically:

From what I can see there shouldn’t be any “collisions” on the CAN IDs. I would also be sure to not set node ids to anything that makes are partial conflict.

I will have custom device on the CAN bus that talks to this gimbal as well as the autopilot via UAVCAN. I can design my device to manage the two protocols, and maybe even modify ardupilot source if necessary.

What will happen in a UAVCAN device (i.e. GPS, ardupilot, etc) if it receives a frame to/from this gimbal in the middle of receiving frames for some other message type?

Has this been done? What (if anything) do I need to worry about?

The spec says this:

(the footnote 66 says: “For example, CANOpen or CANaerospace.”)

It might work, it might not, depending on how you set up your port-IDs and priorities. No guarantees. You can make collisions unlikely if you make sure to avoid using conflicting port-identifiers and node-IDs; for that, please refer to the CAN ID layout diagrams in the Specification.

If there are no port/node-ID conflict, nothing will happen – the irrelevant frames will be simply dropped. If there are conflicts, the frames might be misunderstood by the device as being part of a meaningful transfer, in which case there are two possibilities:

  • If the frames are misinterpreted as single-frame transfers, the node may behave unpredictably due to misinterpreting unrelated data, unless the transfer-ID is misinterpreted as being invalid.
  • If the frames are misinterpreted as part of a multi-frame transfer, they will likely be dropped due to a transfer CRC error.
1 Like