Thanks for this, and thanks for the tip about increasing WPNAV_SPEED this might help us in the short term testing of this aircraft until PR is in.
Reading through the issue and pull request, reminds that we also saw these big yaw movements occur a few times when the GPS Primary switched. We resolved the issue in the field by changing GPS_AUTOSWITCH from 1 to 4 to avoid switching. I presume this would be the same thing, position error causes target velocity to go above 5% of WPNAV_SPEED, which causes the aircraft to yaw to face direction of travel?
Would this be addressed by the PR also or is this perhaps even desired behaviour?
Can dig up a log to show this if needed.
Sorry for all the questions, appreciate you taking the time to explain things!
Regards,
James
Edit: I found the log, looks like it is the same thing happening on the GPS Primary Change events:
I should note that at the time of these flights our aircraft was having magnetic intereference problems with the compass but I dont think that is influencing what is happening here.
One of the changes in 4.1’s guided mode is that by default the vehicle will point in the direction it is moving. In 4.0 the yaw was always fixed unless the caller specifically took control.
@Leonardthall believes the new method is better because it allows external callers to more easily achieve coordinated turns. E.g. by default the vehicle will turn in the direction of the specified position, velocity and/or acceleration. In Copter-4.0 the caller would need to specify the pos, vel, accel and the yaw.
By the way, if you don’t want the yaw moving around on its own, it might be best to take direct control of it by providing a yaw and/or yaw_rate target. You probably already know but there are yaw andr yaw_rate fields and bits in the type_mask field.
Makes sense, thanks.
I certainly agree with wanting nice coordinated turns without needing to control yaw from the GCS.
Although it would be nice if the AP could distinguish between movements to acheive a new setpoint from the user, vs movements to maintain a constant setpoint.
And of course you are right that the best way is to control yaw directly - I need to work on adding that to QGC if I can.
We have been continuing our testing of guided mode in 4.1, and had something a little scary happen. Twice in a row we had the aircraft start to fly away after the takeoff completed in guided mode.
The procedure was the same as before: Press takeoff button in QGC and slide to takeoff to 10m.
When the aircraft reached altitude, it yawed around, and started traveling in the direction it was facing.
My first thought was the GCS sending it a command to go somewhere, but I looked through the tlogs in wireshark to see if the problem was on the gcs side sending a bad command, and I see only 3 messages sent from the GCS which all looks ok.
SET_MODE
COMMAND_LONG (MAV_CMD_COMPONENT_ARM_DISARM)
COMMAND_LONG (MAV_CMD_NAV_TAKEOFF) (Lat lon fields are 0, alt field is 10m)
In the logs, I see that when the takeoff completes, the TPx and TPy start moving as the vehicle accelerates.
In the two times we did this, the aircraft went in two different directions.
In these flights we were able to switch into loiter and the aircraft flew normally.
Previous to these two flights we did a successful flight at the same location where this behaviour did not happen. The only change we made from that successful flight to these two unsuccessful flights was to recalibrate the compass.
Where in the logs would I see the position target that guided mode is working to achieve? I see the TPx and TPy moving but I want to know what position it is heading for and where it gets this from.
Hoping I have just done something stupid here. Logs and tlogs for 2 flights at the link below, the first one (2021-09-21 12-04-45) is the best to look at as we let it go further before taking control.
Sorry for the scary event. I’ve had a look at the log and gone through guided mode but I don’t immediately see where the issue could be so I’ll investigate with @Leonardthall.
When a new target is received you should see a “GUID” message in the logs (but there aren’t any in either log).
Looks like the “PreArm: EKF attitude is bad” issue, that I described here and here is still open. This means, a copter configured for GPS-for-Yaw still can not be armed (e.g. for motor test) inside a building without GPS as compass is only a fallback after GPS-for-yaw has initialized yaw at least once.
Yes, the issue of not being able to initialise the yaw from GPS-for-yaw is still on the issues list and is unlikely to be resolved before 4.1.0 is released. I’ve added it to the GPS-for-yaw improvements issue but I suspect this is one that @tridge will need to help us with.
@Leonardthall
I guess, you mean a test for the “PreArm: EKF attitude is bad” issue when trying to arm without having a GPS for Yaw initialization before?
I mention this, because I also had these “Error pos vert variance” messages when the EKF3 position estimate was going mad which caused a crash with beta5 (you still have that in your issue list).
May be, this has something to do with the communication going on when using GPS for Yaw with two ublox F9P relaying RTCM messages through the Pixhawk.
Sure - BUT when I also see these messages on the ground or even in-flight when there was no download active, it may be an indicator that the CPU is heavily pegged, right?
You haven’t had a chance to test the binary from @Leonardthall have you? Sorry to be pushy but “scary guided” (as we are calling it) is the final blocker for the 4.1.0 release so I’m quite keen that we get to the bottom of it.
By the way, we’ve modified Guided mode’s behaviour after takeoff has completed and I suspect this will mean that the issue cannot be reproduced using 4.1.0-rc3 but I would like to be sure. Because it is difficult to prove something doesn’t happen ideally we’d like you to try and reproduce the issue with the binary that Leonard has provided.
If you can easily reproduce it with Leonard’s binary but cannot reproduce it with -rc3 that would also be good to know but I understand this would be a bit more testing than you may have time to do.
My apologies, I have not had a chance to test it yet, we had to roll back to 4.0.7 to work towards a deadline for a demo.
I will endeavor to test as soon as we can, but the weather here is forecast for rain for the next 5 days at least, so it will probably be about a week till we could test this.
I also have no idea if I will be able to reproduce the issue, as we had many successful flights on 4.1.0 without this issue until one day we had it happen twice in a row. I will be loading the same parameters and flying in the same location to give best chance of reproducing.
If I manage to reproduce the issue I will flash with rc3 and try that.
Found a break in the weather and did this test just now.
With the firmware Leonard provided, managed to reproduce this issue on 3/3 takeoffs.
Then we flashed rc3 and did 4 takeoffs without the error occuring.
Hope the logs are useful, looks like the problem is fixed.
Two logs from the PSC firmware showing the issue, and two logs from rc3 with normal takeoffs.
