Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WIP: GPS Simulator #45

Open
wants to merge 19 commits into
base: master
Choose a base branch
from
Open

WIP: GPS Simulator #45

wants to merge 19 commits into from

Conversation

michaelpantic
Copy link
Member

@michaelpantic michaelpantic commented Feb 17, 2021

To keep track of this:

  • Figure out and implement noise characteristics that can mimic the type of noise we can expect with GPS
  • Tune white/pink/brown noise value to somewhat mimic float/fix/ppk (one config each)
  • write python node that, depending on time, location or service call changes between float/fix/ppk/no-data
  • Profit

Added python dependencies so far:
colorednoise
geomag

Even if its badly tuned, this type of noise generation gives a much more diverse and realistic noise than just adding gaussian noise - which should make tuning our GPS solution more feasible in vicon.

Example of the different noises:
all X-Y plots seen from above, time is encoded by color. Plot shows deviation against true position (0/0/0).
Here its simulated over 1000 samples (100secs) and the noises are rather large. Maybe we need to make the epsilon for brown noise even smaller, to make it slower.

Brown mimics the slower components (constellation/bias/ionospheric dependent noises)
brown_only

White noise is simply additive gaussian noise (mimics all the fast, non-time correlated noise):
white_noise

Pink is somwhere in between.
pink_only

Combined effect (some example tuning):
combined

@michaelpantic
Copy link
Member Author

@rikba @alexmillane @clanegge @tkazik If you have bags that have recordings of the different type of fixes and are stationary (i.e. somewhat known position): Please let me know - then we can use them to tune the noise characteristics. Thanks!

@clanegge
Copy link
Contributor

clanegge commented Feb 17, 2021

@michaelpantic Quite few of the bags from the arche dataset have bags where we switch between fix/float (and sometimes even normal gps). They should be at the lab on a ssd otherwise @alexmillane has them. They could be quite useful for this!

@michaelpantic
Copy link
Member Author

Update: We went out and collected data for tuning.
Tuned it for RTK & SPP, results are really good. Shows that GPS is nothing like gaussian noise at all!!

RTK has a bit of white noise and some pink noise, whereas under SPP there's a load of brown noise and about same amount of white noise as in RTK.

Color code is time - actually color doesn't matter, more the distributions of colors.

Results SPP

Power noise distribution

power_spec_SPP

XY ENU Plot Real Data

enu_xy_SPP_real

XY ENU Plot Simulated Data

enu_xy_SPP_sim

Results RTK

Power noise distribution

power_spec_RTK

XY ENU Plot Real Data

enu_xy_RTK_real

XY ENU Plot Simulated Data

enu_xy_RTK_sim

Next step: Cleanup and push, and invent some tuning in-between for float, which can be anything.
Then it should be ready to properly simulate GPS in Vicon!
FYI @alexmillane @clanegge @rikba @tkazik

@michaelpantic
Copy link
Member Author

Added some imagined config for FLOAT for now:
(no data currently)
enu_xy_FLOAT_sim

for i in range(0, 3):
self._sample_buffer[:, i] = cn.powerlaw_psd_gaussian(self._epsilons[0], n) # white
self._sample_buffer[:, i + 3] = cn.powerlaw_psd_gaussian(self._epsilons[1], n) # pink
self._sample_buffer[:, i + 6] = cn.powerlaw_psd_gaussian(self._epsilons[2], n, 0.001) # brown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's this last number here? Might be worth naming this constant?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or use the argument name

Copy link
Member Author

@michaelpantic michaelpantic Feb 19, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍


output_mag = self.get_mag(input_pose[0:3, 0:3])

# weird pythonic flex that these variables are found

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lol yeah...

self.gps_sim = GpsSimulator()
rospy.Subscriber("/HeadHelmety/vrpn_client/estimated_odometry", Odometry, self.odom_callback)

def odom_callback(self, data):

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we throttle the rate anywhere?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yep now it does

@alexmillane
Copy link

@michaelpantic Thanks for this bro. I'll give it a test this afternoon.

@michaelpantic
Copy link
Member Author

@alexmillane thanks for the quick review!

I'll fix the comments, add throttling and a service call to change modes in the next hour or so.

@michaelpantic
Copy link
Member Author

@alexmillane should be ready-ish now for use.

subscribes to:

  • odometry from vicon or similar

outputs:

  • odometry with covariance (according to dataset)
  • magnetometer

to configure:

  • has a dynamic reconfigure interface to change modes. Currently supported are rtk, float, spp, none

Things to watch out for:

  • Odometry output message does not populate any of the orientation specific parts. Rovio is usually set to ignore those anyways, but we should double check it doesn't cause any undefined behaviour
  • I need to double check the covariance matrix population too
  • Mag data untested -> rotation could be inverted

@michaelpantic
Copy link
Member Author

@alexmillane added a transformstamped output, in case we want to use the transformstamped input of rovio to reproduce old behaviour

@tkazik
Copy link

tkazik commented Feb 19, 2021

I recently came across this very impressive thesis. Especially chapter 3.5 GPS Observable Errors has plenty if interesting stuff (but might very well be an overkill). Also from that thesis, a lovely overview on colored noise:
colored_noise_overview

@michaelpantic
Copy link
Member Author

I recently came across this very impressive thesis. Especially chapter 3.5 GPS Observable Errors has plenty if interesting stuff (but might very well be an overkill). Also from that thesis, a lovely overview on colored noise:

wow thanks for that link. Tons of information and nice noise overview :-)
They model the noise for each stage in the GPS position estimate individually, pretty cool! But yes, in our case that would probably be overkill :-D

One thing I also wondered about: Given that there's is power-law noise and not gaussian per se, how do you put that into a proper filter? (if one were to build one).
This seems interesting: https://arxiv.org/abs/cond-mat/0004369

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants