How to start anticogging calibration over usb?


#1

Hi anybody,

iam struggling with starting the anticogging calibration.

As Wetmelon says: To enable anti-cogging, you wait until the motors have finished their startup calibration, then send the command “t” over USB.

How would i send a “t” over USB with the odrive library?

EDIT: ok, i can also send a t over usart, but when sending the “$t!” nothing happens.
Is the cogging map allocated automatically? I cannot find anything about that in the code.

EDIT: When setting a pos_gain of 500 (100kv, 12V motor), the calibration starts, but i need to damp the resulting vibrations from outside to reach the .calib_pos_threshold and .calib_vel_threshold that i already have set to 10.0f


#2

Hi @flyingmoro

To enable anti-cogging you currently have two options.

1. Use the legacy USB function to enable the calibration.

In ODrive/Firmware/MotorControl/commands.h comment out #define USB_PROTOCOL_NATIVE and uncomment #define USB_PROTOCOL_LEGACY and and flash the board. Use the instructions seen here on how to connect to the boar and control it over usb using the legacy protocol. Once its all working correctly you just send ‘t’ over usb and the anti-cogging process will begin. It takes around 5min over which time the motors will slowly turn. Note that if you remove power from the odrive board the calibration data will be lost and you will need to do it again.

or

2. Try an commit buy @Wetmelon from a few days ago that has added this function to the native usb protocol

The changes can be found here. It uses the native USB protocol so no need to make changes in commands.h. Instead you just follow the standard method of communication over usb.

Its my understanding that the anti-cogging feature in its current form is a very rough proof of concept and thats why it has no real documentation at the moment. I expect this will change in the near future as a more streamlined browser based interface is developed.

I hope that was of some help and remember if you get stuck you can always ask for help over on the discord support channel.


#3

I suggest increasing the vel_integrator_gain quite a bit For the N5065 270kV motors using a 4096 CPR encoder, I found that using the stock calib_pos_threshold and calib_vel_threshold, the following gains worked extremely well:

pos_gain = 200.0
vel_gain = 0.0005 (5.0/10000.0f)
vel_integrator_gain = 0.0150 (150.0/10000.0f)


#4

Hi and thanks for the replies,

i know that i own quite special motors (12V 100kv nom 16A) and i have to tune all parameters a bit different.
In my application iam working with very small amounts of momentum, when the robot is close to zero degrees tilt angle. The amount could fall below the amount of cogging torque so therefore my control algorythms get disturbed quite a lot by that.

During the calibration i tried a lot with changing the gains but i didnt found a setting without too strong vibrations. I then added additional differential and integral parts in the odrive position control and this caused the vibrations to stop and calibration to complete, but the results are not that good as i expected.

As madcowswe mentioned somewhere, it is possible to read out the cogging map with VSCode during debug mode, but i wasn’t able to do this. I set a breakpoint inside the calibration function and it gets hit when calibration completes, but the cogging_map content is not available as VSCode states although i can see other variables values. Does anyone have an idea concerning this issue?

Another thing is, is it possible to store the map permanently after calibrated once? Do i have to “hardcode” it inside the initialization of the cogging_map like so: .cogging_map[] = {0.03, 0.023, ...}; Iam a bit confused as in the Anticogging_t struct it gets declared as float *.


#5

I apologise that using the anticogging is quite cumbersome, it is actually not really a supported feature just yet, just a proof of concept. We will add the features required to read entire arrays (the cog_map) to python, as well as a mechanism to store it persistently; in the near future.

If you really are inclined to make it work today, I would suggest that you redeclare the cogging_map from float* to a statically allocated array like float cog_map[ENCODER_CPR];. Then hopefully VSCode debugger will be much happier to inspect it. When you do this, you will also need to remove the present malloc allocation.

Given that you now have redclared it as a static array, you can indeed set it like .cogging_map[] = {0.03, 0.023, ...};.