Follow Up Question: What is GPS Assist for. I thought I had to pick this option in order to invoke GPS/INS13 navigation).
To add to non-GPS modes so that when you release the sticks it goes into GPS position hold.
Follow Up Question: Does "PATH" need to be green for Pathplanner to work properly? What conditions would make it go green?
I don't pay much attention to it, but I think it may be black until you switch to a GPS mode?
PLAN may be black until you switch to PathPlanner mode, then orange until you upload a correct plan or it may be orange if there is a PathPlanner mode anywhere on the FMS.
I would have to test it...
Follow Up Question: Is there a new env't variable for GoogleMaps. Is there a way I could find it myself for the future?.
This is the current number.
GCS_GOOGLE_SAT_VERSION=726
I clear the Home Location everytime to get the current location as Home Location.
Not necessary or desirable, but not a real problem either.
HomeLocation is not something the user should have to worry about as long as it is close enough that the curvature of the earth isn't much. If it is a long way away, your OpMap (Google map) will be off some meters and flight plans will be off, but everything else (e.g. VelocityRoam) will continue to work. If I forget to change my HomeLocation when flying at home (flying field is 50km=30miles away) my OpMap coordinates that are displayed are a couple hundred meters off, but VR works fine. OTOH I would not even try VelocityRoam if my HomeLocation were on the other side of the earth so that up there is left here. Well I might try it to see what it does.
There is a UAVO called TakeOffLocation which by default gets set each time you arm. That is where RTB returns to.
If you fly in the same location with the
exact same waypoints (plan stored on disk), you probably want to leave the HomeLocation set to the exact same place.
The default is that the waypoints are relative to HomeLocation, so moving HL a meter or two will move the flightplan too (I think).
Thanks so much for the parameter changing bug. I finally managed to change the speed to 3 m/s and height to 4 m. However, this did not seem to affect the speed or relative altitude. The quad rose to at least 20 ft and the speed was significantly faster than 3 m/s. So the quad completed may 2 waypoints, but kept me on the edge as it do so much faster and at higher altitude than expected.
Follow Up question: Why would the speed and altitude not change even though they are reflected in the parameters of the waypoints?
GPS altitude has a lot more error than horizontal. The difference between 4m and 20 feet is to be expected. That is why I recommend 4m, so that it doesn't touch the ground! I don't know about the speed. You could record a log and play it back and examine the speed to see if it at least thought it was going 3m/s (about 10 feet per second). That should be about a human medium running speed.
To make sure this isn't a baro issue, test fly a couple flights with a non-gps mode (e.g. Stab1=Attitude) that has thrust mode set to AltitudeVario or AltitudeHold. AV has a deadband in the middle of the throttle stick, so if it is close to center stick it should not change altitude at all. If you see it drifting up or down in the first several minutes of a flight you need to do thermal calibration. Also test in hover vs. forward/left/right/backwards flight at the fastest you expect to fly it.
Maybe? Leaving the model powered off while you click up the waypoints and edit speed and altitude will stop the refreshing. Then power up the model and send the waypoints to it.