Ulog2mcap - seeking feedback

Hi!

I presented this work during the PX4 Meetup in Belgium and want to push this to completion, so I thought I would seek feedback from the community before proceeding.

Background: at Foxglove, we came up with open-source multimodal format called MCAP that’s now a default rosbag format for ROS users. The format is quite flexible and optimized for multimodal data.

Here is the fork of pyulog I’m working on (together with my friend Cursor). I’m yet to clean it up but thought I would seek some early feedback:

  1. Foxglove expects ENU frames; following some ROS conventions, I created a simple tree of local_origin->base_intermediate->base_link, where local_origin to base_intermediate is an XYZ transform and base_intermediate to base_link adds a rotation
  2. I noticed sometimes log time starts at epoch start, so I try to be smart about it and use gps time to offset the relative time
  3. Not wanting to make pyulog depend on ROS, I used Foxglove message schemas and derived some messages so they can be rendered nicely in Foxglove. This would likely make these derived messages not work with standard ROS tools. Would that be acceptable, or should we rely fully on ROS and try to match MAVROS messages as closely as possible?
  4. Any value in parsing additional information that can be output in the table similar to what you can see in PX4 Flight Review
  5. I notice there is usually some ‘dead time’ in the logs where no sensor data, etc. is published. Any issues with removing this offset? I recognize this might be an issue in my converter; I will double-check this soon

Here is the video I recorded showing the visualization of a converted log file:

Pretty cool @msadowski thanks for sharing!

I must say - I looked over this briefly, so I can’t give you proper feedback.

I do want to mention that it seems like your fork is behind PX4/pyulog and it has a rather new feature of converting to rosbags (ulog2ros2bag). This also includes mcap conversion (missing from the readme, see this block. I guess you could see where you can add on top of that.

I also wonder if Foxglove is thinking on “retiring” your px4_converter.

There’s no doubt that viewing flight control logs together with ROS2 logs is beneficial.

@dotanAtTrim thanks for the feedback! Indeed, should have pulled the main first after so many months since I started looking into this.

Since the mcap output is already there, I don’t think there is a point to add a competing implementation and will indeed make a PR to add to it.

What do you think about the following?

  1. What do you think about deriving messages from the context? For example, TF, flight path
  2. Any thoughts on parsing the log time from gps time if proper time is not available when the log starts?

I would keep the px4_converter, as IMO it serves another purpose (loading ulog locally without having to jump through hoops), while the export to MCAP is geared towards indexing and storing all your data long-term.

Contributions are always welcome @msadowski, and by the way I also wasn’t aware of the ulog2ros2bag converter :joy: