This is the first time I have seen this error and do not know what it means. When trying to arm using APM Plane 3.5.2 I received the error “Prearm: GPS 1has not been fully configured”.
I tried changing the GPS cables and used a new GPS but have the same issue.
Any idea what this warning is for? I am not aware of any configurations required for the GPS beyond stuck. This is a stock ublox unit from 3d Robotics.
can you please post a tlog of when you get this problem?
That message is caused by ArduPilot being unable to complete the configuration process of the GPS. For example, if the GPS doesn’t respond to requests to change a message rate.
This can be caused by a bad transmit wire between the autopilot and the GPS, but it could also be a software problem. We may be able to learn more from a tlog
actually, no need for the tlog. I just realised it said “GPS 1”. That is the 2nd GPS (first GPS is GPS 0).
So the problem is you have 2 GPS modules enabled, but only one fitted. If you don’t intend to have two GPS modules then set the parameter GPS_TYPE2 to zero to fix the problem.
Awesome, thanks tridge. Silly mistake on my part as I was playing around with a second GPS in the past and forgot to turn it off. However, is there any way that arduplane could recognize that there is no GPS attached and not cause it to alert the arming check, but, still recognize if there is a GPS attached but just an error with the configuration?
The current behavior is by design. If you tell the autopilot there should be 2 GPS’s connected we want to ensure that there are 2 GPS devices connected. There is no way to differentiate if there isn’t a GPS or a broken wire that means you have a real problem with the GPS. Because the default setting is that there is no secondary GPS I don’t think that’s a huge problem.
Hey guys, I am seeing the same message for GPS0. I am outside with a good GPS lock (“3D dgps” and 11 satellites).
I am using an RTFHawk with the gps/compass that came with it, the uBlox 6M GPS w/ mounting backplane and compass. I am concerned that the problem may be with the GPS - it’s web page says that it as “Permanent Configuration Retention” which makes me wonder if ArduPlane is trying to configure it and being prevented from doing so.
@Will_Barley I don’t see anything obviously wrong in those parameters. Unfortunately in that version of the firmware there are no further debug options that make it easier to assess. I have a pull request in https://github.com/ArduPilot/ardupilot/pull/3892 that will address this, but until that’s in it’s hard to give further advice on testing. (Without giving a lot of probable dead ends.) If you have a FTDI cable and u-center and want to dump the configuration I can definitely take a look at it.
Really regret not getting that PR in before the version of plane went out. Looking back its obvious that this was going to be a problem
@marcmerlin It’s correct, it fails if the speed error is greater then the needed one. The problem is that its a floating point number, so it means that 1.50001 is greater, but when we convert it to print it comes out as 1.5
I have had this same problem with every plane i have tried to install Pixhawk4d on. I even sent the log files to the 3dr engineers. Never got the issue resolved. pretty dissapointing. I hadn’t had this problem with my old APM boards.
I have tried it with both GPS disabled and enabled. I am using the 3dr GPS with
Onboard compass. I had this same
GPS on the same plane with APM and it was fine. It wasn’t until i upgraded to pix4d that the plane started to collect dust. I had assumed I had damaged the pins on the GPS during the removal and installation process, when I upgraded to pix4d. I have installed APM on several planes and quads, as well as successfully upgrading a quad to pix4d without any issues that I couldn’t solve
For within a day or two. Now my only plane I have tried to transition to pix4D has been essentially parked…
When you say Pix4D all that I know of for that is the photogrammetry software, not any autopilot board. Do you have a link to the board? Plane 3.5.3 will report why it is failing configuration checks which should let you get to the bottom of it. (Unless you meant the speed error thing)