I have a two-VESC longboard that I want to control via UART.
Setup:
- Master VESC has ID of 0
- Slave VESC has ID of 1
- In VESCTool, forwarding over CAN lets me configure/control the slave VESC
- Slave VESC is set to No App
- Slave VESC Send CAN Status is set to True (false for master)
- https://github.com/bastianraschke/ESP8266VESC library for controlling VESC from an Arduino UNO clone
- I modified the above GitHub link to insert the COMM_FORWARD_CAN and slave VESC ID (1) bytes and increase the payload size by two to make room.
What works:
- I can spin up the master motor by sending a current command over UART
- I can spin up either motor in VESC tool by checking/unchecking the CAN forwarding feature
What doesn't work:
- When I try to spin up the slave motor via UART it doesn't move.
Here's what I'm sending to the master VESC over UART:
2 5 6 0 0 11 184 55 172 3 (set current to 3A) 2 7 33 1 6 0 0 11 184 164 155 3 (forward to VESC 1 and set current to 3A -- UPDATED)
If I just send the first line repeatedly, the master motor spins up nicely. If I send just the second line, or both, nothing happens.
EDIT 2: I had an error in my packet assembly code. It looks like I have the right CRC and everything now, but it's still not working.
I have exactly the same problem.
When I use PPM as input both motors spin, but with UART only the first motor spins.
Did you find any solution to this problem?
Did you find any solution for this?
I did notice that appears that the CAN forwarding packet ID is 34, not 33 (it might have changed). I'm dusting off this project so I'll be in a position to actually try it soon. In the meantime I believe it's supposed to look like { 2, 7, 34, 1, 6, 0, 0, 11, 184, 124, 25, 3 }.
The heart of the packet is a payload consisting of the packet ID and any parameters (e.g. 6 for set current, and then a signed 32-bit value for current in mA, with the most significant byte first (big endian)).
Then there is a process where the packet is wrapped in a prefix and a suffix. The prefix is a start byte (2 or 3) and a payload length (1 or 2 bytes, respectively), and the suffix is a 16-bit CRC (CCITT flavor) and a stop byte (3). Note that both the length and the CRC only include the payload in their calculations, not the wrapper.
For CAN forwarding, the payload is a COMM_FORWARD_CAN packet ID (34, I believe, at least in recent versions) followed by a one-byte CAN ID, followd by the payload to be forwarded. The forwarded payload doesn't get its own wrapper; Instead the whole thing gets wrapped up as described in the previous paragraph.
At least that's what I understand from reading the code. Like I said, I hope to try it out with actual hardware this week.
Just tried this with actual hardware, and it works! My two mistakes were that the packet ID is actually 34 (not 33), and the CAN identifier is the VESC ID (in App Settings > General), which should have been obvious but I think I was looking at the UAVCAN ESC Index or something.