Request for review of my CAN bus wiring diagram

1

Hello Community. I am the proud owner of a pair of odesc3.6 boards and am planning to use them in a 4x4 land vehicle. I have read the manual but am not sure I clearly understand the basic concept of CAN wiring. Also I cannot find “CAN 120R” on my boards. Can I request a review of the diagram I am planning to implement?

odesccansheme
odesccansheme1920×1920 177 KB

2

Hi Andrii,

Unfortunately the Odesc boards are an unlicenced clone of the ODrive, so there’s not too much we can help with – they may have changed the hardware, hence the lack of onboard CAN termination. However, your wiring generally looks correct for a typical ODrive device.

3

Thank you for answer. Nevertheless this board is unlicensed it works so far, and I believe it may used as starting point to learn odrive API+ordivetools that`s seemed quite convenient to me . I noticed this board comes with outdated firmware that “manufacturer” not recomended to upgraide. Using odrivetool , I found all properties and comands mentioned in documentation, except .config.enable_brake_resistor but brake resistor itself was comes with board. Should I assumed brake resistor enabled by default or its properties must be setted other way than .config.enable_brake_resistor ?

4

Hmm - usually those clones are on 0.5.1 – they don’t want you to upgrade because otherwise ODrivetool would tell you it’s a clone (which it can detect on newer firmware versions).

You may need to look at the changelog to see the differences between versions: CHANGELOG — ODrive Documentation 0.5.6 documentation

5

Ok, I made the CAN wiring, it works, but it seems that the ODriveCAN library for Arduino is blocking the main thread. A short investigation pointed me to this function.

static void pumpEvents(MCP2515Class& intf) {
   // nothing to do
   // TODO: maybe remove
   delay(10); // not sure why this resulted in less dropped messages, could have been a twisted coincidence
}

This is not what I expected to see when choosing CAN for “professional use” as advised in manual.

6

Fully understand the frustration. We’re in a tricky place of having to support a wide variety of Arduino variants, and typically those reliant on the MCP2515 (e.g. the Uno, Mega, etc) aren’t going to be very fast in the first place (16MHz max, no FPU, not too much you can do with that in terms of real time control) – so we had to prioritize reliability – though I do agree these comments could be more professional, that code was graciously added by a community contributor.

To clarify, the Arduino CAN library is generally intended just to be a starting point or reference for the user to expand on – there’s numerous other issues with using Arduino-based software in production / industrial applications anyways. So we really prioritize fast setup and maximizing reliability as opposed to the sort of low-level code needed to maximize CAN speed. Other platforms with native CAN support (e.g. Teensy, Arduino Uno R4, etc) should be much faster in the first place even with the Arduino CAN library, as we can accurately poll for incoming events.

We’ll add a patch to our library to add some more clarification, so thanks for the feedback!