MISSION flight tests experiences

[afernan]

I propose this topic to log flight missions experiences, tips, recomendations, etc to easy code improvement and complement the WIKI infos obout this matter.

[afernan]

I´ll start with a summary of my missions tests.
H/W: Quadcopter 800gr (w/o batt), AQ6.6r19, GCS 1.5.8 over Nexus 7

Summary: all worked fine, with following comments:
- Once created the mission and saved to AQ (acknowledge received in the screen), the first time that I play It goes to first WP and remains there a loooong time loitering (> 1 min). At the begining I thought It stoped after first WP, but wayting enough it continues the mission.
- Repeating the mission a second+ times, it works fine (no long wayting time after WP1).
- After touching a WP, there is a wayting of about 3sec. This parameter can´t be changed in the Android QGC (but it can be in Windows QGC). Sugestion to add in Android QGC
- Circle works fine. But if you put it in the middle of a mission, it loops infinite. A parameter limiting number of turns or time, is suitable >>Sugestion to change in Android QGC
- "Take off" works fine. Works fine inside a mission.
- You can stop the mission in any moment (for instance, switching to alt-holt). Switching again to Mission It will continue at the point you´ve leaved.
- Heigth is relative to the point mission is activated, if "absolute" tick is off. That is, if you put "0" in all WP, you will flight the mission at the same heigth the mission was activated.
- Landing is very good: precise and slow enough. Works fine inside a mission.
- Yaw during the mission is fixed to the selected value. It should be nice flight with yaw facing every next point instead. How can we program that?

Finally, I suspect that the problem with the Windows QGC could be linked with the big delays explained here before with ANDROID, that looks to stop after first WP. Il´l try it again and report.

UPDATE. VIM had same experience and recomends that after saving the code to AQ you need to wait 30-40 sec to avoid this delay after WP1. This is coherent with what happents to me. For instance, the delay after some "Take off" (is the first point in the mission) can be explained with this.

Angel

[kinderkram]

Thx for your summary, Angel.

The delay of certain waypoints needs to be investigated. For now we can use VIM's and your workaround - waiting long enough...

[GoFaster]

I've had what appeared to be a long delay after I thought the first waypoint was reached.
In my case, it seems to be a loss of altitude along the way from the start position to WP1 (all WP's in mission at 0 relative altitude) After it reaches the horizontal position, it very slowly creeps up to the target altitude, waits for any loiter time to expire, then continues onto WP2.
Don't know why it doesn't maintain altitude along the way and why it takes so long to rise to the correct altitude. I have foam over both baros.

- Felix

[joebar.rc]

[afernan]

More testing results.

Delay after WP1.
I´ve been trying several things like VIM recom (wayting 1min after saving) and this does nothing for me. I have delay only at first mission try. Second repetition and on are ok always. So, there is something to correct in the code.

QGC over WINDOWS
Then, I wanted to know if this could explain the problem in WINDOWS described for many folks about mission stop after first WP. This still remains. So after first WP, remians loitering infinite

Then I´ve created a mission on PC, saved to AQ, then retrieved in Android QGC to see what windows writes as mission.

What I found is the following (see images 1-4 attached). Every WP had

WP0.png (28.49 KiB) Viewed 16391 times

WP2.png (27.84 KiB) Viewed 16391 times

So, I run this mission retrieved and saved again in the Nexus7 and obviously behaves the same than with WINDOWS (after first WP, stops). This is obvious since the Ho. Speed = 0 (no speed to fly to following point).
Then i changed in the Nexus7 to reasonable values:
Hit Rad. = 4
Loiter = 2
Hovering Speed = 5
and then the mission works nice.

Then i´ve retrived this succesfull same mission in windows and found the following (see image 3): Hit Rad = 99.99 (a big number), and Loiter = 4 sec (looks to take the wrong number place).

In summary:
WINDOWS QGC:
- QGN needs to write a correct Ho. Speed different from 0. And add it as a selectable parameter
- To be corrected the loiter time (looks a x1000 factor) and Hit Radius

ANDROID QGC
- Delay after WP1 (1 -2 min) happens only first time os mission run. Second+ are OK
- Always use Hit Radius >1m
- Use a Hovering Speed > 1 (typical 3-5 m/s)

I can supply flight logs, if the are usefull to analize this problems.

Hope this help and sorry for the length.

Angel

[chschmid]

[epyonxero]

I just did my first mission mode flight today.

Started with one circle waypoint followed by a regular waypoint. Took off in manual then switched to POS hold. Once POS was stable I activated the mission. The copter flew to the circle point then began to circle indefinitely, I had to take many control back to stop the circling. Circle looked good otherwise.

Second try I made a Take Off waypoint with default settings when my copter was sitting then two other normal waypoints. I switched to Mission mode on the ground then set throttle at 50%. Motors spooled up and the copter then flipped itself on the ground. Do you need a normal waypoint on top of the Take Off waypoint? Im not sure what I did wrong.

Third try I made a mission with two regular waypoints with the same default altitudes at 4.5 and a third waypoint with the same altitude but a Auto Land command at the same location. Took off manually and switched to Mission mode. The copter appeared to navigate well except for the fact that it would climb in altitude between waypoint 1 - 2 and 2 - 3. At the landing waypoint it made a perfect landing just from higher up than planned. I have foam covering the baro.

[Shogun]

Can anyone explain how absolute and relative altitude are supposed to work, please?

[afernan]

Absolute and relative heigth explanation
(based on many flight tests I´ve done)

Absolute heigth is really absolute w.r.t. sea level. In my case (Madrid, Spain) I have 630m in the place I flight. So every WP with "abs" marked will fly to the value especified. This works very well.

Relative Heigth. This is relative to last WP. This is very usefull.
Let see a tipical example: Lift-off to 20m, several WP´s at 20m, landing.
We need to put following relative altitudes:
1.- Take-off "T.Alt" = 20 (see image attached)
2.- all WP´s altitude = 0 m (abs box NOT marked)
3.- Landing 0 m
This works perfect.

Other example: we want to flight several WP´s always at the same altitude. So, we need to put ALL WP´s alt = 0m (rel alt). So the flight altitude will be the one when launched the mission, wathever it is.

Another example. We want to fly 4WP´s increasing the heigth of each one in two meters. So we put every rel. alt. for each WP = 2m (it works the same with negative values).

All of this works perfectly, and IMHO is a very convenient way of program missions.