Regarding offsets, I was very precise in measuring them. My thinking is for sub cm accuracy, is that I need to apply the same accuracy to my offsets.
It appears you have the moving base and rover connected in the reverse order of the usual method. The moving base is usually connected to the port with the lower number.
Depending the order of the GPS_TYPE* parameters, this could be affecting RTCM3 injection to the moving base.
Also, since you’re using u-Center to configure your modules, ensure that RTCM3 is an available protocol on the input side of UART1 for both modules.
GPS_POS parameters should be measured with respect to the center of the vehicle (specifically, the point about which it rotates when it turns).
Yes, you are right. I shouldn’t measure based on my eyes because other things are not measured like that, either.
What did you do to measure your offset precisely?
Wait, reverse order?
SimpleRTK2B (big board) acts as the moving base, right? It is connected to Telem1.
SimpleRTK2BLite (small board) acts as the moving rover, right? It is connected to Telem2.
So the moving base is connected to the port with the lower number, as far as I’m concerned.
I did it as told in the ArduSimple tutorial
Do I miss something?
Alright, I will check RTCM3 in the u-center, thank you for that!
If that’s the case, then GPS1 is receiving NTRIP corrections from the fixed base station, and GPS2 is not providing any useful yaw information.
It may help to display the value for gps2yaw in the Quick tab in Mission Planner to determine its validity.
I suspect at this point that either your GPS_POS parameters are poorly measured and/or that the interference from obstacles in your testing area is impacting your results.
A good ruler and perhaps a plumb line…
1 Like
Oh, yeah, I noticed that GPS2_YAW was constantly UINT16_MAX, so 65536, which means “configured to provide yaw and is currently unable to provide it”.
I thought every GPS_POS param should be related to the Pixhawk, so I took it as the reference point. I think GPS_POS1_X is corect, because I have measured the distance between the antennas from center to center, multiple times, and that didn’t change.
I also saw that Pixhawk should be placed in the vehicle’s center-of-gravity, but the vehicle is not assembled like that.
So the antennas are placed at the front and the back of the rover, so that makes them 93 centimeters of difference on the X axis which I tell to the Ardurover by setting GPS_POS1_X to 0.93. In the Y there is no difference, they are aligned, so I think the GPS_POS1_Z could cause issues…
Should we calculate the center of gravity of the vehicle somehow?
No need to calculate CoG.
Your reference point for both INS and GPS offsets is as I described above. As long as the GPS_POS distance is accurate to within a cm or two, yaw should be calculated if possible.
To achieve best performance overall, the offsets should be accurate and precise as I described previously.
Your rover GPS is either not receiving RTCM3 from the moving base or it is unable to achieve an RTK fix due to poor signal.
Yeah, I should definitely check RTCM3 and why GPS2’s yaw is 65536…it is still an issue.
I received rtk Fixed actually as you can see from the Mission Planner screenshot I made today, outside. But the rtk Fixed was on for a few seconds, and then again rtk Float or even worse. Yeah, the environment was surrounded by building blocks…
This is probably the root cause at this point.
Also, for the Z reference, you could use antenna height above ground, though unless the antennas are at differing heights (or you have a very tall vehicle), Z offset is largely irrelevant.
Okay, we are getting somewhere.
The antennas are same in height. I am not sure about the rover’s height but it is definitely between 60-80 centimeters. If that is okay, I will set GPS_POS1_Z according to that.
So I should fix the RTCM3 communication between moving base and moving rover.
Thank you very much, Yuri, this stuff is getting clearer and clear, because I can talk about my approach and compare it with the pro approach, which would be you in this case.
Sorry if I ask too much or too stupid questions, I am just really trying to get this work as expected. It doesn’t help either that we have a deadline, I have to make it work as soon as possible.
To be as clear as possible:
RTCM3 between the fixed base and moving base is separate and distinct from RTCM3 between the moving base and rover.
You DO NOT need to send external (NTRIP/CORS) corrections to the moving base for the moving baseline configuration to work properly and achieve a yaw solution.
Too many users confuse the two and think that external corrections are required for yaw. They are not.
For optimum absolute positioning performance, it’s good to have a fixed base/NTRIP/CORS source, but relative positioning between the onboard GPS modules is still possible without it.
Alright, yeah, I also explained it to others who asked like that so the yaw-pitch-roll comes from moving rover (heading, front antenna connected to small 2BLite) relative position to moving base (which is the antenna at the back of the vehicle, connected to big 2B)
To conclude: orientation should work without NTRIP (aka fixed base) but positioning would not get RTK Fixed.
Correct.
And in the case where external corrections are not present, GPS1 would have a 3D/DGPS fix, while GPS2 should have an RTK Fixed state (based on GPS1’s correction data).
1 Like
Ohh, I see. This way I can tell/validate whether the Ardupilot is connected to NTRIP (receives external corrections) or not?
If GPS1 has 3D/DGPS fix that means “no NTRIP”, if GPS1 has RTK Fix/Float that means “NTRIP active”, correct?
Currently, according to yesterday’s testing, GPS2 was constantly on 3D DGPS.
I have also received answer about the height of the rover, the antennas are 50 centimeters above ground to be precise. So is that okay if I set GPS_POS1_Z to -0.5 ? Minus is for the upward direction.
I am still thinking about two parameters whether they are set correctly or not.
- GPS_PRIMARY
If the module connected to Telem1 is the moving base, it is considered the first GPS, right? Then why are we setting GPS_PRIMARY to 1 which actually makes the secondary, the rover module primary? I have even set the GPS_TYPE is 17, which means GPS1 (Telem1/SimpleRTK2B/big board, so many labels) should be considered as the moving base indeed and GPS_TYPE2 is 18, which means GPS2 is the rover.
Since moving base connects to NTRIP and receives external corrections, the moving base (the module connected to Telem1, the port with the lower number) should be the primary GPS, right?
I mean this can be the root cause why they are being swapped over in the Mission Planner…
For me setting GPS_PRIMARY to 1 is not very logical this way, although ArduSimple guide tells me to do so.
- GPS_INJECT_TO
This controls which GNSS module will Ardupilot forward RTCM3 messages to, as far as I know.
By default it is set to 127, which means “send corrections to both”, but the RTK injection should be forwarded to the moving base ONLY, isn’t it? Again, this would be better set to 0, so we explicitly say it, that when the Ardupilot receives external corrections, forward it to the first GNSS module, the moving base avoiding it to be forwarded to the rover.
It would be so great to include an explanation for the parameters WHY are we setting these values like this, like for the GPS_POS1_X, it would help a lot to understand how these parameters work.
So my proposal: set GPS_INJECT_TO and GPS_PRIMARY to 0.
What do you think?
I am also thinking about launching the SITL tomorrow and connect the real simpleRTK GNSS modules to that, so we don’t have to walk with the whole physical vehicle, but the GNSS modules only. So I can tinker with these parameters on the roof of the building. Would it work?
I am reading your discussion with much interest also to learn.
So if you in doubt of these settings, why you not just try it. As I see from the full parameter list you have just a view combinatons to try.
As I understood from communication system of the Ardupilot the GPS connected to the lower port is defined 1st GPS while the other is the 2nd GPS.
But from the navigation system of the ardupilot is taking the (corrected) data of the rover GPS. So form navigation point this would be the “primary” and from communication point the 2ndGPS
Also the RTCM3 messages has to go internal from the “base” to the “rover” so from 1st GPS to 2nd GPS
To test this you can disable the NTRIP data.
1 Like
Yes, you are right, I could try the param settings out, but I don’t really have enough time weekly to go out with the vehicle.
Instead of my own method of trying stuff, param settings out, I have to go through the settings in theory, in my head, which would be the best param settings to make this work as they expect from me.
The rover is in the lab, I can’t take my work home, sadly, but the conditions would be much-much better at my place (rural city, without big buildings, glasses, big trees, which is perfect for RTK)
That is why I am thinking theoretically right now, and I also want to understand which param does what exactly inside the ArduRover
My best thought for today was, okay, tomorrow I will connect to my GNSS modules directly, and I will tinker with the param settings with the SITL simulator running. So I have to take out only the GNSS modules. Yeah, that would be cooler.