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 : https://drive.google.com/open?id=1YXr_k_iyvdH3Ont8zz-6KKbbqhPPB_aq
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 ! 
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.
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 !
I really agree. I read the specification, this isn't straight forward...
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 !
It has been a while, but I made a lot of progress on this. The VESC BMS firmware is now on github (although there are still things to do), and it exposes custom settings to VESC Tool. I wrote a bit about how it works in the README, and there is a section here that describes how the configurations work:
https://github.com/vedderb/vesc_bms_fw#configuration-with-vesc-tool
I made a few other PCBs that show up nicely in VESC Tool when connected over CAN, so it seems to work quite well. There are also tools in VESC Tool to edit configurations and generate code from them. Feel free to have a look and experiment with the code, and let me know if I can improve it somehow.
I just stumbled upon this. I as many others are using VESC ESCs on autonomous vehicles that already support UAVCAN. Our vehicles have a CAN bus with several other devices on it and the ESC needs to play nice with them. The current implementation of UAVCAN on VESC allows for this, but its lacking a lot of features. I just started trying to add support for changing the VESC parameters through UAVCAN because I need it for a project and have found the UAVCAN library to be easy to work with.
The other feature besides parameters that we want to be able to get on UAVCAN is a total current limit based on the current being consumed by all the ESCs, for this the ESCs need to be aware of the other ESCs consumption. So they would need to be able to read the esc status from other ESCs in the system.
I started working on the above this past week.
https://github.com/vedderb/bldc/issues/259
Hi Benjamin.
I am looking for a clear bms to vesc protocol detail. We are making a custom bms for a project of ours and looking what and how the vesc ecpect the can frames. (Address, words, type of frame,erc...).
Would anyone be able to help on this please?