Issue with the Odrive custom firmware based on version 0.4.0

[SunHR-SWJTU]

Hello Nate711,

I flashed your Odrive custom firmware based on version 0.4.0, but it sometimes caused the uncontrolled spinning of some motors. These motors will spin up to full speed if I use odrv0.axis0.requested_state = AXIS_STATE_CLOSED_LOOP_CONTROL. I tested the firmware of version 0.4.0-master, it still happened. But after I flashed version 0.4.11-master, it works. So maybe some problems existed in version 0.4.0.

I'm very sorry to ask if you can migrate your changes to version 0.4.11. Or is there another way to solve this problem?

Thank you so much.

[Ginot-Joah]

Hello SunHR-SWJTU

I have ever seen that Nate711 reply in odrive forum declaring he just have a bit change in odrive firmware.So maybe you should pay your attention on the forum.

In my opinion , I suppose he only change the part about outer loop trajectory control for adapting the theta and gamma from teensy .

I think your issue is more about the index search which would impact the inner loop trajectory control . There is idx_search_speed in file config that it is used in Encoder::run_index_search() . And this function will make the value into inner loop , as a result , if the this value is too big , the inner current control loop would not convergence.

In a word , maybe close the index search or reduce its speed will work . If it does not , look carefully into this two loop .

Hope it would help for you .

[SunHR-SWJTU]

Hello SunHR-SWJTU

I have ever seen that Nate711 reply in odrive forum declaring he just have a bit change in odrive firmware.So maybe you should pay your attention on the forum.

In my opinion , I suppose he only change the part about outer loop trajectory control for adapting the theta and gamma from teensy .

I think your issue is more about the index search which would impact the inner loop trajectory control . There is idx_search_speed in file config that it is used in Encoder::run_index_search() . And this function will make the value into inner loop , as a result , if the this value is too big , the inner current control loop would not convergence.

In a word , maybe close the index search or reduce its speed will work . If it does not , look carefully into this two loop .

Hope it would help for you .

Thanks for your suggestion. But I'm afraid that Doggo wouldn't work properly after I disabled index search. Anyway, I will try the method you suggested. Thanks again.

[Nate711]

Could you tell me more about your problem? I was never able to get the index pin search to work with our firmware. I think they did fix it though in future releases.

[Ginot-Joah]

I think I didn't make the encoder clear. These days I was trying to turn its leg at the best position automatically when powering on by itself. That is a problem about the absolute position give by the encoder.

At first I think the ABI encoders can not be absulote .However, I am wrong. The index search is only about it. In fact, the sinal Z should be responsible for this absolute position via the index search function. I verify it by Suspending the Z pin and set index search into false, still running well.

As a result ,I think the Z pin have no sinal but I dont have oscilloscope to monitor it. If it has no sinal, without questions, it will spin uncontrolledly. And I notice the encoders used in doggo can be a complete absolution by burning its OTP memory but I don't konw if it is neccessary.Hope someone would give me a hand.

By the way , the run_index_search do the same thing as run_closed_loop_control_loop until running this code....
`axis_->run_control_loop(&{
phase = wrap_pm_pi(phase + omega * current_meas_period);

    float v_alpha = voltage_magnitude * arm_cos_f32(phase);
    float v_beta = voltage_magnitude * arm_sin_f32(phase);
    if (!axis_->motor_.enqueue_voltage_timings(v_alpha, v_beta))
        return false; // error set inside enqueue_voltage_timings
    axis_->motor_.log_timing(Motor::TIMING_LOG_IDX_SEARCH);

    // continue until the index is found
    return !index_found_;
});`

It just calculate the v_alpha and v_beta directly and run_closed_loop_control_loop use current_setpoint and phase to do this thing. This two value is about the FOC current control and it finally control the motor through SVPWM. As a result , I don't think this will go wrong as they two are just different in the run_control_loop shown above.......

If there's something wrong, hope you can point out, thanks.

[SunHR-SWJTU]

Could you tell me more about your problem? I was never able to get the index pin search to work with our firmware. I think they did fix it though in future releases.

Before I saw the BOM, I used AS5047P, Odrive 3.5-48V and MN5212 KV340 to repeat your work. AS5047P communicated with ODrive by ABI pins. After I assembled the components, I flashed your custom firmware into the ODrive. Then I configured the parameters according to the procedure in Nate711/ODrive/tools/doggo_setup.py. (Because AS5047P was used, .encoder.config.cpr was asigned to 4000.) After these steps were done, I powered the Odrive with a 6s-LiPo battery, the motors span up to very high speed. I was very confused. Then I did several tests.

