Servers by jDrones

Guided velocity does not match desired velocity

companioncomputer
pixhawk2
arducopter
guided

(CN) #1

Hi all,

we are facing some trouble regarding the setpoint velocity send my mavros/mavlink.
The guided velocity is not matching the desired velocity (see pictures below). Do you have any clue why this happens or how we could fix this? We was using Here+ RTK, Pixhawk 2.1 Cube and 3.5.3 firmware.


Guided mode velocity control: instantaneous velocity control instead of integrating position errors
(CN) #2

For sending commands, we are using the follow test commands:

!/bin/bash

echo "Velocity 1,0,0"
rosservice call /flytos/navigation/velocity_set "{vx: 1.0, vy: 0.0, vz: 0.0, yaw_rate: 0.0, tolerance: 0.0, async: false, relative: false, yaw_rate_valid: true, body_frame: false}"

echo "Flying for 5 seconds"
sleep 5

echo "Velocity 0,0,0"
rosservice call /flytos/navigation/velocity_set "{vx: 0.0, vy: 0.0, vz: 0.0, yaw_rate: 0.0, tolerance: 0.0, async: false, relative: false, yaw_rate_valid: true, body_frame: false}"

echo "Velocity 0,1,0"
rosservice call /flytos/navigation/velocity_set "{vx: 0.0, vy: 1.0, vz: 0.0, yaw_rate: 0.0, tolerance: 0.0, async: false, relative: false, yaw_rate_valid: true, body_frame: false}"

echo "Flying for 5 seconds"
sleep 5

echo "Velocity 0,0,0"
rosservice call /flytos/navigation/velocity_set "{vx: 0.0, vy: 0.0, vz: 0.0, yaw_rate: 0.0, tolerance: 0.0, async: false, relative: false, yaw_rate_valid: true, body_frame: false}"

echo "Velocity -1,0,0"
rosservice call /flytos/navigation/velocity_set "{vx: -1.0, vy: 0.0, vz: 0.0, yaw_rate: 0.0, tolerance: 0.0, async: false, relative: false, yaw_rate_valid: true, body_frame: false}"

echo "Flying for 5 seconds"
sleep 5

echo "Velocity 0,0,0"
rosservice call /flytos/navigation/velocity_set "{vx: 0.0, vy: 0.0, vz: 0.0, yaw_rate: 0.0, tolerance: 0.0, async: false, relative: false, yaw_rate_valid: true, body_frame: false}"

echo "Velocity 0,-1,0"
rosservice call /flytos/navigation/velocity_set "{vx: 0.0, vy: -1.0, vz: 0.0, yaw_rate: 0.0, tolerance: 0.0, async: false, relative: false, yaw_rate_valid: true, body_frame: false}"

echo "Flying for 5 seconds"
sleep 5

echo "Velocity 0,0,0"
rosservice call /flytos/navigation/velocity_set "{vx: 0.0, vy: 0.0, vz: 0.0, yaw_rate: 0.0, tolerance: 0.0, async: false, relative: false, yaw_rate_valid: true, body_frame: false}"


(rmackay9) #3

CN,
I looks like it's trying to do what's been requested but it can't, this leads to it getting behind and it then overshoots. I think it would perform better if you more gradually increased the velocity request instead of immediately jumping it to 100.

To add some more background, when the velocity controller is used it actually also tries to maintain a position and this position comes from the integrated velocities. I suspect in the velocity controller we are not acceleration limiting the requested velocities so this naturally leads to bad behaviour when the velocity inputs are changed too rapidly.


(Amilcar Lucas) #4

My last two PRs improve some of the stuff you are trying to do.

The follow me example worked a lot better for us when we started using the guided_posVel mode and applied the above patches.


(CN) #5

Does someone know why NTUN.VelY is not zero?


(CN) #6

Does somebody have an idea to reduce the overshoots? It is not possible for us to send velocity more gradually.

Are there any parameters which can be tuned to get no overshoots? Normally, in Guided mode, the drone should reach the desired speed (for example 1m/s) and should hold this speed.

Actually, it looks for me that it change the speed always to be sure that it reaches 5m distance after 5 seconds for example if we send a flying commant to fly with 1m/s for 5 seconds.

Thanks a lot for your help!


(Amilcar Lucas) #8

If you have a final position the controller will probably work a lot better if you provide it to it.

If not then you could try to supply an acceleration and change the velocity controller to take that acceleration into account.


(CN) #9

Attached, 2 screenshots. One of our testflight yesterday and I got a screenshot from a DJI as comparison. For my understanding, it never comes to an overshoot but at the end of the guided command, the DJI is much more behind (more smooth) but more stable in holding the velocity.

@Amilcar: Could you please explain it more detailed about "take that acceleration into account"?

We are flying arducopter for several years, and we never had a crash/big error during flight. But we was never so in detail to find best response/tuning. But, for my opinion now, it is necessary! Hopefully we can get this rocking and I can write a tutorial/wiki for other peoples in the future.

Again, thanks all for your help!


(Amilcar Lucas) #10

What I meant was, you can take a look at:

And implement a new controller that does take acceleration into account.


(Guglie) #11

I was testing this patch https://github.com/xvzf/ardupilot/tree/Copter-3.5.3-velcontrol in SITL

But I get same results requesting 5 m/s, 10 m/s and then 5m/s

As @amilcarlucas suggested I think we can handle acceleration to not over-(or under-)shoot


(CN) #12

Hmm, @guglie, any idea how to handle it exactly?


(Matthias Riegler) #13

Hmmm, I thought the issue is due to the position correction... I will take a look again, maybe the triggering isn't working.


(Matthias Riegler) #14

Okay, a second test is up and compiles!
I swapped the posvel controller for the velocity controller in control_guided - That's why part of my code was not even executed.

Are you reading out the log after the simulation? Or is there any utility I am not aware of that shows graphs like this in realtime?

Cheers,
Matthias


(Guglie) #15

Thank you, I'll give it a try.

For my graph I used a GCS, APM planner.


(CN) #16

Hi all, is the modified, updated version working better?


(Matthias Riegler) #17

Results look pretty promising:

However, there is NO position control, no wind correction, nothing. That needs definitely some improvement!

Cheers,
Matthias


(CN) #18

Hi, I tested the firmware on a real copter this morning, attached two screenshots. There are no more overshots but it's not holding the speed exactly. Any ideas for tuning this last thing?


(Khancyr) #19


No other modification than changing horizontal pid value


(CN) #20

We tried this before uploading the firmware and it was not working with the real copter. Which parameters did you changed exactly? We tried, Loiter P and I at minimal values and also with "0", it was not a different in Overshot but you could see with your eyes that it could not really correct the position before sending velocity.