Hallo, mr. mishrasubhransu hath invited me to this conversation and I believe I can answer some questions. I can also start a parallel topic here (the website in general) in regards to the reverse engineering effort on esk8 builders.
So, CAN bus is extremely versatile provided you follow the required physical structure which consists of a twisted pair wire line with your nodes branching off of it (I can get into more detail on the limitations if asked) and a 120 ohm terminating resistor on each end, this can also tell you if you have problems if your bus resistance is anything other than 60 ohms (when the system is powered off).
From what I understand in terms of the history of using CAN in esk8 applications is vedder brought it onto the scene with the vesc, not immediately for direct control, but for controlling multiple vescs with the master designated vesc handling the signal communication to the operator.
I’ll say this right now, using I2C for vital controls is a problem if it’s done anywhere outside a circuit board. I2C stands for Inter-Circuit Communication, it consists of a clock and data line, that data line at long distances (more than a few inches) is very vulnerable to interference with practically no physical layer protection unless you intentionally shield it. As everyone’s familiar, the nunchuck is I2C, I hope I’m the only one familiar with the frequent communication dropouts of the Nyko Kama that would cause the vesc to go full throttle for a second.
As for the bus speed and hardware, the vesc uses hardware compliant with the CAN V2.0B standard, meaning it is the higher speed, overall better version. My testing has been done at 500k and if I set it to anything else, I wouldn’t read it so lets assume that’s the default operating speed. I would also assume that other peripherals made for esk8 CAN also likely use that speed, however modern automotive sensors and components use 250k outside of the engine, so just keep in mind what you’re connecting to what.
To the lighting question, if you want to control a shit ton of lights but don’t have enough IO through the vesc, you can make a dedicated lighting controller that’s connected via CAN bus and command it through that or use that as the receiver node and pass along the vesc commands via CAN. It’s probably not doing on a skateboard scale, but the automotive world puts controllers in individual modules like lights n shit so you don’t have a massive wiring harness, thing with lights on a skateboard is the lights typically don’t get big enough to warrant a dedicated controller on them. There’s another protocol called LIN bus, but I’m not touching that unless it becomes more relevant.
As for the setup question, the main issue is if someone mapped out the entire message structure, it hasn’t been shared which is why I’ve started trying to reverse engineer it myself. There’s a lot of freedom with what messages you can send in the CAN bus, but at this scale, any control you want over CAN bus has to be done with controllers you made, this was a common problem back in the day when I was using CAN on drones for research, any module we wanted off-the-shelf was made for a car or construction vehicle, meaning it was massive and heavy. There’s also the issue of the freedom, you need to have a bit of knowledge with how CAN is packed and unpacked and reading datasheets of other devices for pretty much any application that is completely custom (ie anything outside of pairing vescs together), unless you make a system that’s plug and play and sell enough that it becomes the standard everyone builds too.
Any other questions please feel free to ask!
