I’m sure it will, but I think the EKF can detect and correct the error between GNSS position and wheel odometry. @rmackay9 or one of the other developers can correct me if I’m wrong on that. I want to say there are parameters that govern how much weight is given to one or the other, but I’m not sure.
My rover weighs ~200lb and so slipping isn’t a huge issue for me. If you encounter a situation where the rover stopped moving but the wheels kept spinning you’d probably get warnings of some kind.
Hi everyone, I’m not sure this is the right place for posting this, but we recently launched a new GNSS receiver based on Septentrio Mosaic-H and compatible with ArduPilot GPS Yaw estimation.
We have prepared a brief tutorial explaining how to connect and configure it:
SimpleRTK3B Tutorial
I think its better if you made a new topic for that
Hi Folks,
simpleRTK2B+heading - Basic Starter Kit is supposed to provide correct heading even without ardurover connected, isn’t? Connected simpleRTK2B (with Lite on top) via USB+GPS to the PC, but U-Center is not displaying any heading info. Antennas are 1m in between, config updated as per @jolivart instructions above. Fix mode is always 3D Fix and never RTK fix, even though antennas in an open area outside.
Hi @Muse ,
This kit provides RELPOSNED without ardurover connected.
Make sure to connect a USB cable to the POWER+GPS USB port (not the POWER+XBEE).
You can also check UBX-RXM-RTCM message to verify that your configuration is correct, you should receive RTCM messages at 10Hz if you are using the 10Hz configuration files.
@jolivart , thanks for prompt response. Reuploaded 10Hz config to both boards again, but still not getting heading/length values, all zeroes and still 3D Fix. RTCM seem to be flowing. Noticed that Message Type 4072.0 is not there, could it be the reason?
GPS FIX LEDs blink once a sec on both boards.
Xbee->GPS - blinks rapidly
NO RTK - constantly ON.
Then connected to Lite via USB+Xbee, finding ERROR: txbuf alloc in UBX-INF and missing 4072.0:
Not sure anything in these screenshot helps to identify what could be wrong
Just to be sure:
txbuf alloc is a common error when too much data enters the ZED-F9P, it usually happens at high rates and when this happens, strange behaviors are to be expected.
If the above questions are positive, I suggest you to bring both modules to their default configuration (UBX-CFG-CFG), save the configuration, restart both of them and reload the moving base configurations (I would start first with the rover and then the moving base).
A nice check to do to both units is UBX-MON-TXBUF and UBX-MON-RXBUF, they should not be saturated, otherwise not all messages can be processed.
@jolivart yup, did exactly that probably ten times with 10Hz config files, but results were the same.
BUT tried 5Hz files - and now heading and lengths are shown!
10Hz is above of u-blox maximum frequency specifications (8Hz) but in general it works fine (some epochs may be lost, but it is no critical).
Do you have the latest firmware (1.13) on both moving base and rover?
You should be able to load the 10Hz and get the system working.
With your current 5Hz configuration, can you check UBX-MON-TXBUF and UBX-MON-RXBUF status?
By changing the rate to 10Hz, you should get ± double of what you see so in order to work it should be <50%.
A common mistake when loading the configuration file is to click one time, by mistake the GNSS>File button instead of File>GNSS, and the configuration file is overwritten, so next time you try you are using a bad configuration file.
I suggest to download the 10Hz files from our website and place them in a new folder and repeat the process again.
@jolivart first of all, many thanks for spending your time and trying to solve this mystery.
Re-uploaded freshly downloaded 10Hz files, but nothing has changed, still no heading/length values. Notice that Tx is 98-99% on the Moving Base:
On Rover Rx is just 4%
Whereas with 5Hz Moving Base Tx is just 17%:
5Hz Rover Rx 4%:
Also with 5Hz config, message type 4072.0 is present but not in 10Hz config.
Both run on FW 1.13 although noticed that 1.30 is also available on the ardusimple portal.
(all parameters are similar between Rover and Moving Base in VER)
Our apologies, I have finally been able to get my hands on the hardware and as you mentioned, the configuration file was not ok.
We have updated the moving base 10Hz configuration file:
simpleRTK2B_FW113_HeadingKit_MovingBase_10Hz_Ardupilot-02.txt
It should work now, please let me know if you have any issues.
Thanks,
Josep
Success, now heading is acquired in u-center correctly with v02 10Hz MovingBase config. Now just need to get Yaw working on ArduRover 4.1.3.
Interesting thing, Fixed Base is displayed as Moving Base in the Mission Planner HUD.
Whereas Fixed Base is actually connected to the PC and is feeding RTCM corrections. Meanwhile Pixhawk is running separately (with MovingBase GPS_TYPE = 17 + Rover GPS_TYPE=18) on the battery, communicating via SiK.
That’s just a typo in MP.
Mission planner struggles with Moving Base, continuously reporting GPS 1: detected as u-blox at 460800 baud jumping between No GPS and Fix GPS. Wonder if this has something to do with the v02 MovingBase config file or my 4.1.3 ardurover settings?
| Peripherals | Port on Pixhawk Cube Orange | Config | Value |
|---|---|---|---|
| SimpleRTK2Blite with Tx and Rx cross cable | Telem1 | GPS_TYPE | 17 |
| SERIAL1_BAUD | 460 | ||
| SERIAL1_OPTIONS | 8 | ||
| SERIAL1_PROTOCOL | 5 | ||
| SimpleRTK2B with straight cable | Telem2 | GPS_TYPE2 | 18 |
| SERIAL2_BAUD | 115 | ||
| SERIAL2_OPTIONS | 0 | ||
| SERIAL2_PROTOCOL | 5 | ||
| COMPASS_ENABLE | 0 | ||
| — | — | — | — |
| COMPASS_USE | 0 | ||
| COMPASS_USE2 | 0 | ||
| COMPASS_USE3 | 0 | ||
| EK3_MAG_CAL | 2 | ||
| EK3_SRC1_YAW | 2 | ||
| GPS_AUTO_CONFIG | 0 | ||
| GPS_AUTO_SWITCH | 0 | ||
| GPS_POS1_X | -1 | ||
| GPS_POS2_X | 0 | ||
| GPS_PRIMARY | 1 | ||
| GPS_RATE_MS | 100 | ||
| GPS_RATE_MS2 | 100 | ||
| GPS_DRV_OPTIONS | 0 | ||
| GPS_INJECT_TO | 127 |
Mission Planner isn’t struggling, your autopilot is. You may have a power supply or wiring issue.
Yuri, you might be right, I’ve been testing outside in the freezing temperatures, cube orange running of a power bank. Cold could have impacted battery performance.
Spent hours and hours (more like days now), trying to get moving base/rover/fixed based working and still there is always something not working as expected… Starting to doubt and question myself on everything:
Moving Base (F9P Lite) and Rover- should it have straight cable connected to Cube Orange with serial_option =0 or else?
Moving Based and Rover is connected to 17 and 18, but MP dashboard still shows GPS: No GPS and GPS2: Rtk float. If No GPS, how is it possible that actual rover position is still shown correctly on the map? Worth mentioning, that EKF3 waiting for GPS config data is continuously repeated - could it be the reason?
RELPOSNED and RTCM seem to stop working when once connected to Cube Orange. Can it be that MP is overwriting default receiver config on F9P with GPS_AUTO_CONFIG = 1 or GPS_CFG_SAVE = 1? Once receiver config is reuploaded, it starts reporting heading in the u-center immediately again. CFG-Send is always performed. Haven’t tried all the options yet to pinpoint at which point it stops working exactly.
if Cube Orange is placed not exactly in the position reported in GPS_POS*, does it impact GPS2_YAW numbers? It is always 655*** even though heading is shown correctly in u-center when accuracy is <20%. Hardware is not attached to the mower yet, thus cube orange placement is not fixed in relation to the Moving Base and Rover antennas.
Piggyback setup of F9P+F9PLite
I don’t think you want GPS_AUTO_CONFIG=1 for your arrangement. But that still doesn’t explain the re-initialization behavior. I caused that once by mis-wiring another component that caused a high power draw through the autopilot’s GPIO pins.
Mis-placement of the Cube relative to the GPS antennas shouldn’t cause a complete failure of GPS heading.
Finally some breakthrough. Tested a few more times, GPS_AUTO_CONFIG =1 indeed overwrites GPS config which results in not displaying heading anymore in u-center, had to disable it and reload receiver’s config. Accuracy outside without Fixed base is 0.0100m, RTK Fixed, calculated length between antennas is spot on 96cm and GPS2_YAW is showing realistic figures in the MAVLink inspector, hallelujah!!!. BUT MP still ignores it and displays yaw of the Pixhawk,. Ahhhrrrr… EK3_MAG_CAL = 5 (but depreciated for Rover 4.1), EK3_SRC1_YAW = 2 (GPS), can’t think of any other config to check.
Dashboard still shows No GPS and EKF3 waiting, but actual position is displayed correctly on the map. Even if cable between Lite and Pixhawk is disconnected. Isn’t Lite supposed to provide position instead of Rover @jolivart ?
[EDIT, testing further]
If Moving Base is unplugged and instead Rover is moved from SecondGPS into FirstGPS on PX4, it changes to (no YAW though):
Does it mean Moving Base (Lite) is not feeding needed info directly to Pixhawk?
GPS_TYPEs are set to 17 and 18, GPS_AUTO_CONFIG = 0
[EDIT 2, getting crazy]
Rover connected to SecondGPS, Moving Base to the FirstGPS. GPS_TYPE1=0, GPS_TYPE2=18. How come GPS2 is not displayed anymore even though GPS_TYPE2 is still 18? GPS2_YAW is also shown as 0… Totally lost how data is flowing.
I was afraid this may happen. The SimpleRTK2B+Heading daughterboard config is a bit strange, and it’s entirely possible that a null GPS0 is problematic. @tridge, any insight there?
Guys, since ArduRover 4.1.0-dev is nowhere to be found for downloading, would you mind sharing it?
