I would like to share my recent project about indoor positioning system based on UWB modules. I’m really appreciated about what Randy had done Pozyx with ArduPilot for non-GPS navigation. I would like to have a try with other methods.
The original idea is based on ArduPilot which can set to Loiter mode in an open environment, the natural idea is making a Fake GPS signal to cheat the drone as if it flies outdoors.
There are two ways for making a Fake GPS signal:
a. NMEA0183, this is a common GPS protocol which used for transporting information from GNSS receiver to other devices. The information contains latitude, longitude, altitude, satellite numbers, position fix, etc. As for ArduCopter firmware, it just uses GGA, RMC, VTG messages for getting enough information to locate position outdoors.
b. Mavlink GPS_INPUT(#232) command, this is a GPS sensor input message which is a raw sensor value.
I test these two ways and find that GPS_INPUT command is much better. My drone is not right here, so I may not supply some datas to indicate my judgement, really sorry.
Here is some diagrams to introduce that I have done.
A QT GroundStation shows the drone position and sends Waypoint command
- Diagram shows the process to get GPS_INPUT message from UWB module
- Setting position of four anchors, ZYX refers to really distance between two anchors
- how to choose the original latitude and longitude. (It is based on degree precision, as UWB module has 15-20cm error, we can get from figure that 11 degrees is a better choice)
ps. I refer the Hendrik’s way for changing the firmware code of ArduCopter
pps. The test video and the log
Really great to see this. When developing the pozyx beacon support, we originally used the “fake GPS” (aka GPS_INPUT) method as a starting point but then moved onto the more integrated beacon approach. According to Paul Riseborough with individual beacons we can get some information even if only one beacon is within range and it helps the position estimation. I also found in testing that AP_Beacon worked better than when we were using the fake GPS method. In any case, the Fake GPS is definitely useful to have and I’ve seen others use this method as well for integrating with ROS.
Thanks for the blog post!
Yes, thank you for outlining your solution!
I am not sure that I fully understand the ins and outs of it, but I am curious if this approach would also allow for a seamless and accurate moving between a “real”-GPS (outdoors) and a “fake”-GPS (indoors), essentially fusing the two environments?
What are your thoughts to achieve this?
P.S.: (We had another discussion in a similar vein here, but it has not come to full fruition yet)
The fusing of GPSs is a good idea. I guess you’ve seen this page describing how the blending works?
The key thing is that the weighting between the GPSs depends upon the state (i.e. 2D fix, 3D Fix, RTK Fixed/Floating) and the GPS provided estimated speed and position accuracy.
Also you can define whether you’d like the EKF to hard switch between the GPSs (aka “Use best”) or blend. My guess is you’d want to go for the hard switch actually because it will be difficult to provide the estimated speed and position accuracy with NMEA messages. If you could provide this extra info then the blending would work.
Thanks for those insights and the link.
I see a need for this while moving back and forth between a solid GPS signal, a somewhat degraded GPS signal and an area fitted with a secondary beacon network providing a “Fake GPS” signal.
So my first take-away would be that the “Fake GPS” setup ought to also supply speed estimation for this scenario to fuse well.
I am not familiar enough how position accuracy is communicated. Could you maybe elaborate a bit how this could be achieved with a UWB/ Pozyx/ similar beacon network?
Hello bro your project is very cool, I’m working on the same thing, but I’m having trouble getting GPS input comand in the form of mavlink. can you show it
I’m having the following message error: Compass Variance : In the EKF solution, compass heading disagrees with the heading estimate from other inertial sensors. Clicking the EKF button on the Mission Planner HUD will show the magnitude of the error.
I already changed the BCN_ORIENT_YAW correcting to North, it looks like the compass still has some difficulties getting the right oriëntation, which gives issues while loitering, makes the circling bigger. I figured that I could try changing the AHRS_ORIENTATION
How do I determine which value I exactly need?
the COMPASS_DEC, but I don’t know which values are valid. I checked the Magnet Declination on .and gives me this:"Magnetic Declination: +1° 17’
Declination is POSITIVE (EAST)
Inclination: 67° 11’
Magnetic field strength: 49140.6 nT " Should I adjust that manually?
@rmackay9 Could you tell me by any chance?
2 1-1-1980 01-00-00.bin
I’m doing the Pozyx IndoorLoiter project for my drone. So I know where the first errors come from, thats because I didn’t had enough altitude before loitering. In the last cycle the loitering works to a certain degree, because I’m having COMPASS VARIANCE error. The BCON_ORIENT_YAW have been set, so the pozyx positioning knows whats North. When loitering I try do some circling on the same altitude with pitch and roll, then I notice the circling is to wide. Which refers most probably to the COMPASS VARIANCE error. How can I fix this? I was thinking of adjusting the AHRS_ORIENTATION. But I don’t know what values to use. Also I’m using the internal compass of the PX. Is it possible it has to much interference of metal construction of the Hangar I’m in. Does this mean I have to set the declination manualy?
You can find DataFlash Log .bin File HERE