Direct CAN velocity control

Discussions regarding the Field Oriented Control (FOC) implementation on the VESC.
Posts: 21
Joined: 20 Jan 2016, 04:29
Location: Washington, DC

Direct CAN velocity control

Postby jgeating » 21 Jul 2018, 21:00

I'm trying to control the velocity of a motor (and position of another motor) over CAN. Testing on the same motor, I can control position just fine, but when I try to control speed, it craps out within a few rpm zero crossings (going from a positive rpm to negative) or if I hover around 0 rpm, and I have to restart the microcontroller to get the motors to respond again. The position signal can cross zero and is jittery at times (might be the transmitter), but it never causes the motor to stop responding. As soon as I restart the microcontroller, I can control speed again until I cross zero a few times.

I'm using a Teensy 3.6 microcontroller:
Talking through this CAN shield: ... nsy-35-36/
through a logic level converter to the VESC.

My grounding is a little wierd, in that I'm using the battery ground as the CAN ground. I'm using a slipring to control the VESC, so using the battery ground was a way to preserve channels and let me double up battery current. I also have 3 VESCs per channel of the Tenesy shield (two CAN channels with 3 VESCs each). They're all just wired in parallel to the CAN H and CAN L of their respective channels (CAN0 and CAN1). However, I'd expect bad grounding to cause drops, not indefinite loss of CAN comms until a restart.

Here is the relevant code:

Code: Select all

rpm[wheel]  = ch[0]*3;
uint32_t temp = rpm[wheel];
if (motorsEnabled){
  for (i = 0; i < lenRPM; i++) {
    dMsg.buf[lenRPM-i-1] = temp >> 8*i;
  } = wheel | CAN_PACKET_SET_RPM << 8;
  Can1.write(dMsg);  // CAN1 for wheels

And a picture of the setup:

Thanks for reading!
_DSC0663.JPG (178.36 KiB) Viewed 457 times
_DSC0662.JPG (297.48 KiB) Viewed 457 times

Posts: 21
Joined: 20 Jan 2016, 04:29
Location: Washington, DC

Re: Direct CAN velocity control

Postby jgeating » 21 Jul 2018, 21:09

Update: If I unplug two of the CAN connections to the other motors, the remaining single motor works just fine. The motion is both smoother, and it doesn't crap out when I cross zero. I couldn't find much concrete information about proper multiple device CAN networking, so I just wired everything in parallel. I set the CAN ID's in VESC tool, which lets me control the motors individually. The CAN shields are properly terminated with 120 ohm resistors, and I would assume the VESC is as well. Any CAN experts out there know what could be the problem?

Thanks! Once I get this robot up and running, I'm excited to post some videos here showcasing the precision and power of the VESC 6.

Posts: 309
Joined: 28 Mar 2016, 14:37
Location: FR Valence

Re: Direct CAN velocity control

Postby pf26 » 23 Jul 2018, 08:48

Having CAN signals through sliprings seems a bit scary to me for long term reliability.. I would have used sliprings for power, and wireless (802.15.4) for control. If you use CAN through sliprings, maybe using some small capacitors (47pF ?) between 0V and both CANH and CANL, can help filter the possible rotating contact noise.
Usually, one prefers chaining the CAN devices, and having terminating resistors on both ends. Not sure the VESC6 has the termination resistor embedeed, it may be manufacturer dependant. Using a parallel/start cabling is likely to cause more issues, at least you would not want to use 4 times 120R resistors, that would be too much load (possibly you could try with 270R instead).
Nice setup anyway, must be tough to control with less degree of freedom (3) than motors to drive (6) if I understand well ?

Posts: 21
Joined: 20 Jan 2016, 04:29
Location: Washington, DC

Re: Direct CAN velocity control

Postby jgeating » 26 Jul 2018, 23:39

Thanks pf26, appreciate the reply. You're quite active here and super knowledgeable. Do you have any links to recent work you've done? A while ago I saw you using a VESC to control the pitch of an airfoil, but that was ages ago. I'm curious what you've done since.

I'm definitely going to look at the wireless control - I was trading CAN vs. UART vs. PPM and all the while forgot wireless control was available. For the 3 motors NOT going through sliprings (these control the yaw or pointing angle of the wheels), I'll stick with CAN, but run a shielded cable (CANH, CANL, GND) from the microcontroller transceiver to the three nodes serially, and terminate with a 120 ohm resistor (the microcontroller transceiver already has terminating resistors for both of its channels).

Re. DOFs, there are three wheels, but 6 DOFs and 6 motors. Each wheel has a drive motor to spin the wheel, but then also a yaw motor to aim it. It's called "swerve drive", and it's pretty popular in first robotics among other applications. Never to this power level/package size that I've seen though. I advised and had a senior design team build it for me this past year:

Bad news - two days ago it looks like I may have simultaneously bricked all 6 of the VESCs on the robot in parallel. Just when I was getting confident to give them all power simultaneously. All I did was switch all the CAN rates from 500K to 125K, thinking that might help with the comms issues. I likewise switched the microcontroller transceiver code to 125K, and may have made some other small changes (position mode instead of RPM), but when I hooked it up, the motors buzzed like they were in position control mode, then the sound slowly faded, and I got the dreaded red blinking LED. 2x blinks, even after restart. VESC tool doesn't show any faults in the terminal though. I can connect and measure resistance/inductance, but when I try and measure the flux linkage, the motor doesn't rotate or try. Are my DRV8302's toast? And before I think about buying 6 new VESCs, is it feasible to replace these, assuming I had access to proper equipment - which I probably do.


Return to “FOC”

Who is online

Users browsing this forum: No registered users and 1 guest