It woul.d seem that GPSs and compasses are fairly problematic. Some systems use redundant GPSs.
I recently had a GPS failure during flight.
My question is why these units seem to be so unreliable? The GPS in my car never has any "glitches" (at least none are ever reported or evident). The compass in my car never fails.
The same with my cell phone. It never has issues.
So why do the ones connected to flight controllers so unreliable?
Is it that the GPS/compass units are low quality?
Is it that the wires are too long and unshielded for the noisy environment they are used in?
Is it that the controllers have unreliable software serial (GPS) or I2C hardware or software?
Has anyone checked the signal with an oscilloscope?
I would really like to know.
Replies
Asim said:
The two printers I have:
FlashForge Creator Pro (with many modifications) - this is fast, but can't handle things larger than about 150mm X 230mm X 230mm high. Extremely good for the price. I would recommend this one for most individual users.
RAISE3D N2 (with a few modifications) - A little slower but industrial strength and can print 310mm X 310mm X 310mm
parts.
Both have heated beds. I don't print in PLA because it turns to rubber if left in a car on a hot day. ABS, nylon or similar only.
Haven't had time to look at the flow chart. All my craft are custom and designed be me. I have 2 3D printers which helps a lot.
I don't fly beyond LOS in the USA. But I have flown the model shown in 2 countries outside the US. Previously, I DID have a SIM card that allowed me to use 4G in the country I was flying. Recently I switched to a cheap prepaid plan and found it doesn't work outside the US. The reason I fly that particular one is that it is one of my smallest and folds into a 9" X 12" X 5" package.
I ordered the dead reckoning GPS from -
https://drotek.com/shop/en/822-ublox-neo-m8u-gps-hmc5983-compass-xl...
The 4G link uses a Raspberry pi and a Novatel U551 4G "dongle" plus a camera and some software, including (partial list)-
ser2net
uv4l
webRTC
autoSSH
wvdial
And I also use an Amazon ec2 server to provide the reverse SSH tunnel.
Verizon doesn't allow incoming connections, so the Amazon server provides a tunnel. The drone "calls" the server and the server connects the two ends. Using the server also resolves network addresses to network names. Both sides simply connect to the same (named) server. The latency is really low - about 250mSec.
For video, I use webRTC because it is far superior to GSTREAMER when it comes to latency. I get 1280 X 960 video at 30 fps with no more than 0.6 sec latency.
I do plan on selling a complete package, but I'm still working out some of the finer details - like getting a decent controller to work with Mission Planner instead of the toy Logitech game controller they want you to use. I really hate that controller because the throttle snaps to mid-point if you let it go. Dangerous.
And sometimes, if the 4G connection is dropped, although it automatically "redials" Verizon, the ppp session doesn't restart.
I just ordered a GPS module from Drotek in France. This GPS module has a UBLOX NEO M8U module which offers dead reckoning. If the GPS screws up, the module still outputs GPS data until the data becomes "good" again.
Now, I just have to make certain that the signal quality from the GPS is perfect and also that the flight controller doesn't screw up and not interpret the data properly. I have a Raspberry pi and TEENSY (96Mhz version of Arduino) on board as well, so I'm certain I can figure out how to use them for my benefit. Currently, the Raspberry pi handles the 4G link, which does telemetry, control and live video, and the TEENSY does the failover from 4G <-> 915 MHz. I was only in trouble last week because there was no 4G. Time to upgrade my data plan!
Asim, Several things:
I sat on the ground for 5 minutes messing with my camera and gimbal. I took off manually, and then switched to AUTO after about 10 seconds.
I have my throttle failsafe set to CONTINUE WITH MISSION IF IN AUTO MODE. My radio is set to produce a PWM signal of 950uSec on the throttle output when it loses signal.
Yes, it continued on even after it lost radio signal. That is what it was supposed to do. I have flown dozens of missions in AUTO and out of radio range. This is the first time anything went wrong.
My code modifications only deal with current and voltage monitoring. And the log file shows that the battery voltage never got near battery failsafe, so that isn't what triggered the LAND.
I realize that I lost the telemetry signal (it drifted in and out), but it was in AUTO mode. Again, I have done this dozens of times with no problems in the past.
The distance between waypoint 1 & 2 was about 2.8KM.
Interestingly enough, the GPS I was using was EXACTLY the same as the one you have - I even bought it at the same source.
I'm using a 10,000mAH 4 cell battery. SunnySky X2814/1100KV with APC 10X4.7 APC props and 60A ESCs. I don't get a lot of air time (12-13 minutes) but I fly pretty fast (60KM/hr). Flying weight is usually about 2600g.
I normally don't worry about radio range. When home, I use 4G LTE for connectivity (telemetry + control). I couldn't use that setup for this flight because I was in a foreign country and my 'copter's "data plan" didn't include that country.
The RFD900+ radios are generally good for about 3KM in the city. But that is mostly because unless you are flying very high, at 3KM, you will get a lot of obstructions. I generally fly at 100M. If you are flying over a desert, you should get 6KM or so at that altitude, more if you are higher. I use one 9" antenna on the aircraft and two 9" antennas on the ground.
I do spreadsheets as well. See attached. The one that I lost was the "FOLABLE QUAD". This is a flyer that folds down to shoebox size. This is the one that I use for traveling.
I don't have a recent picture of it, but I have attached a picture taken before I made quite a few modifications. Note that this picture has a 5.8GHz FPV transmitter on board and KDE 2816 motors sitting on heatsinks. After rebuilding, the motors and heatsinks were replaced with SunnySky motrors. The 5.8GHz FPV transmitter was removed and replaced with a Raspberry pi model 3 and Novatel U551 4G LTE dongle.
Flight Time Calculator RevB.xlsx
Foldable Quad.jpg
I was using APM 2.8 controller. 3.2.1 firmware.
I realize that PixHawk is a better choice.
But I have 4 "fliers" and all have APM controllers. It is a lot easier for me if all are the same. The only things different are the PID and battery parameters. I didn't want to switch them all to PixHawks because of the cable and connector differences.
Another reason is that I can compile APM code, but I haven't yet been successful in compiling PixHawk firmware.
I have modified the code to do a better job of averaging the battery current reading, and also included a routine which multiplies the battery current times the battery ESR and adds that to the voltage reading. That gives me a much better idea of the real battery state.
And until a few days ago, the APM controllers worked perfectly.
The reason that I had GPS FS set to LAND was that it had never been an issue before, and I normally fly over land. It was simply an oversight. And yes, I was getting telemetry - kind of. I was at the range limit of my RFD900+ radios and the signal was drifting in and out. I'm trying to determine if the GPS receiver stopped receiving or if the RS-232 signal from the GPS got corrupted.
Maybe you can tell me. The log file is attached, and the trouble began at about 6:59:56
Finally, does anyone make a module that contains a UBlox NEO-M8U module? The M8U module has dead reckoning built in.
2017-05-10 06-52-13.tlog
Are you certain? I have a portable GARMIN that can't do dead reckoning, since it has no vehicle input. It doesn't seem to give bad information when it has a clear view of the sky - ever.
From time to time, I got "BAD GPS HEALTH" messages from MP. At the time, so several months ago, as a test, I hooked up the UBLOX NEO-7M to my laptop using a USB<->RS-232/TTL adapter. I had a 15' "boosted" USB cable I put the GPS on my deck. I kept a log file overnight using BRAY's TERMINAL program. A check in the morning showed no missing data. I realize this wasn't a very scientific test, but made me realize that the GPS wasn't terribly unreliable. It is also true that the GPS I used for my test was stationary.
Finally, I GOOGLEd around and don't find people complaining about GPSs not working when there is clear sky.
So, I put the GPS on my quad and it flew perfectly - until yesterday when the GPS failed and the craft landed nicely - in the ocean. I was too far away to regain control. FailSafe was set to LAND on GPS fail.
I am 99% certain that my connections were good and the wires were not broken.
Could there be some other factor that causes unreliable GPS readings when used with APMs?
I'm away from home until this coming weekend, but I thought that I would put a scope on the lines and check for good levels and general signal quality as soon as I can. I'm an EE and do hardware design, so I certainly know what to look for.
And don't APMs use a software serial port for GPS input? If so, is there a chance that the routines could be blocked (by ISRs or something else) and could lead to unreliable READs?
I need to know. This failure cost me about $1500.
Chris Anderson said:
The GPS in your car and phone lose signal all the time -- it just isn't reported in the app or is compensated for with other sensors, because it doesn't matter very much if it's exactly right (because it has a driver). Just go through a tunnel and you'll see -- your position is reported by the wheel encoders, not the GPS. Likewise the compass in your car "fails" all the time, in the same sense that it does on an autopilot, which is to say that it's not perfectly calibrated. It just doesn't matter very much so you don't notice. The mag in an autopilot only "fails" in the sense that it doesn't pass a very stringent calibration or data validity test.
Basically, autopilots are doing something *much* harder than your phone or car, so they apply much higher standards of acceptable performance on their sensors.