Improve stopping performance

[theArchLadder]

Stopping performance when activating poshold etc, has room for improvement.

The current method tries to calculate the stopping distance, these are the problems i see with the current code:

• Calculating a accurate stopping distance is close to impossible with so many variables (wind, deg/s, max_bank_angle, not reaching full bank angle, etc), so the calculated distance will either be shorter than possible or longer than necessary.
• pos_p may not give posr_p a big enough error to give full bank angle.
• the jerk limit of ~100deg/s is low.

Why calculate a stopping distance when we just want to stop as fast as possible? With pos_p and posr_i at zero (target velocity is always 0), the stopping performance is exactly as i want it, it just stops as fast as it can and looks beautiful, no need to calculate the stopping distance here. Here's my idea on how the code could work: position hold is activated, go into "stopping mode", target velocity is simply 0, use only posr_p and posr_d to achieve this, stay in this mode until velocity is close to zero or a timeout is reached, then go into the normal position hold mode.

posr_i could be used to fight wind but could give back-tracking if the anti-windup is not good enough. It might make sense to have a higher jerk limit during stopping, but higher jerk limit during WP navigation gives violent maneuvers when switching to the next waypoint.

@digitalentity said a similar method was used before in inav, but it gave oscillations. My test flights with pos_p=0 confirms that the new posr_d scaling and default removes those oscillations.

[digitalentity]

Scheduling for 1.2

[theArchLadder]

More testing done with agressive tuning. My quad stops nice and fast, but then slowly moves a meter or two after that before stopping completely. Changing inav_gps_delay from default 200 to 50 seems to remove this problem. Using M8N GPS with HIGH_G and VELNED=ON. This was with nav_pos_p=0, nav_posr_i=1, so target speed is always zero and the stopping distance calculation is not used.

See this for more info, EQ45 also seems to have this behavior. http://www.rcgroups.com/forums/showpost.php?p=34581284&postcount=5274

[gurkenfolie]

with nav_pos_p = 0 no RTH is possible.

[theArchLadder]

@gurkenfolie Correct, but it allows us to test how stropping would behave if we had the feature requested in this issue.

[gurkenfolie]

any improvements here so far? isn´t it possible to bank hard (45°) or set posr_p to 0 for a specific time (e.g. 0,5 seconds) when the sticks are released and centered?

[theArchLadder]

@gurkenfolie #254 helps a lot with this. The bad news is that my new job leaves me with very little time for inav :(

[Mathotg]

Over the past few month I did flew quads with Inav, quads with tarrot module, bebop 2,...

Basically they all fly about the same. the Parrot Bebop2 has also a kind of stop when you release the sticks which is similar to what I got on my robocat 250 with the modified INAV. i did extensively explain the modifications on rcgroups. from my point of view, further improvement does not add a lot off value.

I think also that the problem is a bit more complex that what we all think. The sticks are close to the center /released not only when we want to stop the motion but also when trying to slow down , to achieve constant speed while the wind is pushing is... I do from time to time get the quad going in braking mode while I try to make a straight at constant speed even if my stick is not exactly at center. I plan to test lower stregnth for angle mode and see if it improves the things...

All I want to say is that braking hard might also jeopardize a bit the behavior in translation or in navigation/cruise mode (dolphin behavior)... It has to be tough cleverly and properly tested.

that's my 5 cents

[digitalentity]

@Mathotg can you remind me what your modifications to INAV were?

[Mathotg]

I did set banking angle to 45° I did double in the code the jerk limit I did also double the effect of nav_pos_r param in the code then the key is to have a nav_pos_p not too high and a nav_pos_i close to 200 to predict a distance making sense and avoid backtracking. I do fly a 280 quad and a 600 quad with these setting and it works prettywell. So well that I did not update to the latest Inav versions

[digitalentity]

If you can submit a PR I'll probably merge it right away.

[Mathotg]

I'm not enough familiar to make a PR (Push request?) so here are the 3 lines of code changed

in navigation_rewrite_multicopter.c I did multiply by 2 velErrorX and velErrorY

velErrorX = 2.0f* (posControl.desiredState.vel.V.X - posControl.actualState.vel.V.X); velErrorY = 2.0f* (posControl.desiredState.vel.V.Y - posControl.actualState.vel.V.Y);

float maxAccelChange = US2S(deltaMicros) * 3400.0f;

PIDs were scale between INAV 1.01 and 1.1... I did that update also on my 1.01 based version in which the I did made the modification.

Like I wrote, nav posP has to be around 20, nav_pos_d around 200 to compute a braking distance making sense. I do not hva my dump with me right there but I can look for it tonight if needed.

On RCgroups I'm eq45, so you can my be find more info on the thread.

[theArchLadder]

@Mathotg The stick controll issue can be solved by using nav_user_control_mode = CRUISE Your approach seems to simply be posr_p and posr_d tuning, i havedone that a lot and IMHO it's a dead end, you either get nervous behavior or slow braking.

Feel free to check out #254 , more work needed there but it made a huge difference in stopping performance for me.

I really wish i had more time for inav...

[Mathotg]

Going to cruise change the way it flies. I prefer attitude mode... so I will continue on that. It's closer yo helicopter and I fly both.

Indeed #254 seems interesting. Well, i did scale the gain and I have a solution which works. i did put graph on rcgroups. You can do the same and compare performance. May be yours brake better but it s just a question of taste. Basically, we are two flying my code and we are happy.

Also, i needed to stop testing since i had to redo a recovery each time i try to flash the f3.

Keep the good work

Regards

Gilles

Le 14 juil. 2016 21:03, "theArchLadder" notifications@github.com a écrit :

@Mathotg https://github.com/Mathotg The stick controll issue can be solved by using nav_user_control_mode = CRUISE Your approach seems to simply be posr_p and posr_d tuning, i havedone that a lot and IMHO it's a dead end, you either get nervous behavior or slow braking.

Feel free to check out #254 https://github.com/iNavFlight/inav/pull/254 , more work needed there but it made a huge difference in stopping performance for me.

I really wish i had more time for inav...

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/iNavFlight/inav/issues/155#issuecomment-232761175, or mute the thread https://github.com/notifications/unsubscribe/AQn5wxouZSX39_fSR9d3fWGyNYVPGnS2ks5qVogNgaJpZM4ID7Sv .

[stale[bot]]

This issue / pull request has been automatically marked as stale because it has not had any activity in 60 days. The resources of the INAV team are limited, and so we are asking for your help. This issue / pull request will be closed if no further activity occurs within two weeks.

[stale[bot]]

Automatically closing as inactive.