Position drift and wrong takeoff altitude

#1

Hello, I’ve got a setup of a drone with Marvelmind Indoor GPS.

The drone has 3D lock of GPS, and when I perform a takeoff of about 0.1 meters it goes to about almost 1 meter of altitude and I got a little of position drift, it doesn’t get lock in the take-off position.

There’s the log file: https://logs.px4.io/plot_app?log=580109c8-3a7f-4b53-8b65-44bdac8ac5ea
In the begining I was testing the kill switch and in the final, I used the kill switch because it was getting closer to a wall.

Should I tune the PID? Am Idoing something wrong?

Thanks in advance, Vinha

#2

What have you with this parameter?
https://dev.px4.io/en/advanced/parameter_reference.html#MIS_TAKEOFF_ALT

There might be some minimum defined in code as well, something worth debugging.

#3

It is set to 0.0 meters
I’ve already tried with 0.1 meters too and i got the same

#4

I’ve already fixed the altitude.
I’ve updated the rate of the roll and the pitch and it seems to don’t drift while taking off. But when it is in loiter mode the drone starts to have a positive roll and pitch effect . Updating the rollrate and pitchrate gains the drone just move foward now.
There’s the first log without updating pitch: https://review.px4.io/plot_app?log=d04c27fd-4ce1-4327-b28d-aa9e2ca98d6f
And now with the roll and pitch rates updated: https://review.px4.io/plot_app?log=f4e7d461-c34a-4550-9f6b-6ad24ed7f1d9

Should I change the MPC variables too?
Thanks in advance!

#5

I’ve already fixed the altitude.

How did you do this?

#6

I fixed by putting lower altitude for take-off

#7

Ok, so it was the MIS_TAKEOFF_ALT parameter?

#8

Yes @JulianOes
But I still couldn’t fix the position. It doesn’t stay in the same position in loiter

#9

I’m suspecting that the heading is off. Have you verified that it is correct before flight and during flight?

#10

What do you mean by “heading”?

UPDATE: I’ve been trying to takeoff the drone by creating a mission of a waypoint above the drone (0.1m) and landing on the same place and everything goes well. It takes off and lands (just the position not fix). I changed to 0.2m and again everything smooth . Then I changed to 0.3m and the drone slowly flew to the ceiling. (I cutted of when it reached the ceiling and it crashed to the ground) :confused:
Here’s the log file: https://review.px4.io/plot_app?log=a0bfaa7f-1755-4ec5-a65b-7b055f012567

Should I change the estimator to LPE, or keep it in EKF2?

#11

So with heading I mean the yaw orientation, so e.g. if it is facing North when it says it is.

Also, you might want to set up RC in a way that you can switch to altitude control or stabilized when something goes wrong. That way you can take over manually and don’t need to kill/crash it every time.

I don’t think changing from EKF2 to LPE will magically fix your problems. I think you need to make sure the position information that the estimator is given is correct and that it can output the correct estimate.

#12

Yes, it’s facing north when i’m pointing north.
You’re right, I should have that :slight_smile:

The position that arrives to the GPS port of the drone is rigth (NMEA), the relative altitude also changes right (if I put the drone +/- 10cm above the current position, the values vary between 0.0 and 0.3m in the flight HUD and then stabilize in 0.1 m.
One thing I noticed is that when I move the drone down, the distance goes to -0.5 and then stabilizes in 0.0m. I can garantee that the altitude in the MARVELMIND never goes down from 0.0 meters.
It seems that px4 is giving some compensation to GPS values, but the values I give from marvelmind system are accurate, so px4 don’t needs to compensate that.

Am I supposing something wrong?

#13

The estimation fuses GPS, baro and accel data for the altitude. In order to put more weight on the GPS data, you can try to reduce the noise setting for the GPS position:
https://dev.px4.io/en/advanced/parameter_reference.html#EKF2_GPS_P_NOISE

#14

I’ve put it to the minimum possible, but it still does not stay in position.
As I’m flying indoors, the baro measurements are not accurate. Should I increase baro noise?
And should I also change some gains of MPC_XY_* and MPC_Z_* ?

Thanks for the help!

#15

Sounds reasonable. First you need to make sure with tests that the position estimation is correct. Starting to tune the position control without knowing the estimation is correct won’t help

#16

I think that only the Z position coordinate of the estimation isn’t correct. I can see the drone correcting the position (x,y) but the altitude no. It takes off, loiters for around 3,4 seconds and then starts to descend. Sometimes a GPS failsafe is enabled and it starts to slowly descend while the led starts to flash purple.
Here some videos about it: https://drive.google.com/open?id=1Q4_zQyDJGAFlCMf8JGzySFh-isQh5Kr1
I’ve tried to change the gate of the GPS and it got better, but it activates this failsafe.

#17

Does it actually lose the GPS or can you debug what happens in that moment?

#18

For what I can see, Marvelmind is always giving a position, even if it is a little bit wrong. The altitude is always oscilating +/-4cm and the position just oscilates +/-2cm. Marvelmind sends the messages accordly to the NMEA frequency and so on, so I think it might be a problem of the EKF2.

#19

And are you sure the NMEA parsing is working correctly because NMEA is in fact not supported. You might just get lucky that ashtech is similar and it therefore gets parsed.

#20

I used the SDK in python to check the coordinates and made a simples script that convert the first telemtry data to the point (x,y,z)=(0,0,z) and then calculate the distances between that first coordinate to the next telemetry data and the distances when I move the drone around are correct, even with a little bit of overshoot, they tend to stabilize in the correct point with the error I said before. So the data from marvelmind is arriving to px4 in a correct way I think.