@Yuri_Rage one of my rovers is not getting the EKF Yaw Aligned message, i.e. I am not getting GPS yaw. Do you know how I can view the actual RELPOSNED and PVT messages that the ardurover software should be receiving from that GPS? Is there a debug setting somewhere? I don’t see them in the flash log. Are they in there?
I don’t think you can view them directly. Is your rover GPS showing an RTK fix?
For which GPS? In my config, Telem1 is connected to the “big board” and Telem2 is connected to the “small board”. The small board, GPS2, should be the source for GPS yaw.
Working mower (running on a Pixhawk 4) shows this:
The other mower (Pixhawk 6C) shows this:
and when arming, the not-working mower also shows this. Note “DCM Active”. I don’t see “DCM Active” on the working mower. Does DCM Active mean that EKF3 isn’t active??
Ok, let’s go back to basics. These problems are almost always the result of some missing/incorrect parameter.
First, on a moving baseline configuration, you have a moving base GPS that provides corrections to the rover GPS. The rover GPS’s location relative to the moving base is what provides heading (yaw) information. In this case, the rover GPS is most likely GPS2, if you have it configured per the documentation.
It is a common misconception that you need to inject external RTCM3/NTRIP data to the moving base in order for GPS-for-yaw to work. That is incorrect, and for troubleshooting’s sake, I recommend removing the external correction source. It will help clearly delineate where the problems lie to have only the onboard corrections in play.
Share your parameter file. I suspect the issue will be obvious.
Lastly, a bit of opinion - ArduSimple keeps pushing their daughterboard setup for GPS heading, but it is super finicky to set up with ArduPilot, and to be frank, I HATE it. You’ll experience far less frustration by simply connecting two of the SimpleRTK2B boards to any given autopilot.
Logfile https://drive.google.com/file/d/15x3nREPtLJW905N0YQc5jUQaeUY-Af0i/view?usp=share_link
Params https://drive.google.com/file/d/185xP8EWmSb1r7KgPyqoWrypxXtS9WiCn/view?usp=share_link
I have the Ardusimple daughterboard configuration (simpleRTK2Blite, lightest solution with ZED-F9P - ArduSimple) and it works (including external corrections for precise location and GPS yaw for heading) on one of my rovers… Here is the setup I have been following: https://www.ardusimple.com/ardupilot-simplertk2bheading-configuration-external-corrections/
I agree it is finicky. The same setup had been working at one point on the other rovers but it has stopped working (on the ‘not-working’ rover I mentioned above).
At this point I could certainly experiment with physically unmounting the 2 boards and letting the ardurover software handle the communication of the RTK messages between the 2 boards for purposes of having one of the boards serve up RELPOSNED (which is the message with GPS yaw).
I rebooted the autopilot and the watchdog messages (“WDG:”) went away, here’s a logfile of the autopilot running
https://drive.google.com/file/d/1HFNQKkrwF8tMmchWa4A_DT5uPh1j8L9I/view?usp=share_link
I think the issue is likely with the configuration files. They are written for firmware version 1.13 and I think uCenter handles things poorly if the firmware is mismatched. Ensure you are running 1.13 firmware on your SimpleRTK F9Ps before proceeding farther down the rabbit holes.
Of note, 1.13 is quite outdated now, though it should still work fine for this application…yet another reason for my disdain of this particular configuration.
Yep, checked that, 1.13 firmware on all of the F9Ps.
Safe to assume you’ve reloaded ArduSimple’s provided config files after this problem appeared?
Also, in your log file, GPS2 is performing significantly worse than GPS1 in all aspects. It’s seeing a varying number of satellites, and consistently fewer than GPS1, and all other reported values seem to follow suit. Loose antenna connection? Frayed//kinked/damaged wire?
Another point to consider…if you ever accidentally allow GPS_AUTO_CONFIG and GPS_SAVE_CFG to become enabled (and they are by default), the F9P configs from uCenter will be overwritten, and the daughterboard arrangement will not work properly.
1 Like
OK, I:
- disconnected simpleRTK2B+Heading from Pixhawk. The small board is mounted on the bigboard.
- Using u-center, reset both ardusimple boards to the default config (using UBX->CFG->CFG) then using uCenter, uploaded the ardusimple recommended config .TXT files
- Using u-center, confirmed that, a few minutes after powerup, the small board is outputting RELPOSNED message with correct length, heading, and 28-29-30 SV
- Set Ardurover params GPS_AUTO_CONFIG and GPS_SAVE_CONFIG to 0
- Connected to pixhawk and restarted and waited. Here is the logfile
https://drive.google.com/file/d/1nAuH-gVXyFFUGCKigY3iSsV8WoRrhw5W/view?usp=share_link
I get EKF active but I don’t get the IMU0 initialized messages I am accustomed to seeing on the other (working) rover.
@tridge @Yuri_Rage are you able to look at this logfile and see if you see anything? if you look at the EKF flags do they tell you anything?
Thanks!
I’m not at the computer anymore, but if the rover GPS is still not reporting RTK Fixed, and the autopilot is not yaw aligned, then the EKF will remain failsafed. In other words, I think the GPS config issue is the root cause.
Are you certain that you’ve not mixed the config files for the moving base and rover up?
And is the GPS_POS1_X param accurate for the distance between antennas?
It’s almost always the simple things…
Thanks for asking about the simple things, but, yes, i’m sure I’ve not mixed up the config files. (I even extracted config files from my working mower’s GPSs and compared with the configs from ardusimple and with the configs from the non-working mower). GPS_POS_X is right. In addition to comparing GPS configs, I also compared params between the working and non-working mower and they are the same in all material respects. (The non-working mower has never “seen” a compass so it’s compass_ID params are 0, whereas the working mower has “seen” a compass before i switched over to GPS yaw, so, those params do differ, and I suppose there is some obscure dependency on some compass param within the EKF code, even though COMPASS_USE are all 0). I have begun swapping components, one component at a time, to determine what component causes the gps yaw not to work on the one mower when it does on the other.
Is there anything special to be aware of when running Pixhawk 6C (non-working mower) vs Pixhawk 4 (working mower). Are the TELEM1 / TELEM2 to uart/serial port mappings different?
Right now I suspect that the non-working mower isn’t even receiving the RELPOSNED message (on TELEM2’s GPS) that would get gps yaw to be working. But i don’t know why that is.
As I said, the Ardusimple GPSs in the piggyback configuration, when not connected to Pixhawk, do lock in and produce RELPOSNED messages.
Are you sure there’s no way of observing the GPS messages that arrive at the Pixhawk’s ports?
Those messages are parsed and relayed as MAVLink, and logged as the GPS.x values. They are not logged or visible directly via any means of which I’m aware (that would be a lot of overhead!). MAVLink’s GPS2_RAW.yaw is the closest I know of. Your logs show a consistent zero value there, which is usually indicative of a configuration error. If GPS2_RAW.yaw shows 65535, then the autopilot is attempting to use it for yaw but cannot (as in precision issues or antenna distance mis-measurement).
If the compass is disabled and the EKF yaw source is GPS, it doesn’t matter if there are some lingering calibration values.
You ask a valid question regarding the 6C. I’ve never used one. The firmware target for it is fairly new. That’s the next logical troubleshooting step, and you may be onto something regarding UART mapping.
1 Like
Wouldn’t hurt to just swap the connectors between the two ports just to see what happens…
I have a hunch that UART mapping is the root cause.
Do you have the intended GPS1 (moving base) plugged into the port labeled GPS?
If so, and you have the rover GPS plugged into Telem1 or 2 then the GPS’s will swap position.
ArduPilot assigns GPS1 to the one connected to the lowest numbered (GPS connected) SERIALx.
Right now, you have SERIAL1, 2, 3, and 4 all assigned to GPS. Two of those are incorrect, at a minimum.
UART Mapping
- SERIAL0 → USB
- SERIAL1 → UART7 (Telem1) RTS/CTS pins
- SERIAL2 → UART5 (Telem2) RTS/CTS pins
- SERIAL3 → USART1 (GPS1)
- SERIAL4 → UART8 (GPS2)
- SERIAL5 → USART2 (Telem3) RTS/CTS pins
- SERIAL6 → USART3 (USER)
- SERIAL7 → USB (can be used for SLCAN with protocol change)
Unless you have a compelling reason to do differently, I recommend sticking with the ports labeled GPS1 and GPS2. Where possible, the hwdefs usually assign DMA channels appropriately to those for use with moving baseline configurations.
1 Like
Hopefully you’ve gotten things working.
For what it’s worth, I explored the possibility of auto-configuring the SimpleRTK2B+Heading boards from within ArduPilot today. I thought it might be as simple as adding a GPS_DRV_OPTIONS bit and then adding a couple of lines of code to change the UART config to match the config files from ArduSimple, but I quickly discovered that the auto configure routine does not seem to play well with the shared UART1 hardware setup on the Lite board. I do think it’s in the realm of possible, but I do not want to rewrite the mature and rather critical ArduPilot GPS driver. So unless the dev team wishes to tackle it, I’m afraid users will have to continue using the config files and uCenter.
2 Likes
Not working yet. Today I tried setting SERIAL1 and SERIAL2 to mode 5 and the other serials to mode -1 and no luck.
I have pored over the SimpleRTK2B+Heading docs and it seems that the UART which is used to pass the RTK messages from the big board to the small board is the same as the UART which is connected to the Pixhawk. As far as I can tell, the big board sends RTK messages (1207, etc.) on its UART2. See the “Xbee Socket” section of this document here https://www.ardusimple.com/simplertk2b-hookup-guide/ . Then, the small board receives those messages on its UART 1. See the “Bottom XBee Header” section of this document here simpleRTK2Blite hookup guide - ArduSimple However, the Pixhawk’s connection to the small board is also connected to this same UART 1. See the “Pixhawk connector” section of that same document. Hence the UART2 on the big board and the UART 1 on the small board and the Pixhawk Serial (Serial 2->UART 5 in my instance) are all connected together. I have some suspicion that this may be what makes this so finicky.
My testing time is limited next few days so progress will be slow… but I will keep you updated. I’m taking a brute-force approach of swapping out components (ardusimple boards, antennas, pixhawks, etc.) to identify which component is the source of the different behavior between my working mower and my not-working mower.
Again, I think it may be just a matter of swapping the two connections. See my post regarding serial mapping and GPS numbering above.
You are absolutely correct about this specific SimpleRTK arrangement’s “finickiness.” I’m all too familiar with it, and I do not use it for that reason. The design is somewhat clever, but I wish they’d put a set of jumpers on the larger board to make the XBee UART headers (physically) more configurable/flexible.
Dear Highly,
My configuration works just like you have explained, GPS2 is showing RTK fixed in u-center. When I connect my Ardupilot as well (with my GNSS heading module) on USB port, the rover, GPS2 after 1-2 minutes the signal precision decreases from RTK Fixed to 3D dgps.
Have this issue occured to you?
I am using SimpleRTK2B + Lite heading kit in a moving base configuration.