I recently flashed 3.6.6 and originally had problems connecting to GPS1. I fixed that with a reflash.
I now have more “advanced” problems. I am using FrSky Taranis X7 and have yaapu telemetry running with voice feedback.
I take off in Loiter (more stable than Stabilise and throttle behaviour is well suited for takeoff among trees). Once the drone is stable some 20-30m above I attempt to enter Auto mode but the Pixhawk emits 7 beeps (recorded on camera) and enters RTL mode instead. RTL mode proceeds to fail by overshooting the “home” location while simultaneously locking controls so I have to disable it to regain control and avoid an encounter with a large cypress tree. (attached log shows a very short RTL mode as this is not the first time this happened)
Flight plan (waypoints) are loaded and this flight plan worked on the previous version of Ardupilot (3.5.7 I think).
Once airborne I get regular “GPS Glitch” messages on my yaapu/X7, followed by “GPS glitch cleared”. This is also new behaviour. I am using two GPS receivers which are set up for blending
The log shows terrain failsafe errors. But, I have a ceiling of 50m AGL and the terrain I am flying over is hilly so I need to have a way to follow terrain. I set the altitude for each waypoint to at least 20m AGL (the last one as it comes back towards origin where I land it manually). I understand that follow terrain will use Google Earth data which will get uploaded to Pixhawk, I also read that for the follow terrain to work I need to have a long range rangefinder. My tfmini is not a long range rangefinder. How can I verify that the terrain data was in fact uploaded to Pixhawk?
It might be interesting to go back to 3.5.7 (it’s available through the MP’s Previous Firmware’s link). If it does work then that might mean we have a regression but I suspect it won’t work on 3.5.7 either.
The key difference is the addition of the short-ish range Benewake lidar which I don’t think Copter-3.5.7 supported. If a lidar is present then by default it will try to use it for missions. We don’t yet support mixing a range finder and the google earth data (or more accurately SRTM data).
There is a parameter called WPNAV_RFND_USE which, if set to 0, will mean the range finder isn’t used for terrain following in missions. Maybe try setting this and see if it works.
I am a bad tester… the FW I was using before I started having problems is 3.6.5. However I cannot figure out how to go back to it so I flashed 3.6.6 again and will try to see if I can make it work.
I will set WPNAV_RFND_USE to 0 and see if that fixes the Auto problem.
I do not know what is going on with the GPS, but maybe a reflash will have fixed that. It does not appear normal that both GPS receives would suffer a glitch, offset by a few seconds, then recover, and repeat the whole thing every 10s or so.
EDIT: I found this setting that may correspond to the GPS glitch happening every 10 seconds
Vibration levels are a little high on the vehicle and this may actually be the root cause of the GPS glitches. A “Glitch” comes when the EKF doesn’t think the GPS data agrees with the IMUs.
The vibration levels are highly correlated to the throttle level. The graph below shows throttle (in blue) and we can see the EKF’s altitude estimate (in red) separates from the barometer altitude (in gree) when the throttle goes high. It recovers later but this is a dangerous situation actually. It would be best to improve the vibration isolation or use a flight controller with built in vibration isolation (like the Cube or CUAVv5)
Sorry for the delay. I was being more conscientious and followed a more serious testing protocol rather than taking the drone up and seeing what falls off (figuratively speaking).
I placed the Pixhawk on a vibration isolation platform. This improved the vibration issues and I had no more GPS glitch issues.
I downloaded QGroundcontrol which immediately told me that follow terrain requires terrain frames to be uploaded to the controller, and they will not be uploaded because a) they are not available and b) the flight controller does not support them. I then changed the altitude limit mode to anything else that does not require uploading of frames. I managed to have an auto flight after doing this.
I now have another problem, and a crash, so I will make another post if I cannot figure out what to do.
