Precision landing and auto tune

#1

So… I am having issues with auto tune, but i decided to chug along and start testing scripts because I am getting decent flight in stab, althold, and loiter mode. I have enabled one harmonic notch filter, but I havent really investigated it too much, just whatever was on the ardupilot doc… I only spent one day on this and I also auto trimmed and manually tuned the roll PIDs.

I started off with the takeoff_and_land script and it went awesome imo, then proceeded to play with different heights and was successful. I tried RTL mode and was approx within +/-2 feet so I assumed that GPS was good (I am looking to upgrade GPS module if anyone has suggestions). Then, I started testing the set_velocity_body script and got some unusual behavior. The first test was to go forward for a bit and then enable RTL, which was a success. But then, I tried the East and West directions and the drone started yawing for some reason. Is this because the autotune? Has anyone experienced this?

#2

If you upload the .bin file we can have a better way to analyze this.
You might consider asking over at the Ardupilot discussion forums, but they would ask for that as well.

#3

Oh cool. I will try over there at ardupilot as well, but I would greatly appreciate it if you would take a look also. I uploaded my most recent logs to google drive here

My most recent flight was May 29 2023, but I have also included other flight days just in case.

#4

Could you share the set_velocity_body script?

#5

Yes! Here it is…

send_velocity.py (4.4 KB)

#6

I also did a test hover yesterday and I was wondering if you could help me interpret the flash logs. What parameters are best for tuning? I assume that the best guidance for tuning is the data log, but I am not sure where to start.

#7

Is this the correct file? Above you name it ‘set_velocity_body’.

#8

Yup, its the same one. I just named it different from the programming primer course (and minor style changes), but it uses the same function, the send_local_ned_velocity function with the msg = vehicle.message_factory.set_position_target_local_ned_encode with the same while loops to keep sending that velocity message.

When I tested the script and gave the function (0, -1, 0) parameters to move west, relative to the drone, at one meter per second, it instead yawed.

#9

That’s because the code is having it turn quickly left

while (i<4)
image
so it looks like it is yawing. Modify it a bit and it will change, although in this example a bit wonky.
image
image

If you are trying to change direction 90 degrees, then left turn just once, then continue forward.

#10

Hey @jax200! Thanks for taking a look! So its my code thats off? Well thats better than having hardware issues imo. I ran this script in the field when I should’ve ran it in the sim first.

I want it to maintain its heading while it executes four movement commands. So, pitch forward, pitch back, roll left then roll right, without any yaw. Is that possible with the local ned velocity commands or will the drone always yaw with those messages?

#11

Those commands work in the x, y, z planes (NED=North East Down).
Check around, maybe ATTITUDE at https://mavlink.io/en/messages/common.html.

#12

Hey @jax200, I am having trouble reproducing those screenshot movements in sitl. When I run the script in a sitl instance it doesnt behave like it does in your screenshots. The drone does not change its heading when I run it in sitl.

However, when I run the script in the field, it does. In the field, it does those cw and ccw donuts in your screenshots. Is there some thing I am missing? I think there is some discrepancies between my drone and sitl parameters, but I am not sure which ones I should look at.

I just tested the code and I added that extra line that you added in the screenshot (that extra call to the send_local_ned_velocity function) and the sitl drone moves in a diagonal, never changes heading.

I must have some kind of mode parameter incorrectly or something.

I am trying to achieve the same motion that is in the How to build a Raspberry Pi drone: velocity commands. There, Caleb makes his drone go right and left without yaw i.e. no change in heading.

#13

I’m unsure. What happens when you run the programs from the course? My SITL setup is configured with all current dependencies and python 3 as I have described elsewhere.

#14

When I run the course programs, they act natural i.e. the drone does the NSEW cross maneuver. Can you try running this script. It’s the one I used out in the field and tested in SITL. In sitl, the script behaves just like the course scripts, but in the field it did a cw circle followed by a ccw circle.

I dont think that any of these commands should make it yaw in this fashion, correct?

UPDATE:

After looking around a bit, I think the type_mask is incorrect in my script and I need to specify a yaw_rate = 0. It is related to this GitHub issue where people get the same behavior that I have been describing i.e. the yaw when trying to roll side to side.

I cant tell the difference in SITL though. When I zoom in on the SITL quad, I see two, a red quad and a blue one… do you get those also? In any case, I will test the new function, with the updated bit, out in the field and report back.

Also, I was looking at the commands.

And I see that MAV_FRAME_BODY_OFFSET_NED is deprecated. Do you still use it, or do you use MAV_FRAME_BODY_FRD?

#15

I am traveling and won’t be able to check until next week.

#16

np… figured it out. Thanks for all your help and safe travels! (man do I wish I was also traveling :joy::rofl:)

#17

What was your solution?

#18

It was the yaw bit mask. I guess some bug makes it so that you have to include a yaw bit, which I was not including. Weird thing is, that SITL did not catch it… I was getting fine behavior in SITL but in the real world no.