[Feature Request] Trapezoidal Trajectory/Position Control

[raess1]

It would be really great if the VESC firmware included an option for trajectory/position control, beyond the single rotation currently supported. At the ODrive they recently implemented a trajectory planner, and it would be really nice if VESC's supported this too. Maybe having the source code available also makes it easier to implement.

Would also be great if the position control could accept commands on encoder counts, same as the Odrive.

What do you guys think? Would it be possible to implement this features in the VESC FW?

[Peemouse]

Hi !

My opinion is that the VESC is basically an ESC.
It should stay an ESC.
Thanks to its numerous way of communication, the use of an additionnal controller is the best way to go whatever the type of application (bike, skateboard, machining, multicopter...) keeping thus the VESC generic for any kind of use.

Regards,

Clément

[raess1]

agreed and disagree :-)
I am not saying we should remove any of the existing function (so it will still be generic for any kind of use) rather improve/add already existing functions so the VESC can be even more generic in robotics applications.

Position control (Servo Control) is already implemented in VESC. so to improve how we can do multi-turn encoder count commands for position control would be a great feature for many applications.

One thing I love about the VESC is that it has alot of features "in-house" which mean we dont need use even more additionnal controllers to get the desired features.

I think the Trapezoidal Trajectory/Position Control is one of the main function that is missing in the VESC for a lot of robotics builder out there.

best regards
/RF

[raess1]

So we made a a couple of changes in the FW to handle multi-turn position control. we do no longer compute shorted angles , we use full revolutions.
The encoder position still remains degrees. For example one can control 0-2160degress for a 6:1 gearbox and the output is 360degress on output.
we added a command in the FW: COMM_SET_POS_CUMULATIVE.

demo video on it working: https://www.youtube.com/watch?v=lDOAy9ZJrX0

[raess1]

We are working on an updated/modified version of original firmware for the VESC (based on FW3.33).

Key Features
1: Multi-turn posistion control (controlling motor position over multiple encoder turns, for example 0-2160Degress)
2: Removed shortest route rotation -+180 degress
3: Handle encoder rollover up or down.
4: First test of implement a cascaded style position, velocity and current control loop. The idea was previously tested on our simulator for cascaded position and speed control (http://grauonline.de/alexwww/motorsim/motorsim.html)

Some motion testing with new firmware over ROS
sin motion #set_pos = math.sin(time.time() % 10.0 / 10.0 * 2 * math.pi) * 500 + 500
https://www.youtube.com/watch?v=iflbHGTBwwo&feature=youtu.be

[vedderb]

Nice work! If you give me a pull request, I can implement it in the firmware after some testing.

I think the shortest route rotation should still be there, as it is very useful for applications where you only care about one turn, such as gimbals. Ideally the multi-turn position controller should be a separate implementation, and also include acceleration and velocity parameters.

I would say a control mode named motion control, with a motion control function in mcpwm_foc (or separated into a new file) that gets called in the same way as the current position control and speed control functions. That new control mode should not only have the PID parameters, but also acceleration and speed parameters. There should also be an option to wrap the speed controller, or to run position control straight away. Using an inner speed controller has several advantages, but the biggest disadvantage is that measuring speed with low noise and low latency is tricky as there is no direct speed measurement available - the speed measurement is derived from tracking the position with a PI tracker, whereas the position is measured directly.

[raess1]

Thanks @vedderb
I gave you a pull request. Maybe you can look on the code and see how you could improve the feature further. A true motion controller would be a great feature for the VESC!

BTW: We based the modification on FW3.33 from @tlalexander/bldc , since we could not get the encoder (AS5048A) via SPI & HW pins to work on newer versions. :(

@tlalexander/bldc did also implement the the "Handle encoder rollover up or down" in the FW, which we used.

We was also thinking of using the (float)enc_counts for the encoder. So the counts would not be hard coded in the FW & could be easily be adjusted in vesc tool same way one adjust the ABI counts.
Did a commit for that in a separate branch:(untested).
sequoia-hope@aca9eaa
Did we get the correct you think? :-)

We Would love to see your feedback and improvements to extend the VESC for even futher robotics appliactions!

/RF

[ddosoff]

2cents: working with cumulative angles is better then tachometer steps.

ODrive implemented cogging compensation algorithm. I think cogging compensation important for VESC too. Strong cogging is bad for my winch app, bad for slow speed skateboard driving.

Some common interface should be done. Cogging compensation and position control have to be implemented from ODrive to VESC.

[supercrazysam]

@ddosoff Totally agree especially on trajectory control and cogging compensation.
Having trajectory control implemented in VESC would be extremely beneficial to all opensource robotic project.

Any update on trajectory control? I waited for this feature for almost 2 years now.

[hexakopter]

I think there are no updates in that regard and I don't see it on the current TODO list on the VESC project website (https://vesc-project.com/node/110), but that list also wasn't updated for some time.

I am also thinking that adding some motion control features would benefit a lot of robotic applications, especially with the recently added HFI functionality to track the motor nicely at low speeds without extra encoders needed. That is a big advantage over the ODrive project when the motion control functionality would not lag behind.