You are here

CAN bus protocol upgrade thoughts

3 posts / 0 new
Last post
Last seen: 3 weeks 3 days ago
VESC Original
Joined: 2017-05-24 12:15
Posts: 101
CAN bus protocol upgrade thoughts

Hi dear VESC users and developers,

FW 5.00 is on its way, thanks to the good work of Benjamin Jeffrey and many contributors.

Thank you everyone !


As many things are on the table for a rework, could we take the opportunity to upgrade the CANbus integration ?

There are some devices that can (or will soon) hook to the CANbus, such as BMS, accessories, telemetry device or even chargers.

At the moment this implies to find workarounds for every device to communicate together.

I propose to throw our thoughts and needs (as users or developers) for building a CANbus open to more devices and bringing the ability for them to inter-operate (for instance, the BMS can allow the ESC to regen but not discharge in case of battery low, but without shutting down the power line).

Here are some of mines :

  • Add a device identifier (for instance, in COMM_GET_VERSION) to know that the device is (ESC master, ESC slave, BMS, Charger, accessories, telemetry, bluetooth module...).
  • Extended frame ID are embedding commands and target ID OR sender ID in case of status message. This can be confusing. Why not coding both target and sender ID in the Extended frame ID as we have some room left (29bits available, only 16 used). With way we can also save one payload byte as some commands reply with their ID ?
  • Reserve some of the CAN_PACKET commands (the first for instance) for "universal" commands and put device-specific commands furtheer in the enum ?

Those are some thoughts but as I'm designing a "SmartCharger" with CAN ability I'd like to find a sustainable away to communicate with BMS or ESC easily. At this state, I'm afraid to issue commands to the wrong target and make some bad things (i.e ATM, DieBieMS GET_CELLS_VALUES command = VESC FW_WRITE_LZO command).


I already started few months ago to work on a draft about such a unified protocol.

Here is a link :

I found out some existing protocols such as the EnergyBus but it's only limited to 48V batteries. VESC 75-300 and other upcoming ESCs are going far beyond this limit. Not suitable for us, but maybe a good start ?

Also, perhaps UAVCAN may be the way to explore ?


Please share your thougts ! smiley

Last seen: 6 days 22 hours ago
Joined: 2016-12-26 15:20
Posts: 378

That is my next goal, after finishing the dual motor support, which is big change almost everywhere in the firmware. So far FW5 communication is remarkably backwards compatible with VESC Tool and old VESCs, even though dual motors on one MCU is a very different situation.

Changing the CAN protocol completely is something I want to avoid, as I have helped many people implement CAN communication with the VESC. I don't want to break things if that can be avoided.

I have a few working BMSes that will get open source firmware, similar to how the VESC fw is structured, that I'm currently working on. They will have full integration with the VESC and VESC Tool. Most of that is going to be done over CAN-bus, with a protocol that will stay backwards compatible. That will help others who make a BMS support the VESC, hopefully in a way that won't break with firmware updates in the future.

For settings, I plan to implement a way for arbitrary devices to expose configuration parameters, that VESC Tool can list in a new page. Then, for example, if you plug in your LED controller, it can show up as an external device in VESC Tool and expose its configuration parameters there. Jeff and Andrew (you might know them) will collaborate with me on this. This way, the VESC and VESC Tool don't need to be aware of the device or device type at all, as long as that device only cares about RT data from the VESC and providing settings to the user via VESC Tool. Once the VESC FW can take advantage of new devices (e.g. information provided by the BMS), I will just have to add commands for that, or utilize commands that are already implemented by someone else. To avoid collisions, the first CAN ID bits can be e.g. CAN_PACKET_DEVICE_DATA, with the unused bits describing what type of data. There are many details to figure out here, but again, I will think about that when dual motor support is tested and done, and FW5.00 is released. This will be the target for FW6 possibly.

Regarding UAVCAN, there is some support in the firmware for it, but for now I want to keep the protocol backwards compatible and simple. UAVCAN is a bit tricky to use if you just want to assemble a few simple can packets on e.g. an arduino to control a motor, as you have to understand and implement the whole thing. The VESC has some very simple CAN commands to do the most basic things, and most people I helped using the VESC when consulting would have a hard time with UAVCAN.

Also, thanks for sharing the document, there are many important thoughts that I will take into consideration. We should discuss it once I start the work on the protocol.

Last seen: 3 weeks 3 days ago
VESC Original
Joined: 2017-05-24 12:15
Posts: 101

First, thanks for sharing your workflow. This dual motor integration shall be a very tough challenge !

Keeping things backwards compatibility is golden rule, I agree. l'll keep that in mind.

I really like the way you plan to bring the ability to other "passive" devices to be expose their settings.

That would be great also to perform their FW update the same way to do it with VESC.

VESC Tool will then become the all-in-one place. The heart of a whole eco-system.

Can't wait !

UAVCAN is a bit tricky to use

I really agree. I read the specification, this isn't straight forward... frown

Also, thanks for sharing the document, there are many important thoughts that I will take into consideration. We should discuss it once I start the work on the protocol

Well, this is a rough draft (I even saw wrong statements when reading it again...), but I'm glad it may help you out.

I'll stay available at any time for discussing it.

Feel free to ring my bell for contributing to your BMS development !