1. I wonded if the configuration leaded to this problem. So I configured the parameters according to ODrive Documentation. The problem remains.
2. Then I wonded if it is the custom firmware that caused this problem. So I flashed the firmware of 0.4.0-master into the ODrive, and configured the parameters according to ODrive Documentation. The problem remains.
3. Then I found that the BOM was provioded. So I used AS5047D to replace AS5047P, and configured .encoder.config.cpr back to the default 2000 (same as Nate711/ODrive/tools/doggo_setup.py). The problem remains.
4. I then wonder if this problem has been fixed in the new firmware release. So I flashed the firmware of 0.4.11-master into the ODrive, and configured the parameters according to ODrive Documentation. It works!

So I think probably some bugs in the firmware of version 0.4.0 caused this problem. It should be noted that this problem does not occur every time, but very frequently. But in version 0.4.11, this has never happened. I tried to modify the firmware of 0.4.11 according to your changes in version 0.4.0 but failed for lack of understanding about ODrive. Considering that you are familier with the source code, I will be very appreciated if you release a custom firmware based on the latest version.

By the way, if index search is disabled, how to configure other parameters? Please forgive my ignorance , but if there were a configuration guide, it would be easier for researchers in other disciplines to duplicate Doggo.

Thanks a lot!

[danbo2]

Hi SunHR,

Have you implemented the RobotDog ? We are repeating it but meet some issues when assembly. Can you give me your email address ?@SunHR-SWJTU
Thanks,
Yiyi

Could you tell me more about your problem? I was never able to get the index pin search to work with our firmware. I think they did fix it though in future releases.

Before I saw the BOM, I used AS5047P, Odrive 3.5-48V and MN5212 KV340 to repeat your work. AS5047P communicated with ODrive by ABI pins. After I assembled the components, I flashed your custom firmware into the ODrive. Then I configured the parameters according to the procedure in Nate711/ODrive/tools/doggo_setup.py. (Because AS5047P was used, .encoder.config.cpr was asigned to 4000.) After these steps were done, I powered the Odrive with a 6s-LiPo battery, the motors span up to very high speed. I was very confused. Then I did several tests.

1. I wonded if the configuration leaded to this problem. So I configured the parameters according to ODrive Documentation. The problem remains.
2. Then I wonded if it is the custom firmware that caused this problem. So I flashed the firmware of 0.4.0-master into the ODrive, and configured the parameters according to ODrive Documentation. The problem remains.
3. Then I found that the BOM was provioded. So I used AS5047D to replace AS5047P, and configured .encoder.config.cpr back to the default 2000 (same as Nate711/ODrive/tools/doggo_setup.py). The problem remains.
4. I then wonder if this problem has been fixed in the new firmware release. So I flashed the firmware of 0.4.11-master into the ODrive, and configured the parameters according to ODrive Documentation. It works!

So I think probably some bugs in the firmware of version 0.4.0 caused this problem. It should be noted that this problem does not occur every time, but very frequently. But in version 0.4.11, this has never happened. I tried to modify the firmware of 0.4.11 according to your changes in version 0.4.0 but failed for lack of understanding about ODrive. Considering that you are familier with the source code, I will be very appreciated if you release a custom firmware based on the latest version.

By the way, if index search is disabled, how to configure other parameters? Please forgive my ignorance , but if there were a configuration guide, it would be easier for researchers in other disciplines to duplicate Doggo.

Thanks a lot!

Hi SunHR,

Have you implemented the RobotDog ? We are repeating it but meet some issues when assembly. Can you give me your email address to discuss some issues ?
Thanks,
Yiyi

[SunHR-SWJTU]

Hi SunHR,

Have you implemented the RobotDog ? We are repeating it but meet some issues when assembly. Can you give me your email address ?@SunHR-SWJTU
Thanks,
Yiyi

Could you tell me more about your problem? I was never able to get the index pin search to work with our firmware. I think they did fix it though in future releases.

