ethz-asl / mav_rtk_gps Goto Github PK

Piksi can be reset by sending a MSG_RESET with code 0x00B6 (lib SBP 2.2.1).
An example how to do that can be found in piksi users forum, where the code of the message must be adapted to our current library version.

To improve robustness, the rosservice should not be an "empty service", which can be called by mistake. Probably a SetBool service is good enough: if the request contains "True", then the driver should reset Piksi.

@kholtmann what do you think about it?

See https://github.com/swift-nav/libsbp/releases/tag/v2.2.1

@kholtmann especially interesting is the the feature in V2.0.0:

Addition of Age of corrections message. This will go out with every solution epoch to indicate correction age

This could probably address the issue you saw in Piombino when there were huge network delays.

Waiting for a reply in swift-nav/libsbp#472 or in Piksi Forum.

Hi people!

As the driver is not being used only by the MAV team I would like at this point to split the init_rovio part and the actual ROS driver in separate repositories (while keeping GIT history). When I asked to create this repo a didn't think about this possibility. I will then take care of updating the Wikis in a more readable way.

@helenol If you're ok with this I'd ask you to create a new repo: ethz_piksi_ros

Thanks,
Marco.

@helenol @rikba @fmina
Hi Team,

I'd like to open source this package for the special issue of MBZIRC.
Today I updated the documentation and cleaned up some parts a little bit.
Would you mind having a quick look at it and maybe tell me what you think?
I'm not totally sure it's already "good enough" to be open sourced ...

Thanks a lot! :D

Put here images used in wiki pages

SBP library in usage is the one located in /usr/local/lib/python2.7/dist-packages/, and not the one installed in ~/Software/ folder. Switching back and forth from Piksi V2 to Multi can be annoying, since you manually need to remove the SBP folder that you don't want.

At the moment messages time stamps are filled with ros::Time::now(), see navsatfix message.

We should investigate a better way to estimate time delay between ROS driver and when the measurement was actually received.