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

Feature/message logger #174

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

Feature/message logger #174

wants to merge 21 commits into from

Conversation

clanegge
Copy link
Contributor

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 added 2 commits June 4, 2020 15:46
New base class was set up handling the listener subscriptions to message callbacks.  Object can inherit from this class and set up callbacks for any group of SBP Message (observation, emphemeris, ...) .
@clanegge clanegge requested review from michaelpantic and rikba June 12, 2020 08:59
@rikba
Copy link
Collaborator

rikba commented Jun 12, 2020

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.

@clanegge
Copy link
Contributor Author

clanegge commented Jun 12, 2020

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).

@michaelpantic
Copy link
Member

michaelpantic commented Jun 12, 2020

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
Copy link
Member

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

@rikba
Copy link
Collaborator

rikba commented Jun 12, 2020

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

@clanegge
Copy link
Contributor Author

Cheers! Will continue working on it then!

@michaelpantic
Copy link
Member

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 :-)

clanegge and others added 12 commits June 12, 2020 23:53
Adds 3 lambda functions. Corresponding methods have been added to cb_to_raw_obs_converter as well.
Wrong message type was copy pasted to sbp_send_message method
- File logger is initialized in own method if in launch file logging is set to true.
- Per default logger is off. Default binary directory is: /tmp/tmp_observations.sbp
- Sender id was moved down to receiver_ros, so that every receiver stores its own ID, and not only the base station (sender id is needed for logging)
Changed back class names to "observation". Ephemeris can also be considered an observation
Also added prefix to observation file with the type of receiver, hopefully this allows to store observations from multiple connected receivers into different files.
Can start and stop logger for attitude and position receiver independently. If a custom name is set, the file is not overwritten when logging restarted but rather a number is added as appendix preventing accidental loss of observation files.
@clanegge clanegge marked this pull request as ready for review September 14, 2020 13:09
@clanegge clanegge requested a review from rikba September 14, 2020 13:10
@clanegge
Copy link
Contributor Author

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.

Copy link
Contributor Author

@clanegge clanegge left a comment

Choose a reason for hiding this comment

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

@rikba
I had a look at the last changes & it LGTM. I think we tested this quite thoroughly and it should be ready to merge.

@clanegge clanegge mentioned this pull request Jul 7, 2021
@marco-tranzatto marco-tranzatto removed their request for review February 27, 2023 12:24
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