Thanks for the report. I’ll have a peek.
I’ve tested Drift in the simulator and it seems to be performing the same in Copter-4.1 vs 4.0 as far as I can tell. The test was:
- arm and takeoff in Drift mode
- pushed pitch stick forward (vehicle flew forward)
- pushed roll to the left (vehicle roll to the left and also yawed in counter-clockwise direction)
- pushed roll to the right (vehicle rolled to the right and also yaw in clockwise direction)
- pushed yaw to the left (vehicle rolled left to -9 deg)
- pushed yaw to the right (vehicle rolled right to +9 deg)
- repeated the above tests with pitch stick pulled backwards
Maybe you’ve got a log from the flight?
Perhaps also check that simple mode and/or super simple mode aren’t enabled.
It was over 2 years since I last flew in DRIFT mode.My Kakute f7 boards did not allow it. When I switched from althold to drift the controls were checked and when yaw banked left and right I went back to stabalize then landed.In my mind,yaw did nothing on the left stick,as I remembered drift.Now I feel bad for wasting your time.Flew just fine today.
1 Like
I have been flying 4.1.0-rc1 on my large X8, and am seeing some issues with yaw when flying in guided mode. These issues didn’t happen on 4.0.7.
I press the takeoff button in QGC to arm the aircraft and takeoff to 10m in guided mode.
Once the aircraft gets to 10m, when the In flight Yaw alignment is done, the aircraft will make a big yaw movement, usually around 90 degrees but not exactly. It does not do this on every takeoff.
We then command the aircraft to increase in altitude using QGC, at which point the aircraft makes another large yaw movement, sometimes up to 180 degrees.
We did not see these yaw movements when following the same procedure with 4.0.7.
Attached is a log showing two flights, the first flight no problem occured, the second flight the problem occured as shown above.
Any ideas on why this might be?
No problem at all. I’m happy that you gave drift a try because it is difficult sometimes to find beta testers of the less popular features/modes.
Thanks for the report. I suspect we have a little issue when Guided mode changes from the “takeoff” submode to its new default velocity+accel submode. It is perhaps more detail than you want but for the record this is where in the code the transition happens. If we look at the logs (screen shot below) we can see the “EV: LANDING_GEAR_RETRACTED” event happens just as the target position jumps and the yaw starts moving.
I suspect this is not difficult to fix but I’ll need to discuss with @Leonardthall
2 Likes
I also have not used DRIFT for quite a wile. ASAP I will try with Copter 4.1.0 and send you a log file.
1 Like
Thanks @rmackay9,
We are flying this aircraft a lot right now so can test any changes or provide any more logs needed.
Sidenote, the aircraft in question was unable to do auto takeoffs from disarmed like this on 4.0.7 because of delayed spool up of the motors causing the throttle to reach 100% and the craft to launch into the air.
The changes introduced on 4.1 have totally fixed that and auto takeoffs are beautiful now so thank you for that!
Also, this might not be the place for this, but in LAND or RTL, at 10m, the copter goes from decending at WPNAV_SPEED_DN to LAND_SPEED. Is the height at which this speed change happens configurable? Our aircraft can fly for a very long time and the barometer drift over that period may result in it hitting the ground at WPNAV_SPEED_DN if it drifts too much.
1 Like
Thanks for the feedback and great to hear that the takeoffs are working well.
LAND_ALT_LOW is the parameter you’re looking for I think. I"ll try and add this to the wiki as well.
Ahh perfect thanks, that’s what I needed!
I was playing around with a custom build of qgroundcontrol in SITL, and I found a mavlink command which reliably causes SITL to crash.
I’m not sure if this is even a problem or if this is just a silly mavlink command to be sending 
But I thought I would mention it, steps to reproduce:
sim_vehicle.py -D -G
module load message
message COMMAND_INT 1 1 0 195 0 0 float(“nan”) float(“nan”) float(“nan”) float(“nan”) 0 0 float(“nan”)
GDB output shows PANIC Internal Error (1024)
This happens on Master and on Copter-4.1 branch of ardupilot.
Hi James,
In general I think I would prefer if AP rejected this messages and we have a PR that does this. It’s gotten stuck though because we don’t want to reject messages with NaNs in field we don’t use.
I’ve created a PR which I think will resolve the issue with the vehicle yawing after it completes the takeoff in Guided mode.. Another user on the “Vision Projects” channel also complained about this behaviour.
I’ve also added an issue with a little more detail about the cause of the problem. You would probably also find the problem went away if you increased WPNAV_SPEED from 300 to 1000 (or even a little lower) but this would just be a workaround and wouldn’t resolve the issue in all cases.
Hi @rmackay9,
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.
Ok txs for the feedback.
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.
1 Like
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.
Thanks again
1 Like
Hi @rmackay9, Me again 
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.
1 Like
Hi @james33,
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).
@rmackay9
Will give rc1 a try tomorrow.
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.