TRex 500 in a scale fuselage, using Matek H743MINI with Arductopter heli 4.3.3. I have test flown it before putting it back into its fuselage, but without any fence. Now that I’ve specified a height + radius fence I can’t get it to arm because I get the “Prearm: Fence requires postion” message even though MP is showing 11 or more sats, and shows “3D dgps”. With the fence disabled it arms and flies normally.
I’ve temporarily set prearm logging on, so below are the param and log files. I’ve unchecked EK3_GPS_CHECK options one at a time to see if any of them changes the situation, but they don’t. AHRS_GPS_MINSATS is set at 6. I’ve compared the param file with the one from my other TRex 500 which also has a height + radius fence and is arming okay, but can’t see any obvious differences. So any ideas what might be preventing arming please?
This log shows 7-8 sats and an Hdop from 2.3 to 2.75. That won’t fly, have to wait longer. In the image it shows an Hdop of 1.7, that’s not good either.
You need to wait until you see a message(s) “EKF3 IMUx is using GPS”.
Thanks Dave for that quick reply. Having done an internet search I now understand what HDOP is about, so my GPS_HDOP_GOOD value of 140 is saying that it needs to get below 1.4 to qualify as a position fix? That’s the default value, but would it be unreasonable if I were to increase it to, say, 200? I’m not looking for super-accurate landings; just to get it back into the ball park if I have a problem.
I’m testing in my garage, so I’ll go outside tomorrow if the weather’s good, and see if the message goes away.
I suspect it will and then problem solved w/o changing a term used for pre-arm. If you need to arm it for some reason indoors just temporarily disable the fence. You can set a switch to disable fence also.
I would be very shy about altering the GPS_HDOP_GOOD upwards. My fear would be you have a wandering position and the heli will try to follow it at takeoff and potentially tip over.
Instead try limiting the constellations to just 2
GPS_GNSS_MODE,5
you can try selecting different combinations until you get best/fastest time to low HDOP
In that log you are very close to structures and that would be a problem too.
That’s interesting Shawn. So restricting the number of constellations the GPS has to look at decreases the time it takes to get an accurate fix? I’m in UK, so is 2 constellations enough there?
Actually, I’ll wait until I’ve checked if going outdoors solves my initial problem, before playing with GPS_GNSS_MODE.
Yes.
It’s very safe to change GPS_GNSS_MODE, within reason of course
The GNSS units can easily be overwhelmed by more than two constellations - depends on the unit and it’s processing power of course, which will be loosely related to $. We see it in GPA.Delta in logs, that update rate should be steady at 200ms.
I chose GPS_GNSS_MODE,5 because that will suit your region.
Example:
Where I am there are lots of Beidou sats visible but if I choose that, the HDOP is worse and it takes longer to get a fix (set Home position). They clearly dont have the same accuracy as GPS. So at minimum you would remove these and any other unnecessary constellations.
Yes, can confirm this.
Sometimes less is better as GPS receiver can focus on those few constellations selected, rather than having to process the data coming from all constellations available at the time.
This is further complicated by the fact that we, who are dealing with aircraft, want fast update rates from the GPS receiver and not just a 1or 2Hz update rate as it may be the case on handheld devices for bush-walking or in many car GPS receivers.
I’ve tried again outdoors, and get hdop = 0.8 or so, but even after 10 minutes it still won’t arm. From a cold start, after about 3 minutes I got the chirp noise that says it’s got 3D fix, but when I tried to arm I got the ‘uh-oh’ buzz. Later on it appeared to arm (long buzz) but that was immediately followed by a short buzz – confirmed in MP by ‘ARMED’ message closely followed by ‘DISARMED’ message.
I’ve changed GPS_GNSS_MODE from 0 to 5, as suggested by shawn above, but apart from that the configuration is the same as before. There are no prearm error messages in MP.
Here’s the .bin file from one of today’s tests. It’s a ‘warm’ start, so sats were registered quickly. I hope it will reveal the issue, though I’m not experienced enough to analyse it.
Thanks Dave. I don’t understand that though; are these messages saying that my receiver has gone into failsafe mode? My radio system is Taranis X9D+2019 with FrSky receiver, and failsafe is set to ‘receiver’ in this heli and in my other TRex 500 which is working okay. My Taranis hasn’t given any loss of signal messages, so the receiver shouldn’t have gone into failsafe mode.
What’s really puzzling is that this heli has flown in Stabilise and PosHold mode before I installed it into its scale fuselage and programmed the fence. And I can still arm it if I disable the fence.
I don’t want to get too far out on limb with Trade Heli and you have it working OK on another craft but “No Pulses” is the typical FS mode used with a Flight Controller. There could be a reason you are using “Reciever” that I’m not aware of.
The behavior for radio failsafe’s should be no different between multi and Tradheli. I don’t know enough about the different radios and which failsafe type to use. But we share all of the common libraries and files in Copter regarding failsafes
Dave, that rings a bell. When I set up my first heli (the one that seems to be working okay) I seem to remember being advised to set my Rx failsafe mode to no-pulses. I’ll check that out tomorrow and correct it, if only to get consistency in my various crafts’ setups, though surely it would affect the heli with or without the fence enabled?
The GNSS settings look good, there’s nothing more you can do there except maybe check for a firmware update.
I’d day it must be subject to reflections or some kind of interference. You can see on the map it seems to be close to houses and the positions is wandering all over the place
In the log you can see the Lat, Long, Altitude and Speed are all varying. You wouldn’t want to be arming anything with all that going on.
The Glitch warnings are because Ardupilot is getting a particular compass heading and the GPS track is saying something totally different, so that will resolve itself when the GPS position catches up with reality.
Thanks for those replies. I’m familiar with the FrSky swamping issue, but when it happens I get multiple ‘signal lost/signal recovered’ warnings on my Tx, which doesn’t seem to happen with this particular setup.
My ‘workshop’ is in the garage roughly beneath the bottom left corner of the flat roof on the upper house in the screenshot. Yesterday when I took the heli outdoors I was lazy and only took it into the 2m-wide passageway between the two houses. I’ll try in the back garden this aftenoon, and hopefully that will prove that you’re correct Shawn. Otherwise I’ll have to wait until I can get to the wide open flying field.
At least this saga is proving to me that setting a fence is fulfilling my desired objective of preventing arming when GPS accuracy is doubtful I just didn’t appreciate the extent of the effect of buildings.
Tested in the back garden, with about 5m clear all round, and the same result. I then tried again with fence disabled, but same result again. Here’s a link to the log from the first test of those tests:
So now I only have two questions apart from what’s going on:-
Should I be patient and wait and see if it works at the flying field, with no buildings around, or should I remove it from the scale fuselage now to maybe swap out the GPS module?
How do you show the GPS track from the log on the mapping as you did in a previous post Shawn?
I just didn’t appreciate the extent of the effect of buildings.