VESC mods for robotics use


#1

This is just a thread where I can talk about the mods to the VESC motor controller required for use with Rover and subsequent robots.

So far the VESC has been a great motor controller. After making my own in 2016 and realizing I needed larger FETs to handle the high currents low speed control needs, I began to look elsewhere.
D4489BC1-C3C0-488B-94E4-6D4EA2F0E6F94A6448F5-9899-4A57-BECA-0834B5E66084
(Above, my motor controller design from 2016)

As I looked for other designs, I found the ODrive and the VESC. In early 2017 the ODrive was a new product and I backed one of the early batches. I also ordered a VESC to play with. The VESC began to work well for me, and so I have still not reviewed my ODrive board.

I did find however that the VESC needs a capacitor soldered on to it to make Field Oriented Control mode (a high precision high torque control method) work well. In robotics you often need precision low speed control, and while the VESC is used primarily for electric skateboards and ebikes, Benjamin Vedder the VESC creator has a thing for robotics too. Unfortunately FOC seems to have been added after the hardware was designed and the high rate of switching needed to make it work can prematurely drain the tank capacitors used to energize the FETS. This will trigger the dreaded DRV errors many VESC users encounter. There are many things that can cause DRV errors, but depletion of these tank caps below 8 volts is the one I found I needed to fix. It looks like I failed to take photos of the debugging process but after reading the DRV chips data sheet and probing the board, I determined that the voltage at these caps hit 8v before every fault. Adding a 10uf cap eliminated this condition, which I had been triggering on ramp up every time.

The caps c18 and c26 are too low value and adding a 10uF cap capable of above 20 volts or so (I cannot recall the exact cutoff) is important.

See those caps below:

6730E4DD-06C4-4689-A183-3B8588C5A734

And a modified board here:
2EA74EB0-498E-4C01-BA74-1F346AEEAB09

Once this cap is added, my constant DRV issues disappeared, and the oscilloscope confirmed that the voltage here no longer dropped below 8 volts.

That’s the only mod my VESCs need. Another mod people online have done is to move some resistors around to use an SPI encoder, but there is another port on the board you can use that is faster (hardware SPI instead of software SPI) and does not require mods - just a change in a header file for the firmware.

That’s all I wanted to share for now! I will try to put my scope on a board in the future to share my findings fully.


Beaglebone Blue[CAN] with VESC for Robotics
#2

I was recently asked a couple of questions about this via email. I thought I’d post the answers here so everyone can benefit.

The questions were: what pins did you use for hardware SPI and where is this enabled in the firmware?

For the firmware, see the commit in my branch of the VESC firmware with my changes for Rover:

Note in particular the following line:

#define AS5047_USE_HW_SPI_PINS 1

So that’s how you enable hardware SPI, and if you follow that definition in the code, you can see which pins it enables. But below I will also show pictures of the necessary wiring.

I want to point out though that you can just run the Rover firmware from that repo if you’d like - it’s generally compatible with normal VESC operation. I’ve included the compiled binaries in the git repo. It also features a new feature that keeps track of the absolute position of the encoder over many revolutions, and has a new CAN command called COMM_SET_CURRENT_GET_POSITION that sends the absolute encoder position (and velocity I believe) when you send a set_current command. That’s the single command the Rover stack uses for controlling the motors (after the motor has been configured in VESC Tool).

So feel free to give that a try!

But here are the two pictures of Rover that will clarify the wiring:
6544F0C3-B197-4180-B235-F56CF2865D61B803B1F1-D293-4CA0-9DE9-8419B68A0A13

Thanks for reading and feel free to ask any questions if that’s not clear!


Beaglebone Blue[CAN] with VESC for Robotics
#3

Hello, Taylor!

Great for sharing the stuff about VESC and SPI encoders. Most of all I like the Love idea, because we all need a proper inner drive.

I have a situation and I’m a little bit blurry.

  1. For a BLDC taken from an hover board, 6.5" type you recommend using VESC or Odrive? These things I want to connect them with ROS eventually.

  2. Have you seen proper off-axis encoders ideally with absolute indications? I’ve seen something from Allegro, but…

All the best,
Ktysai


#4

Absolute encoders don’t seem practical for wheels or motors, where what you always need is relative, like how far did I move. And absolute encoders in general are more expensive.
Absolute coordinates in space would be very valuable, but are very hard to get except in a highly controlled environment like a milling machine, and even there it’s rare to have absolute.


#5

Right, Dave!

My problem is the integration with ROS. There’s needed an absolute encoder, at least at my current level of expertise.

Thanks for sharing!