Open kylecarbon opened 5 years ago
Hi @kylecarbon, sorry for the late reply; I just saw the notification for this issue had been buried in my mailbox.
I've wondered for a while what the best strategy is for handling these core ROS tools which are considered separate from the ROS client libraries. The ROS community throws everything even remotely independent in its own repository but that doesn't seem appropriate for the Julia community where registered ROS packages would sit at the same level as something like Plots.jl
.
Given the large number of ROS packages/tools out there, I think it would be best for now if a Julia interface to rosbag
was in a rosbag.jl
repo somewhere. I'm open to ideas of how ROS-related stuff could be consolidated into RobotOS.jl
though without bringing in the entire ecosystem.
Of all packages to integrate with RobotOS.jl
, I feel like rosbags
would be one to do so? Although I'm also fine with a separate rosbag.jl
:)
I can't say I have clear ideas on how to consolidate other ROS-related tools, besides possibly a ROS.jl
Github group? That way, at least it'd be easier to find all ROS-related tools and you wouldn't have to bring anything else into RobotOS.jl
?
I just discovered the RobotOSData package was registered a few months ago with what looks like a goal of exactly providing an API for getting data out of ROS bags. It may be worthwhile to see how the two packages could be functionality integrated.
Opened RobotOSData.jl#1 to start a conversation on possibly integrating the bag messages with RobotOS
auto-generated types.
Any chance you have plans to support
rosbag
? I could take a first stab at it too if you have preferences for the C vs. Python API, how it's integrated intoRobotOS.jl
, etc.