Before I saw the BOM, I used AS5047P, Odrive 3.5-48V and MN5212 KV340 to repeat your work. AS5047P communicated with ODrive by ABI pins. After I assembled the components, I flashed your custom firmware into the ODrive. Then I configured the parameters according to the procedure in Nate711/ODrive/tools/doggo_setup.py. (Because AS5047P was used, .encoder.config.cpr was asigned to 4000.) After these steps were done, I powered the Odrive with a 6s-LiPo battery, the motors span up to very high speed. I was very confused. Then I did several tests.

1. I wonded if the configuration leaded to this problem. So I configured the parameters according to ODrive Documentation. The problem remains.
2. Then I wonded if it is the custom firmware that caused this problem. So I flashed the firmware of 0.4.0-master into the ODrive, and configured the parameters according to ODrive Documentation. The problem remains.
3. Then I found that the BOM was provioded. So I used AS5047D to replace AS5047P, and configured .encoder.config.cpr back to the default 2000 (same as Nate711/ODrive/tools/doggo_setup.py). The problem remains.
4. I then wonder if this problem has been fixed in the new firmware release. So I flashed the firmware of 0.4.11-master into the ODrive, and configured the parameters according to ODrive Documentation. It works!

So I think probably some bugs in the firmware of version 0.4.0 caused this problem. It should be noted that this problem does not occur every time, but very frequently. But in version 0.4.11, this has never happened. I tried to modify the firmware of 0.4.11 according to your changes in version 0.4.0 but failed for lack of understanding about ODrive. Considering that you are familier with the source code, I will be very appreciated if you release a custom firmware based on the latest version.
By the way, if index search is disabled, how to configure other parameters? Please forgive my ignorance , but if there were a configuration guide, it would be easier for researchers in other disciplines to duplicate Doggo.
Thanks a lot!

Hi SunHR,

Have you implemented the RobotDog ? We are repeating it but meet some issues when assembly. Can you give me your email address to discuss some issues ?
Thanks,
Yiyi

My email address is [email protected].

[Ginot-Joah]

@SunHR-SWJTU
Look at the function Controller::update, for how odrive make the control.Here are the describtion given by madcowswe:

Purpose:
Motor force = - kp * (position - desired position) - kd * velocity
We currently have:
current = vel_gain * (desired_vel - actual_vel) and
desired_vel = pos_gain * (desired_pos - actual_pos).
Substitute in desired_vel into the 1st formula, and you get:
current = vel_gain * (pos_gain * (desired_pos - actual_pos) - actual_vel)
Multiply in vel_gain:
current = vel_gain * pos_gain * (desired_pos - actual_pos) - vel_gain * actual_vel
And now you can see this is the exactly the same control law that you wanted, if you set:
vel_gain * pos_gain = kp
vel_gain = kd

Now you look at Nate711's function Controller::update, he make it in an elegant way. He use alpha and beta to express the position and velocity of the two axises. It corresponds to the p gain and d gain, and plus them together for current value!! So he can control two axises at the same time! It's billiant!

However, he use a value "pll_vel_" as input which is assigned in a PLL loop of Encoder::update. Is it the axises' velocity? I don't know..
Emmm, replacing the Controller::update in 0.4.11 by Nate711's Controller::update may work. But the new firmware had change pll_vel_ into vel_estimate_......

[SunHR-SWJTU]

@Nate711 @Ginot-Joah
Thank you for your kind help. I run the doggo_setup.py and the all motors worked.

Previously, after a failure to run the script, I had opend it and should set up Doggo according to the bare_bones_calibration() which disabled the index search, because the actual calibration in main() is it. However I seemed to take it for granted that full_calibration() is better than bare_bones_calibration(), so I had use full_calibration() which enabled the index search, thus the problem occured. It has been verified that, as you said, uncontrolled spinning is related to the index search.

Thanks again! I'll continue to do the following work to repeat Doggo.

[Ginot-Joah]

@SunHR-SWJTU
What you do is just evaded the index search, but I am afraid that the problem should be solved. I think it is the key to stand it up by itself rather than adjusting its legs by hand before powering up.

[akrolic]

Hey @Ginot-Joah,
I agree with you, I would also like to find a solution to this issue. Have you spent anytime trying to come up with a solution since your posts from 2019? Please let me know because I am at a point know where I will begin looking at migrating towards a newer firmware version and solving the encoder absolute index problem would be a priority. From what I understand the latest odrive firmware has support for absolute encoders, so migration should solve this problem more or less on its own.

Thanks!