Maybe you mean the second circuit of flight in the same mission? Each .bin is one continuous AUTO flight. So there you would be right: first circuit around the field good, second circuit slow. Below is the first flight, and the only difference is I flipped RTL really shortly after I noticed the slow behavior, so the 2 m/s plateau on the chart is shorter here, and more prolonged in the second mission, since I let the slowness ride until it hit the next waypoint…and stayed slow.
I would love a .bin analysis video or how to!!! The wiki does not explain much on it at all.
So I clearly see in the data table that WP_NAV_SPEED is set to 800 cm/s.
What I’m struggling to find is where in the data table would be a command to change this. I suspect the problem area is around where the AUTO landing occurred. I see some mission commands for the payload drop (DO_DIGICAM_CONTROL) and then takeoff. Then there is a CMD which I presume means it’s command #10 of 18 total commands, type 22 for takeoff, to 75m altitude.
Could I trouble you to sniff around data table line 75747 of the .bin attached (screenshot of that one below) and see if there’s something in here that would change WP_NAV_SPEED? Or, is there a way to filter the data table to return only certain types, so not to have to scroll through 1000’s of lines?
Because you don’t know, it does not mean that is does not exists 
1 Like
I know it is not video but there is a lot to learn on these pages:
https://ardupilot.org/copter/docs/common-downloading-and-analyzing-data-logs-in-mission-planner.html
https://ardupilot.org/copter/docs/common-diagnosing-problems-using-logs.html
1 Like
Just took a quick look at the logs, did anybody notice the continuous change in compass by EKF?
Back to the original issue. A quick question @blueskies how you managed to not disarm but continue with takeoff after land for package drop ? As far as I know this option is just merged to latest dev, and with 4.0.3 it was only possible with commands from GCS or onboard computer… and why the a parameter4 of LAND command set to 1 in your missions? (Not the waypoint file you sent, but in the missions that can be extracted from logs…)
Did you check the mission files ? Please… he did not use payload_place command.
I don’t know, but it works (well, works in theory). I was actually shocked that it would when I tried it with AC 3.2.1 some time ago. I thought for sure a LAND command would terminate the mission. But I went on to do many missions using this. LAND, DO_DIGICAM_CONTROL, TAKEOFF. It would land, drop the payload (actuate servo), and take right off like clockwork. Maybe that was superseded in some subsequent AC version. If it’s coming back improved, well that’s cool by me.
As far as the LAND command set to 1, I noticed that too, and I don’t know where that came from. I didn’t deliberately enter any values here. Do you think it means something?
PAYLOAD_PLACE, correct I did not use that, but have considered it. However I’m trying to accomplish this without slung cargo. But I would use this or another mode to get the job done if I can have any recommendations. Fly to WP, land, drop payload, take off. It’s wicked cool when it used to work for me.
Then finally, the mystery at hand: the speed change after landing. What do you think is going on there?
Hmm, interesting. I just downloaded the waypoint file and ran it in simulation - disarmed upon landing.
Well, what I know is that at the start of the final descent of landing, the loiter controller is initializing to keep the landing point and set the the max xy speed to, guess what, 200cm/s… You not supposed to do takeoff without disarming first, so my guess is that the 2m/s stuck somehow.
Problem is that I cannot repro it with SITL. (have to check 4.0.3 later)
Some more digging in the code I’m more and more convinced that the issue is what I said above. Only a mode change or a nav speed change command touches the max xy speed, which means if you takeoff after land, without disarm (which eventually requires a mode change since auto is not armable) the 2 m/s will stuck.
Update: It seems you can indeed continue in auto mode after land, the forced disarm was introduced in the latest dev. But I still thinks the speed issue is caused by the change in land mode.
OK, @blueskies I have a good news and a bad news.
Good news,I have a solid repro in simulator,
- If you execute a land followed by a takeoff then the WPNAV_SPEED is set to 2m/s for the remainder of the mission.
Bad news, that it seems by design.
- The, non disclosed, side effect of the LAND command, that it sets the WPNAV_SPEED to 2m/s and unless you explicitly change it back to a value you want then it stays there.
Solutions :
- Use a PAYLOAD_PLACE instead of land, according to my tests and the code, it does not change the wpnav_speed
- add a DO_CHANGE_SPEED right after the takeoff command in the mission, that will change back the speed to the desired value.
Since it is a very specific and rare case and does have easy solutions, i don’t think that this behavior needs to be changed. However I’ll add a PR request to update the documentation with this info. (This is only my personal stance, if you want, you can raise an issue and ask devs for a fix.)
You da man, thank you so much Andras! Owe you some beers for that one.
It’s a little weird to have the speed default to 2 m/s after landing, but a developer must have deemed that useful so I’m not one to argue. Do a speed change back up to my desired is an easy workaround. But I figure there’s gotta be someone out there besides me trying to do landing deliveries of payload.
So do you think if I do payload place with no sling if it will sense the touchdown as a “payload mass unloading event” (ie: decreased power output) and trigger release then resume the auto mission or will it just sense a landing and just stay there landed?
And I don’t want to press it, because I’m grateful already, but any sense for why the DO_DIGICAM_CONTROL didn’t actuate? No RCOUT 7 output, except on the one mission where I manually hit it just after takeoff.
There is a very telltale comment in the code about descending state of the payload_place command:
if we discover we've landed then immediately release the load:
So I think it is ok to use payload_place with a non sling package.
Regarding the release, it seems your mission is either corrupted or you used an old version of mission planner… anyway it should look like this
Hi Andras-Perhaps it’s more than just a LAND command at work. I’ve flown a lot of Missions with Land in the middle and not noticed this. The one attached flew at the WPNAV_SPEED setting for both legs.This one was out of my back yard or I would post the flight log. But it’s just a leg to a WP with a return and delay before takeoff again and then another leg to another WP and return.
Apparently this ‘bug’ existed in 4.0.3 (at least I can repro it with 4.0.3 in SITL) But since that release there was a change in the code https://github.com/ArduPilot/ardupilot/commit/7b1e34d219eaa559ef85c015a8f453cfa4f8a07d which inadvertently fixed it. So from 4.0.4rc1 it is working as excepted… case closed
Outstanding, thank you Andras and thank you Dave. I can’t wait to try it out with 4.0.4! I’ll test both PACKAGE_PLACE and DO_DIGICAM CONTROL ways of doing it.
Of note, when I switched the mission from UTM to GEO lat/long, I now see where Andras illustrated a “1” in column 5, there as an actual latitude number. That probably corrupted it. The whole mission table reformats when you toggle between UTM and GEO nav, and I simply didn’t notice the glitch until I switched. I must have recycled a WAYPOINT into DO_DIGICAM_CONTROL, and did not correct the fields.
You guys or anyone reading this who might wish to explore this precision landing of payloads thing, DM me. We gotta keep stickin’ it to the man! (Amazon, Google Wing, etc.)