I recently upgraded from a single VESC & motor longboard to a dual VESC & dual motor setup, carrying through the same remote and HM-10 bluetooth transceiver setup.
The VESCs are connected via CAN, with the master having ID 0 and the slave having ID 1, and a HM-10 BT module on the master VESC's UART with "Multiple VESCs Over CAN" enabled in the nunchuk app.
With this setup, I rode over about 20km with barely any problems (aside from motor stuttering, at high current, but that's another separate issue).
Today however, I added a second HM-10 BT transceiver to the slave VESC with the aim of using a separate remote to read data in real time from the VESCs. Within 30min of riding this setup however, my main remote lost connection to the VESCs and the motor(s) became stuck on, twice. The first time, both motors were on, and the second time only the motor connected to the master VESC became stuck on.
Turning the remotes off and on again did not allow control to be regained, however they did pair successfully.
I was able the second time to get hold of my laptop and use another BT transceiver to connect to both VESCs in VESC tool and see what was going on. It was only through the keyboard control here that I was able to shut the motor down without power cycling the e-board.
My first thought was that the 2 BT modules in the e-board were interfering with each other, however even with only the main remote turned on, I was unable to regain control of the runaway motor.
The VESCs were both set up to use UART @ 9600bps under "APP to use", with a timeout of 200ms. The main remote used "COMM_SET_CHUCK_DATA" to send values to the master VESC via bluetooth every 50ms, and the master VESC had "Multiple VESCs Over CAN" and ID=0 , while the slave VESC had ID=1.
The secondary remote was connected to the slave VESC via UART over a separate BT module, and used "COMM_GET_VALUES" and "COMM_FORWARD_CAN" to get data from the slave and master VESCs respectively, one at a time, with ~200ms between each request.
I can't figure out why there would be a problem here, the VESCs wouldn't be transmitting with the same ID onto the CAN bus would they? And the fact that I was able to connect using VESC-tool over bluetooth suggests that it wasn't that the bluetooth modules had locked up.
The VESCs are connected via CAN, with the master having ID 0 and the slave having ID 1, and a HM-10 BT module on the master VESC's UART with "Multiple VESCs Over CAN" enabled in the nunchuk app.
With this setup, I rode over about 20km with barely any problems (aside from motor stuttering, at high current, but that's another separate issue).
Today however, I added a second HM-10 BT transceiver to the slave VESC with the aim of using a separate remote to read data in real time from the VESCs. Within 30min of riding this setup however, my main remote lost connection to the VESCs and the motor(s) became stuck on, twice. The first time, both motors were on, and the second time only the motor connected to the master VESC became stuck on.
Turning the remotes off and on again did not allow control to be regained, however they did pair successfully.
I was able the second time to get hold of my laptop and use another BT transceiver to connect to both VESCs in VESC tool and see what was going on. It was only through the keyboard control here that I was able to shut the motor down without power cycling the e-board.
My first thought was that the 2 BT modules in the e-board were interfering with each other, however even with only the main remote turned on, I was unable to regain control of the runaway motor.
The VESCs were both set up to use UART @ 9600bps under "APP to use", with a timeout of 200ms. The main remote used "COMM_SET_CHUCK_DATA" to send values to the master VESC via bluetooth every 50ms, and the master VESC had "Multiple VESCs Over CAN" and ID=0 , while the slave VESC had ID=1.
The secondary remote was connected to the slave VESC via UART over a separate BT module, and used "COMM_GET_VALUES" and "COMM_FORWARD_CAN" to get data from the slave and master VESCs respectively, one at a time, with ~200ms between each request.
I can't figure out why there would be a problem here, the VESCs wouldn't be transmitting with the same ID onto the CAN bus would they? And the fact that I was able to connect using VESC-tool over bluetooth suggests that it wasn't that the bluetooth modules had locked up.
