Relative Position Invalid

Q&A forumCategory: QuestionsRelative Position Invalid
Kyle Waremburg asked 1 month ago
3 Answers
Kyle Waremburg answered 1 month ago

Hi,
I’m running dual simpleRTK2B V1 to achieve an accurate heading / relative position with moving base.  I have a third acting as a stationary base station.

From time to time I see the relative position valid and heading valid drop to 0.  During this time the carrier phase solution continues to report Fix.  I assumed that if I had an RTK fix between the 2 boards that the position would always be valid.  Is this not the case?  What else is required to achieve a valid relative position.

These dropouts occur once every minute.

Generally power cycling the receiver clears up the issue.

19
GNSS Fix: True
DIFF Soln: True
Rel Pos Valid: False
Carr Soln: Fixed
Is Moving: False
Ref Pos Miss: False
Ref Obs Miss: False
Rel Pos Heading Valid: False
Rel Pos Normalized: False
279
GNSS Fix: True
DIFF Soln: True
Rel Pos Valid: True
Carr Soln: Fixed
Is Moving: False
Ref Pos Miss: False
Ref Obs Miss: False
Rel Pos Heading Valid: True
Rel Pos Normalized: False



Thanks,

Kyle

Kyle Waremburg answered 1 month ago
Kyle Waremburg replied 1 month ago

I’m not sure why but my images aren’t posting…

Kyle Waremburg replied 1 month ago

I was hoping to illustrate this with plots but given attaching an image isn’t an option I try to explain more.

Once every 60 seconds the relposned flags changes from 279 to 19 for 4 samples. The data is at 5hz.

clive1 replied 1 month ago

You’ll need to post images to your own server/resources, and then link to them.
What version of firmware is running on the units?
What baud rate is the data link between the two units?
Which messages? Any UBX-RXM-RTCM log for the Moving Base Rover contemporaneous with the UBX-NAV-RELPOSNED reporting?
Top-Of-Minute? or some random second within the minute?

Kyle Waremburg replied 1 month ago

https://drive.google.com/file/d/1c_E5KwT0sv4ujJcZGQRngaMF6Rmu7WEL/view?usp=sharing

I have, navpvt, navrelposned, navsat, and navstatus msgs logged.

FW: 113 (UBX_F9_100_HPG_113_ZED_F9P.7e6e899c5597acddf2f5f2f70fdf5fbe.bin)
Baud between the moving base and the rover is 115200

I’m using the configs from the Ardusimple Site. All I did was tweak the ports because I’m not using a heading kit.

It happens from second 8 to 9 according to the sec reported in navpvt.

clive1 replied 1 month ago

I’ll perhaps look at the double stacked devices here later, pretty sure we’re not seeing rhythmic data/solution loss here at 5 or 8 Hz, but not using config scripts.

Check also UBX-MON-TXBUF on the Moving Base Reference side, incase there is some buffering issue, and an output interface that’s not sinking data fast enough. This could perhaps cause inter-modulation, and data loss, MB is pretty intolerant to latency/data loss issues.

If you’re just bonding the UART2 channels 460800 baud would drop the latency there, watch however for UART1 choking with data.

Kyle Waremburg replied 1 month ago

I have a short (6 inch) wire between the boards connecting the UARTS. I can attempt to increase the baud rate later today.

Can you help me understand what additional conditions have to be met to go from RTK Fix to valid position?

clive1 replied 1 month ago

No, not really.

The underlying maths/geometry has to work, and the data from the last epoch needs to arrive within 700ms. If you’re not getting data, that’s probably the first thing to check/verify. I don’t think uBlox provides a check-list.

Kyle Waremburg replied 1 month ago

Okay, this problem has occurred 3 times over the last month. We haven’t been able to reproduce it reliably. When it does occur the operators just power cycle.

How do I verify if I’m getting data or not during those periods? We are connected to a linux machine running ROS. I’m not sure how to easily connect it to U Center for interrogation. Or am I overcomplicating this?

clive1 replied 1 month ago

Well the orbits of the satellite and other factors can change the amount of data coming out of the receiver. If the bandwidth is close to limitations additional satellites during brief periods can cause issues that come/go. Look for other outputs to stall, or not report certain messages.
You want to be looking at the data stream for “$GxTXT txbuf alloc” type warnings, GREP your logged data for “txbuf alloc”, as this is a big red flags that you’re overloading one of the interfaces, and will cause some data loss on ALL of them.
Enable/log UBX-MON-TXBUF on the Moving Base Reference
Enable/log UBX-RXM-RTCM, UBX-MON-IO on the Moving Base Rover

115200 baud is not adequate for 5 Hz operation with NMEA/UBX data, basically gives you a 230 byte budget per epoch. Configure the UARTs at 460,800 baud and cull any messages you don’t need/use. Turn off or disable unused interfaces.

>>Or am I overcomplicating this?
I don’t know, you don’t need to run uCenter, although it might help to probe the issue real time when it occurs. What you do need to do is log sufficient data that you can do a post failure analysis to understand what happened, or see if there are any conditions common to the times when it fails.

Kyle Waremburg answered 1 month ago