The best standard in my opinion is J1939, Vedder has setup the VESC messages to act very similarly to this protocol by default. Without getting into how canbus works, the best practice I’ve seen through work experience is having devices with configurable “source addresses,” some go even further to integrate configurable “parameter group numbers.” This way when the user sees something not working, a device just needs to be bumped to work again, though I also highly doubt we’ll see more than 7 different types of device peripheral systems on any given skateboard canbus. I have posted my efforts on vedder’s can message structure, but I have to verify it more since it worked with 2.18 and we’re on 3.63 or something.
2 Likes
I think we’re talking more about the application layer such as “retrieve cells data” or “I will shut down, please stop driving the motor” messages.
This is the purpose of my document : the content of the message, not the way to send it.
1 Like
Nice initiative to get a more general standard. To be able to get a standard and have it implement it needs to be lean and adaptable so it doesn’t grow into something to big that will fail because of its complexity or fail over time because it’s not updated everywhere.
To make it as general as possible we could keep it really simple, no need to define ever case with a custom flag if the handling of the state is the same as other flags, make one state instead. ie. Use different levels of states, information, fault, error, critical so the VESC and other units can act on those without having a flag for every specific case that can happen. Each general state can have a short text to describe the issue that can be used to inform the user in different ways.
The units could then easily be customized how to handle these few states with configuration.
ie. Information: log
Fault: no charging
Error: no discharge and no Regen
Critical: shutdown
These are just examples and could easily be setup by the user or application for the needed functionality when a state is received.
It’s also safer to let a unit decide how to handle a incoming state so they aren’t forced to handle something that is not needed or wanted.
Well, I think the Christmas wishlist is starting to include things meant for other holidays. We should really consider how CAN Bus is used in the automotive world since it’s pretty much an exact parallel. You have the OEM (Vedder in this case) create the basic structure just to get the essentials running, like the ECU, body modules, steering wheel controls, etc. This base should be considered something you can’t change and will have to make your devices bend to the will of if the OEM (Vedder) does decide to change it. OEMs can and do bend to the will of a device they want to integrate, but that’s up to them.
With that as the preface, the fault codes. In CAN, you send data in messages, with the default VESC CAN, it’s the 2.0B standard, meaning the headers are 29-bit identifiers with 8-byte payloads, immediately that should tell you the issue with sending codes in plain text on CAN bus. The devices are supposed to know what a fault code is and how to interpret it for the user with a single byte, sometimes even less if you’re strapped for data. Vedder does have a way of pulling fault codes over CAN, at the end of the data poll payload.
It also needs to be requested from the controller, that little “Send status over CAN” box ya’ll tick to get multiple motors to work only sends the rpm, current and duty cycle, to get more you gotta request it and capture 8 messages in rapid series. Not a bad way to do it, I’ve done the same thing professionally.
What I’m getting at is the VESC is interacted with in specific ways to the VESC, and will react accordingly to how other devices want to talk to it and if parameters are within it’s limits. Cars for example that have a CAN-enabled throttle will stay at full throttle so long as the throttle says it’s pressed to full throttle, and the ECU doesn’t hit any limits. The VESC itself will not react to any fault codes in a CAN network, not even to other VESCs. The only fault code sent over CAN that will kill anything the VESC is doing, is a code that makes whatever is broadcasting the throttle commands to the VESC to stop broadcasting messages. We’d have to add that functionality with custom firmware for the VESC, which Vedder has no responsibility to implement in the master. It’d be like Delphi saying to Toyota, “Our automatic HVAC controller can detect when there’s high CO2 in the cabin, you need to adapt your ECU to react to our messages to turn off the engine as a standard.” Now if Vedder wants to implement that functionality on his own, that’s fine, but in my opinion, still not ideal cause you want these devices to be firmware agnostic.
In closing, as 3rd party developers, it’s up to us to make our products highly flexible to the base system, and other 3rd party devices that might conflict with us. The automotive industry has this approach (usually), reinventing the wheel is a pain.
4 Likes
Thanks for your inputs.
I agree with the big picture. The VESC FW needs to be change as well because it also needs robustness.
For instance, having an over-current, over temperature and so on on the master drives the slave one to zero current (idle).
Let’s say you killed the DRV, you’re good to come back home by foot even if the slave VESC is ok.
Plus the need to communicate with other devices.
Delphi vs Toyota : not sure if the comparison applies to our setup. IMO, the big master in our system is the BMS. if it wants to shut down, everything will be depowered
So it NEEDS to be taken into account to maximize availability (aka high batt. temp or high batt. current that can be handled by limiting the power, VESC side).
Anyway, PLEASE, contribute to the document or start a new draft is mine isn’t to your flavor. We need to go ahead with it but I can’t do it alone.
Thing is if you’re gonna have these features, the VESC firmware isn’t what should change, well, it can by Vedder’s will, but we shouldn’t rely on what changes. For the kind of control outlined in your document, the best way to accomplish this is to have a CAN based remote receiver that does the final commands to the VESC while considering the statuses from the BMS, otherwise you’ll have to provide the custom app for the VESC to work with your BMS. Hell, you could make the BMS the remote receiver if you don’t want to make a separate module. Best part is your “Master” is the receiver module, not a VESC, a dead VESC is highly unlikely to bring down a CAN network. Again, we need flexibility in design considerations, imagine at any given time a user will want to use a device combination that won’t work unless your product can yield whatever causes the conflict quickly.
Also a side note, I retested the CAN message functions I’ve reverse-engineered on a 3.62 VESC, and the main commands do work, like the duty cycle set, current set, brake current set, rpm set, etc. There’s also a few new commands like this handbrake thing and set current rel, which I’m not sure what it does. But, there has been a change to order of statuses in the cascade return of message 8, instruction 4, mostly cause Vedder added a method of selectively requesting VESC statuses like just the current or just the tachometer instead of the whole thing. I’ll need to do more testing to verify, but for now the throttle related commands from 2.18 are accurate to 3.62.
Reverse-engineering is necessary because no one, not even Vedder, has made a message structure outline for how to interface with CAN bus like what real OEMs would publish. Which should answer the second question, whatever system you make needs to agnostic of the main or other systems in the network, you shouldn’t rely on Vedder or the other main devs for the VESC project to implement features you consider critical to the use of your system. Worse yet, they might roll back stuff that was needed to get thing to work before due to a conflict with a new feature they want. Yes, the source code is published, but it also still needs to be tested to verify it’s true or if there’s any quirks or inconsistencies, to me that’s a part of the reverse-engineering process, especially if you’re finishing documentation that should’ve been done long ago.
The middle-ware device, how is that different from how we use it today? No VESC has a remote receiver built-in, you still need a bluetooth module, nrfchip+remote, Nyko Kama receiver, RC receiver, etc. The only difference is you’d be going in through the CAN bus port, which is what would fix this over-crowded UART port problem I’ve been hearing about. And why is everyone trying to get in through UART? Because it’s the only port Vedder made any outline on how to use. Like, a UART splitter sounds more sketchy than a CAN-based throttle controller.
Why do you need to reverse-engineer things ?
Source are published.
For sure you can change the VESC FW ! Just pull resuest what you want to add and if it’s clean enough it’ll get merged.
Nothing’s closed.
I thought to this “man-in-the-middle” device too but this adds another chip = another cost = another room to find for embedding it = another point of failure
1 Like