Im using totally separate datalogger unit which has own power (battery) and its not connected anyway to autopilot or any sensor in Pixhawk Cube. This datalogger includes own microcontroller where is connected own GPS unit, own barometer and own magnetomer. And this system stores its realtime data to own SD card, which is inside this datalogger. We sometimes use this same mag-survey system as a hand-held measurements, so in other word this survey system is totally outside of the autopilot system.
Just as a reference here… this was a 5.5 hour constant-pressure-altitude flight using Baro altitude as the primary altitude source. In this case, the pressure really only began to change during the last hour. Again, not a sensor issue, an environmental one. You can also see the turbulence subsided during the flight.
Trees are not very tall in that area ( in Lapland), like 15 meters. But there was small hill just beside this crash site. We will drive through that area next month so I can take a picture of that.
I will deliver you later more specific info about the area DEM and also our flight plan with the waypoints.
ok, maybe it clipped a tree on the hill?
For GPS accuracy, if you can’t move to RTK then at least using a F9P dual-band GPS should help. In my experience it produces much better altitude than a M8. Also, GPS antenna quality really matters.
You are absolutely right, I fully agree. GPS alt and baro alt can and will vary due to weather condition. That’s why I started to use GPS as a primary alt sensor. But isn’t it a bit odd if two same kind of GPS units in same plane are showing different altitudes and the difference is rising and it can be over 20 meters. Maybe the final solution to “my altitude problem” is that sometimes some GPS receivers can start drifting due to different atmospheric conditions. That’s why I don’t fly with GPS alt any more but using baro and in realtime updating alt_offset parameter to keep my plane alive.
Would you be interested to have a Skype meeting in near future? It could be easier to share screens etc and go through this case. I feel that it’s quite difficult to explain all details here. And if we got any conclusion, we could share the result here.
I think this was a very informative and constructive discussion. I would like to thank everyone for the professional contributions. As for me, we will start using multiband GPS unit as primary altitude source as soon as possible.
If my experience could be of any help, we shoot serials on photovoltaic panels for a living, we shoot from a distance of 5 meters and we have a tolerance of 50cm (25 up and 25 down), due to a rather low F to keep pics very sharp and clear.
We struggled a lot using baro alt as it was not precise even in a 20 min flight, at least not the precision we needed as mentioned before. Than we switched to a F9P with a correction from a local cors wich we get trough an onboard lte router. Since that we have absolutely precise and robust RTK fix troughout the day, basicly it stays in fixed from 8 in the morning to 6 at night, always delivering ultra precise altitude reference.
We are using a drotek unit without antenna and we tested 3-4 different antennas and finally settled to a conic type (can link the exact part number if needed).
In the end, F9P is a bit pricey and a good antenna can cost as much as the unit itself (unit and antenna in the 600 USD range) but it is worth every penny you spend on it. Our job would simply be not possible without it.
We prefer using an LTE router onboard but, obviously, correction can be injected from the GCS.
We use an lte onboard router to have internet available on the drone, we use it for the cors and we have a vpn to do other stuff from ground connected to the drone and sometimes we use lte to pilot the drone whenever the ipmesh gives us environmental probs.
For the antenna i have to look the code number, we got it from digikey, later i will look up the code.
Router is nothing special and it is not wired to the FC, it just let onboard devices have internet access. Raspberry is connected to the router and running mavlink-router distributes mavlink to all the nodes, on the uav and to the ground. When using ipmesh, router and gcs are directly connected, if using wan trough lte than mavlink is routed trough vpn to gcs.
We usually have both links active, ipmesh and vpn, so that mavlink comes trough two different paths and we have never had a gcs failsafe this way.
You are using an LTE dongle connected to the Raspberry pi for internet connection.
what is the function of raspberry pi in your application?
You are using local LTE networks, and establishing VPN connection back to the ground control for telemetry data rather using like RFD900x etc. “or” SIK type radios. correct?
Sorry, never tried this setup before.
I kind of lost you when you said IPMESH and VPN, both are used.
I have actually never tried any of the following options in MP
is there a good documentation out there that I can read.
@Darad Thank you for being constructive and focusing on solution, I see less and less of this kind of attitude around.
Since we have two raw gps data log which did not correlate I think it is OK to say that one of the GPS had external interference or intermittent internal error. Since these are consumer devices it is sadly possible. Based on the data and the fact that the plane crashed I say it was the onboard GPS that failed. The FC had no chance to correct the altitude error since it was set to strictly follow the GPS altitude.
As Tridge said, a M9P dual band GPS will definitely help, or updating QFE. (Once I have time to flight test my plugin, I would recommend to use it with Mission Planner). Also I think a second GPS in blendig mode could also help IF we assume that it was a gps failure and not an external interference.
I noticed from the pics that the Here Gps is a bit “buried” in the fuselage. Maybe it is an optic effect due to the pic but if it is not, maybe you could try raising it a bit. In the position it is now i think it could get some nasty multipath from carbon and kevlar around.
@Eosbandi, yes, I came to this same conclusion that the problem is in GPS unit. This annoying phenomenon has teasing our surveys quite a long time and causing several crashes and I have been weaponless against it. This discussion here has opened my eyes that problem is not in FC and FC is not changing primary alt source from GPS to baro.
I will definitely test M9P dual band GPS. So let’s stay tuned !
Good point. GPS unit was a bit buried in that plane. We have several planes and some units are not so buried, but while testing M9P GPS in future, better not to install it so deep in the plane fuselage.
I know I can change the altitude source from baro to gps. But is it possible to change to a specific GPS?
The reason I ask is I would like to keep the Here GPS connected to GPS1 with the lights and arm button and use a multiband GPS for positioning and altitude on GPS2.
