-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Consider promoting rs2_lcm::camera_description_t to drake lcmtypes #9801
Comments
I'm fine with promoting it to RobotLocomotion/lcmtypes. |
Per Slack discussion, these types do not seem to require any Drake-specific LCM types, so it'd be nice to put them a little more upstream, so I'd agree thta If we think LCM is worth the time investment, we should try to make a better set of standard messages. |
Are there particular issues with the existing message types which we should consider correcting before moving into a common repo? I think changing out the encoding and transport layers (to say the least!) is perhaps beyond the scope of this issue unless the existing defects are particularly bad. |
The only thing I've noted is that most of RobotLocomotion/lcmtypes use a common header_t. You should probably add the header, when moving the messages into the RLG repository? |
I think the messages using |
I was not proposing any changes to the type, only relocating it's definition. The standard argument to strongly disprefer changing the type is that one can no-longer playback old log files using the types on master. Perhaps in this particular case, we don't have log files that we value for the camera description? But if we do, then I would recommend to move the type without adopting a new header. |
@kmuhlrad -- can you update me on what you consider to be the current status of the camera config in manip station? (do we still need a better way to configure it?) |
Right now the cameras are still added in the C++ via hardcoded transforms. I'm still using the custom config files for Python stuff, which repeats some of that information. No cameras exist in any .sdf files (although that makes less sense for the clutter clearing demo than for the class setup). Deciding a common format for configuring the cameras would be good. |
Are y'all using ManipulationStation at all in C++? If not, consider just adding the cameras through Python, which is rich enough language that you don't really need a config file? (just sugar functions, like |
All of my uses are in Python. I think the point of the config files is to make sure that values aren't being repeated in multiple places. For example, I need access to the camera pose when doing downstream point cloud processing so I can put the point cloud in world frame, which shouldn't live in ManipulationStation. |
Hm... What is the point cloud processing written in? How are these things coordinated? I'm pretty sure that this can be resolved with either functions or middleware comms, without slowing down app evolution by upstreaming app code to libraries prematurely. To put on my hacker / engineering hat: I'd only be fine (and only marginally so) with config files in (The config files will ultimately be very application specific to start, and as such should live near the application so they can change quickly without getting in the way.) |
All the processing I'm doing is in Python. Here's a slightly outdated version of the system: https://github.com/RobotLocomotion/6-881-examples/blob/master/perception/point_cloud_to_pose_system.py. Now that PointClouds support RGB, the RGB images would be connected elsewhere. The entire flow is in https://github.com/RobotLocomotion/6-881-examples/blob/master/perception/run_perception_system.py#L106. The config files I'm using just have the same camera poses as the C++, but changing one does not affect the other. This discussion seems to be related to #10127 |
Ah, yeah, that discussion is very relevant. I was about to re-type the same response :) We really should start modularizing Truly, there should be a free function in I would love to help with this, but unfortunately have other things on my plate at the moment :(
Meep! That means brittle duplication! At this point, I would suggest one of the following:
|
It took me a while to figure out what this was referring to. I think the referent is https://github.com/RobotLocomotion/realsense2-lcm-driver/blob/master/lcmtypes/camera_description_t.lcm. I'm not sure why we need to copy the file in order to refer to it from Drake? We could add it as an external. |
For the record... use of RobotLocotiomotion/lcmtypes by Drake is deprecated now. We should not add new items to it. |
I haven't needed this recently and don't currently intend to fix it. |
the realsense driver publishes it. if we want to consume it from drake, it probably needs to be promoted. any objections? cc @sammy-tri ? @EricCousineau-TRI ?
The text was updated successfully, but these errors were encountered: