Discussion:
[FOSS-GPS] RTKLib fixed baseline length
Marco Mendonça
9 years ago
Permalink
Hi all,

I'm having some issues processing an RTK baseline with the fixed baseline
length feature. I can't get anything close to a reasonable solution. Are
there any other settings that I have to change along with this to make it
work?

Thanks!

- Marco Mendonça
a***@googlemail.com
9 years ago
Permalink
Selecting moving base mode works for me. But I have not tried fixing baseline length recently. Regards Anthony

Sent from my HTC

----- Reply message -----
From: "Marco Mendonça" <***@gmail.com>
To: <foss-***@lists.osgeo.org>
Subject: [FOSS-GPS] RTKLib fixed baseline length
Date: Sat, Apr 2, 2016 20:13

Hi all,
I'm having some issues processing an RTK baseline with the fixed baseline length feature. I can't get anything close to a reasonable solution. Are there any other settings that I have to change along with this to make it work?

Thanks! 
- Marco Mendonça
David Kelley
9 years ago
Permalink
Marco :
Works fine for me as well.
There are no "special" switches, does it first work for you when
stationary? Start with getting that to work as a first step.

If you have it working in the mode "Kinematic" (ie normal moving rover
RTK) or "Static" (ie stationary RTK where measurement noise is taken out
in dithering the clock estimate more than the position), then
"Moving-Base" should work as well. I presume you know the reason for
using this mode is often to get a precise estimate of the rovers heading.

Here is an image of it working in that mode on short 130cm baseline.
You can see that the two antenna are nearly, not not 100% located N-S
with respect to each other. The ~0.1 degree shift is because the West
side of office building does not run a true north-south! Feel free to
connect to the SNIP NTRIP casters that are listed on the image below to
confirm everything else is working. [No user id is needed, and
Serv2.itsware.net:2101 is left up during the weekend. Not guarantees
during the US work week as that is used a testing machine.]



Good luck!
Regards, DC Kelley
...
Marco Mendonça
9 years ago
Permalink
Thanks, David!

I'm actually trying to post process two RINEX files on rtkpost from
antennas on a car. I chose the moving baseline option, set the baseline
length, but still, no solution.

When not setting the baseline length as fixed, it works fine. Although the
estimated baseline is close to the real value, I'd like it to be fixed.

I'm also using moving baseline. With the length constraint, the results are
noisy and only with 1.07% fixed epochs. Without the constraint, the fixed
epochs are around 90% and much smoother and coherent. And I'm absolutely
sure about the distance from antenna to antenna.

Also, thanks for the example provided! I'll connect there and try to debug
my option choices. Any other guesses of what might be happening are greatly
appreciated!

Regards,

Marco


Date: Sat, 2 Apr 2016 15:09:23 -0700
...
- Marco Mendonça
David Kelley
9 years ago
Permalink
Well, hummm..
Post the two files if you can for others to tinker with. Recall that
RTCM 1004 will not carry the Doppler that you might have originally had
(so it may not be present in your RINEX files if that is what was
converted), so you might be better of post processing with raw data (or
MSM type RTCM if you get it). Doppler is very useful here, esp with L1
only. I have not used the baseline constraint in RTKLIB, so can not
comment on its use or value here, would have to dig into the actual
code. In any event, with the moving baseline method expect to see
noticeable loses the positional estimate reported, in favor of a better
estimate or the yaw and pitch. [you can see that with the two reference
stations I pointed you to, in static you will see <5mm variation] This
method is at its best for a ship or plane. If your antenna are set are
too close ( say~<50 cm), or they interfere with each other (due to the
down convert local oscillator crosstalk between identical GNSS devices),
other issues will of course arise. Just some quick guesses.
Good luck, regards DCKelley
...
--
--
Regards,
David Kelley
ITS Programs Manager, SubCarrier Systems Corp. (SCSC)
626-485-7528 (Cell) 626-513-7715 (Office) 888-950-8747 (Main)
swanta2002
7 years ago
Permalink
Hi Marco & Kelly,

I am new here, and I am presently working on the moving baseline concept
with the RTKLIB software. I am aware that the solution should be a circle
with a radius the length of the distance separating any two receivers. The
result I got is far from being a circle, it is just the shape of my
trajectory (rectangle), very low fix (1.8%), divergent lines and numerous
spikes.

I read where you guys said it works for you, did you get a circle as
expected? and could you please intimate me on what to do to easily resolve
this problem? I am really in a fix and need help concerning this.



--
Sent from: http://open-source-gps-related-discussion-and-support.1099874.n2.nabble.com/
_______________________________________________
This message is sent to you from FOSS-***@lists.osgeo.org mailing list.
Visit https://lists.osgeo.org/mailman/listinfo/foss-gps to manage your subscription
For more in
Anthony Wooldridge
7 years ago
Permalink
Hi, RTKlib outputs the moving antenna position, not the polar vector from the base station, whether fixed base or moving.
However that vector is calculated somewhere in the software and is used in the graphical output of rtknavi. It would not take much programming change to output that vector, typically heading angle is the most useful from a moving base system. However the moving base solution is never as good as from a good fixed base, with sound physical reason, as there is less information to provide a solution.
A better way would be two fixed based solutions (2 rovers sharing one base) and manually extract the polar vector from the two solutions if that is what you need.
Regards Anthony

⁣Sent from TypeApp ​
...
swanta2002
7 years ago
Permalink
Hi,
Thanks for your contribution. The last paragraph of your reply explains
exactly what i am doing. I have 3 receivers, one is considered the base and
the other two making refetence to it. Like u said, i should extract d polar
vector from d two solutions manually. That is what i want and i guess it
should be a circle but, it is not giving me a circle.

Any idea on how to extract it manually please? Ll be glad to 've an insight
from you.



--
Sent from: http://open-source-gps-related-discussion-and-support.1099874.n2.nabble.com/
_______________________________________________
This message is sent to you from FOSS-***@lists.osgeo.org mailing list.
Visit https://lists.osgeo.org/mailman/listinfo/foss-gps to manage your subscription
For more information, check http://wiki.osgeo.org/wiki/FOS

Felipe G. Nievinski
9 years ago
Permalink
How large is the difference between estimated baseline length and its
assumed value? I presumed it's been measured with a tape, between antennas
reference points (not the antenna phase centers)? Also, make sure you're
configuring the antenna models correctly in RTKLIB settings.
-FGN.
Marco Mendonça
9 years ago
Permalink
In average, without the constraint, they agree at a 5mm level with a
standard deviation of 3 cm. It is a pretty reasonable solution given the
dynamics, but I'd like this noise to be propagated to the other parameters
being estimated, where they actually belong.

The antennas are experimental, so I don't have the antenna type or the
phase centers, but they are both exactly the same, with the same
orientation, so I think this effect is not the one to blame. And the
baseline measurement was made with a caliper, down to the millimeter
between the antenna mounts.

If I can't figure this out, I'll keep with the unconstrained solution. Not
a big deal, but also not the ideal solution.

Thank you very much for the help Mr. Kelley and Dr. Nievinski!


- Marco Mendonça
...
Loading...