ethz_piksi_ros icon indicating copy to clipboard operation
ethz_piksi_ros copied to clipboard

Feature/message logger

Open clanegge opened this issue 4 years ago • 8 comments

PR should (at some point) enable to log any type of raw message and store it as an binary file. With this feature the driver would be able record the messages required for PPK as binaries.

Opened PR to discuss the new structure of the observation callback handler.

Proposed changes:

  • Base Class SBPMsgTypeCallbackHandler implementing methods for adding listeners
  • Derived Classes hold objects of SBPLambdaCallbacks for message types for which callback should be set up
  • Multiple listeners can be set up for different groups of message types, so that UDP sender only listens to observations, but logger can set up additional listeners to log additional messages

Coarse Class Diagram of the new structure: piksi_callback_handler

clanegge avatar Jun 12 '20 08:06 clanegge

We could definitely go that route. Then we can use the sbp2rinex pipeline.

A different approach could be to record the necessary ROS topics in a ros bag image and write a python programm to convert to rinex and call swiss topo corrections.

rikba avatar Jun 12 '20 09:06 rikba

We could definitely go that route. Then we can use the sbp2rinex pipeline.

Yeah, that was the idea.

A different approach could be to record the necessary ROS topics in a ros bag

That would also work. A benefit of writing it directly to file is that you don't have to have an extra rosbag running on your basestation if you want to store the messages as well (as redundancy or if swiss topo corrections are not available yet).

clanegge avatar Jun 12 '20 10:06 clanegge

we also thought about the rosbag method - that would be cool too in the future, as you could then just use the rosbag to get PPK. But you'd need to also build a extractor tool (kind of rosbag2sbp2rinex).

Could just be another EphemerisCallbackHandler that sends out ros messages. but depends ont he usecase, I think eventually both are useful :)

michaelpantic avatar Jun 12 '20 10:06 michaelpantic

Btw Thanks for the UML! I think the architecture like that should work!

michaelpantic avatar Jun 12 '20 10:06 michaelpantic

Agree. Your architecture looks great and straight forward to implement. Go for it. Writing rosbag2sbp2rinex is probably more of a hustle.

Could just be another EphemerisCallbackHandler that sends out ros messages.

Just for completion, this already exists. The ros driver relays all sbp messages published by the piksi, e.g., image

rikba avatar Jun 12 '20 10:06 rikba

Cheers! Will continue working on it then!

clanegge avatar Jun 12 '20 10:06 clanegge

Just for completion, this already exists. The ros driver relays all sbp messages published by the piksi,

ah true, sorry completely forgot about this!

So we'd "only" need a ROSbag -> Rinex converter. In case we ever do that, its probably best to go from ros message directly to rinex, but I guess we leave that for the future :-)

michaelpantic avatar Jun 12 '20 12:06 michaelpantic

Something I added towards the end:

  • the log filename is always prefixed with the receiver type, so that multiple connected receivers don't write to the same file
  • The logger can be started/stopped through a service call for any connected receiver independently
  • You can specify a custom log file name. When the logger is stopped and restarted again the file will not get overwritten, but a number will be appended to the file name.

Just tested it with two piksi's, one attitude and one position receiver, and it seemed to work (I was able to log observations from both devices and convert the logged sbp to a .obs and .nav file), incl. stopping and restarting the file logger.

clanegge avatar Sep 14 '20 14:09 clanegge