During my testing to find the problem with SBF GPS functions I think I have uncovered a bug if someone could duplicate it and confirm.
I would recommend this be done with the props off.
Procedure:
Power up and wait for LED to flash green.
Switch to Loiter and observe the LED going blue.
Switch back to Stab LED goes green, and arm.
Move throttle up so it doesn’t auto disarm and change to loiter.
Refusal tones sound but LED stays green.
Move throttle down in loiter and disarm.
LED stays green starts to flash as expected.
While still in loiter arm again, LED stays green and goes solid, giving the impression you are in Loiter but in fact you are in Stab.
I found this because the SBF GPS will not go into any auto modes and generates a GPS Horiz error.
But I can envisage this happening if someone has a week GPS that is not sufficient.
There is evidently something amiss with the 3D Fix/HDOP analysis if we get a green light for auto modes but it then refuses and goes blue when we actually switch into those modes.
Your description sounds correct. When you are in Stabilize it shows green because you don’t need GPS, so it means you are good to go - there have been past talks to change this to yellow if there is no GPS lock, but nobody committed to do it.
Once you change to Loiter, you need GPS so it changes to blue if there’s no GPS lock. After you have armed you tried to change to Loiter but it wasn’t allowed (as per your refusal tones) because you still didn’t get a GPS lock, so you stayed in Stabilize (and hence the green led).
You weren’t in Loiter at this point, you were in Stabilize.
I hope this has clarified it for you.
Have you talked to the SBF guys? They made the driver and should be able to help you.
@OXINARF it seems very confusing.
As the green is used to indicate guided modes are good to go, and blue that manual modes are ok, to be left in Stab, with the Tx switch in Loiter and a green LED does not make sense.
On the ground before arming the indicator is clear with blue showing until a GPS lock is achieved and green to show auto modes are available.
With 3.4 now, you switch to a guided mode and the FC changes its mind and switches to blue, but that at least shows you there is a change of mind and why it will not arm.
I would have expected the same logical procedure even if armed and flying, you get the warning beeps AND the LED changes to blue. This gives the user a clear indication that he has GPS issues and he knows where to look.
I can see the current situation as counter intuitive as you can think you are in a guided mode and the copter wanders off because it is really only in Stab.
I am still trying to track down the ‘SBF guys’.
The closest I have come is finding @Michael_Oborne did the PR’s on the Swift library which seemed to be the ones with the SBF routines. I have PM’ed him with no reply as yet.
Is there anyone else involved with implementation of the SBF routines?
They are definitely broken in 3.4.
when armed it shows blue/green based on GPS 3D lock, regardless of mode
when unarmed, green is showed when you have 3D lock and have passed GPS pre-arm checks
So you had 3D lock (reported by the GPS), but it wasn’t good enough for the EKF, failing the GPS pre-arm checks for modes that need an absolute position.
Right now green doesn’t say that, it basically means you are good to go in the mode you are in.
Like I’ve said above you actually have 3D lock and that’s why it shows green, regardless of mode. But it wouldn’t make sense to change to blue because the mode hasn’t changed. You shouldn’t think you are in a GPS mode because it is refused and you are warned with a tone - if you are too far away that you can’t hear it then you should use a GCS.
@OXINARF I agree with where you are coming from.
Reading through the Wiki it states clearly that blue = No GPS lock and green = GPS Lock.
And this was always the case with FW < 3.4
You wait until Green, then you start your Auto mission, or any guided mode.
If it remains Blue you can only use manual modes.
However
This is NOT now the case.
And this is the point I am trying to make.
Even though the LED goes green it NO LONGER means you are good to go in any GPS Mode so why change it to green.
From what you are saying I actually need to go through all 6 modes I have on my Tx watching the Green LED to see if it changes to Blue for a mode so I know that I cannot use that mode or need to wait for some undetermined state to improve before I can use it.
Where is the logic in that?
The LED colour, according to the Wiki, is not related to Mode but to the GPS state for guided modes
“Solid green - with single long tone at time of arming: Armed, GPS lock acquired. Ready to fly!”
With 3.4 it is now dangerous to change modes in flight because you may or may not get that mode depending on the internal state for that mode.
I must agree to mboland. Everyone is used to the simple system green=GPS-ok, blue=no-GPS, but anything other is ok. Regardless of the actual selected light mode. With a green LED indicating that GPS is ok, I can take off in stabilized mode and switch to GPS modes later without any bad surprises.
Changing this in 3.4 would be extremly irritating, and will lead to a lot of GPS-related user problems.
And what about setting the RTH? If a green LED indicates “your actual flight mode is ok, regardless the GPS lock”, how will I know whether the RTH is set at takeoff?
Changing the LED colours does not make any sense in my oppinion.
Let me be absolutely clear: nothing changed between 3.3 and 3.4
Like I’ve clarified above, green is only showed if you have a GPS lock. But to show green (when unarmed) that’s not enough, you also need to pass the GPS pre-arm checks. And the GPS pre-arm checks are different for different modes. For modes that don’t require GPS (like Stabilize) we don’t care if the EKF is happy with your GPS lock or not because we don’t need your position to use that mode. For modes that need GPS we do more GPS pre-arm checks because we need to be sure we have a good GPS lock and the EKF is happy with it.
Also, both of you said that you think that taking of with green means you can always change to a GPS mode while in flight: that’s not true, never was true and will never be true. And the reason is really simple: just because you have a good GPS lock on takeoff that doesn’t mean it will keep the same through out your flight: the lock may degrade, you may completely lose the lock or the GPS may simply glitch.
If you want to be sure you have a good GPS lock and that home will be correctly set on arming change to a GPS mode and wait for it to be green.
@OXINARF I do understand what you are saying.
And I can see that the new EKF routines have added a lot of initialisation changes.
I am commenting on this from the perspective of someone who has been using APM from the 1.4 days through all the iterations to the present.
As just a user I have nothing more to go on than the Wiki and what is revealed in forum threads such as this.
I can point out, conclusively, from versions <= 3.2.1 that when the GPS indicator showed a lock you could be sure that any guided modes you were about to use would work.
I have production machines out there in use that prove this.
If this is NOT now the case then it needs to be clearly stated in the Wiki, or I foresee a huge number of issues, and probably accidents, from uses not understanding this and expecting, as I did, that the indicated Green=GPS Lock meant that guided modes are good to go.
I would have thought it would be more logical to keep the expected function of the indicator LED’s and for the GPS pre-arming routines to step through the internally stored flight modes before giving the Green to Go indication.
Either this or add a large red addendum to the Wiki on LED indicators that each flight mode must be checked prior to flight.
This has come to light, for me anyway, because of the one machine I am building that uses SBF, which clearly has a GPS Horiz problem which does not pass any pre-arm checks, even though it gives a Green LED when it gets a 3D Fix.
Another identical Octo with PixHawk and a M8N GPS still gives a Blue LED for a while if you switch to say, Loiter, after getting the Green LED in Stab.
I wasn’t around when the 3.2.1 was the stable release so I won’t comment on it. But 3.3 has been out for about a year and it already has this led behavior.
I agree that the led situation could be improved - and, as I’ve said, there were discussions around it but no one did it. There were also discussions about always enforcing a good GPS lock for all modes when arming, but not everyone agrees with it because that would enforce something that isn’t needed in some modes.
Regarding the wiki, PRs with corrections are welcome. Unfortunately we can’t do everything and we hope that, as we work for the benefit of the community, the community can also contribute back.
I do appreciate the time the Dev’s put in and always try to contribute what I can to help, such as this forum entry.
Having worked with technical documents my whole working life I would be happy to help with the Wiki where I can.
I think there should definitely be an update to alert users to this change in GPS indication, especially as 3.4 seems to be getting stricter in this regard.
I agree about alerting the community when a basic change in behavior is being made. Wasted time at best and crashes at worst can occur before people figure out what changed. (THR_MID reliance and barometer reset are other past examples that the community needs to be alerted about.)
thanks for the testing and feedback. To be clear, there’s no change in behaviour of the LEDs between Copter-3.3 and Copter-3.4. There was a change between AC3.2.1 and AC3.3 though. In case it matters, the change stems from the inertial nav system which was less rigorous would simply do it’s best while the EKF simply refuses to give a position if it hasn’t initialised yet.
I’ve created an issue to capture this request. https://github.com/ArduPilot/ardupilot/issues/4918. I’ve tentatively marked it for AC3.4.1. As long as most people are happy with this I’m happy, but because it’s not a change since our most recent official release, I don’t think it’s a show-stopper that we need to fix before pushing out AC3.4.