-
Notifications
You must be signed in to change notification settings - Fork 30
20210304_telecon
I took the notes below during an ad hoc meeting on March 4, 2021. They were not initially intended for public release so they are a best-effort record, with a number of omissions and probably also errors. At Laura Lindzey’s request I’ve made some effort to clean them up so they are at least intelligible, and I’m posting them here so we have some record of what transpired. - Michael McCarrin
Thanks Michael! I took a quick pass through filling in a few things from my notes. --Laura
NB: While this takes the form of a transcript, it is NOT an exact record of what was said. Pretty much everything has been paraphrased.
Laura Lindzey: APL
Kris Krasnosky, Chris Roman: URI
Ben Raanan: MBARI
Tully Foote and Mabel Zhang: Open Robotics
Michael McCarrin, Carson Vogt, Brian Bingham, Woensug-Choi: NPS
Laura: (To Tully) What does it look for a project to go through standardization of messages? How does a community go from everyone using their own message definitions to having a default set?
Tully:
Get critical mass.
Early in the life--go fast and break things, be willing to iterate quickly.
With every new user, make sure it covers their use cases. You'll have a natural tailing off as you get enough use cases to make sure it works works for everybody.
Starts off as a non-official thing. People know it's early and they will have to keep up. Make sure maintainers are committed to being clear about communication to the community. Otherwise it will fragment.
Then, once it's stable, a message-only package can be added to common_msgs as a dependency.
It is easy to just write your own messages. It's better to also have 3-4 processing libraries that work well with them. If you build the input-output processing that uses the message, it's much more useful and encourages adoption. The code reuse part is what makes it valuable.
For example, "here's a message definition and corresponding Gazebo plugin". Also, if everyone is using these plugins you can update a little more easily; just have to update a few central plugins.
A lot of the "leadership" is brute force initiative. Most important thing is an end-to-end demo, since that makes it hard for people to not user your messages.
Laura: tysm. Follow up questions?
Ben Raanan: Dave Caress at MBARI works on mbsystem, which is a framework for processing multibeam sonar, and has seen all use cases. Don't think there's a sonar message type he doesn't support. Did what Tully was describing back in the 90s. Would be a good person to ask for a list of use cases. Will have a lot of insight into what the general purpose message should contain.
Tully: I'll suggest when you look at messaging, think about the physical ramifications of things, semantics of what’s being communicated, rather than the most popular hardware.
Brian: Hard for us in our community. Difficult to get to a common understanding of what a general multibeam is. Having something similar to an IMU message or more semantically higher-level is something that we've struggled to get right.
Tully: Ideally you want downstream processing to be unaware of what sensor produced the message.
Brian: I have a question. Some of these things are multi-purpose sensors. Sometimes we don’t have 1-1 sensor to message correspondence. The DVL emits several messages. Does that create any problems?
Tully: That's good. You want semantically meaningful interfaces. [Gave example of another sensor where they are doing this.]
Ben: For DVLs, there are standard message types defined by manufacturers. Have you guys considered emulating these to some degree in ROS?
Tully: No, I have not.
Laura: The DVL message that the current repo proposes is based heavily on Ian Vaughn's at WHOI. The approach they took is to publish both a standardized Dvl.msg as well as device-specific messages with fields that map one-to-one to fields in the instrument's datagram. (e.g. PD0, PD6)
Brian: Not terribly happy with that way of doing things: some instrument specificity, but also tries to be higher level, so it's in the middle.
Separate point: writing tutorials is also really good for adoption. In addition to the demo, this is helpful.
Tully: I agree. And this helps you find the pain points and fix them to write the code/API to make the writing easier.
Chris Roman: Two things before I have to sign off:
If you can become the path of least resistance you'll succeed.
A lot of the sensors have users set parameters like threshold value. You really want whatever is going into the rosbag to contain everything you need later to figure out what happened, so you need some way to record what these settings were.
Tully: If it's inherent to interpreting the data it should probably be embedded in the message. Min/max range, for example. Doesn't change and bloats the message.
Ben: This is going to complicate things significantly. No two manufacturers use the same format. Some have hundreds of fields. You should probably just log the binary data in that case.
So, Laura, you will need to define the scope. Getting everything will be tedious work, and maintaining will be a full time job.
Kris: 1-1 Norbit message in ROS. We log that along with a naive projection point cloud. Also would like to log a standard multibeam message, whatever that ends up being. Things in the Norbit could be published as a separate topic. Not sure this belongs in the message.
Tully: If it's critical to interpret the data, it needs to be in the message. Optimal would be [lost this]... End up with a per-sensor implementation data.
Laura: A problem with these acoustic messages is that all manufacturers have somewhat different capabilities. The definition of what is critical is also sensor specific.
Ben: What are the use cases you have in mind for this message, Laura?
Laura: Kris should give the list; he is more actively using multibeam messages right not.
Kris: Need projection. Movement of vehicle between transmit and receive pulse. Have been assuming a motionless sensor, but this quickly becomes not good enough.
I’m also interested in geometry. Example of a message using “cross-track,” “along-track.” This is a mess if you are looking up. So we need coordinates that still make sense, less tied to the machine.
Laura: How about elevation / azimuth?
Kris: As long as it's defined with the standard axes it's fine. I've been using transmit and receive angle. That is something you can actually control.
Multibeams have one transmit and multi-receive. We could make one message that includes multibeams...
Laura: Quickly ran into this problem. Modern multibeams don't just give you a point. Lots of things would like a point.
Kris: I just report detections. If you do intensity vs range you get huge overhead. I think the way to represent that might be an image with jpeg compression.
Brian: How do you interface with the hardware if you don't [missed this...]
Kris: You need to know something about vessel motion to convert that to a point cloud.
Brian: [Something about a ROS interface; audio not clear for me]
Kris: You need travel time and angle.
Brian: I love the idea of having separate --not just one multibeam message.
Kris: Detections, and then water column data. A lot of times with Norbit we don't save column data.
Brian: Three levels of message data. Chris Roman would call it Raw, rare, cooked.
Tully: Laser geometry library does the projections for laser scans. Even at 60Hz, moving fast enough causes a problem. We have number of rays and time between each ray, which is small but significant. Timing data and relative angle of each beam should be enough to write the generic processor.
Kris: We need that for our stuff so I'm writing it right now. Also need sound velocity profiles. I'd like to see a CTD message, sound velocity message to complete that picture.
Brian: I don’t think we’re going to resolve everything in the remaining 15 minutes, so let’s plan next steps. I motion to using acoustic_messages as a place to put our stuff. I volunteer to be a maintainer Laura if you want. Second?
Kris: Sure.
Laura: Before I agree: is it the right name? I initially tried to keep the name narrowly scoped but now it seems to be opening up.
Kris: oceanographic_messages?
Brian: One repo with packages: acoustic, environmental, […] Any issues with APL hosting it?
Laura: I'm fine with that. Our projects are so far into the the research end of the research-product continuum that changing names and breaking stuff isn't a problem.
Brian: Can start putting issues up to capture what we need.
Kris: I can start putting up PRs right now. Will probably fork today.
Brian: Hosting at APL is awesome, but Laura shouldn't be the only termination point for PRs. I volunteer to be a maintainer and I volunteer Kris.
Kris: Sure.
Laura: Also don't want to be the termination point for every driver. That needs to be more distributed.
Brian: yeah
Laura: I like the idea of renaming to oceanographic messages.
Brian: Is there a name that fits with the ROS ecosystem?
Tully: We try to name them so people will find them.
Brian: ocean or underwater
Kris: underwater is more limiting.
Brian: Don't want to alienate people in working in rivers, etc.
Kris: hydrographic_messages?
Ben: Great discussion. Recommend adding a document explaining how to contribute. Maybe name it after Tully.
Brian: we could brand it.
Laura: Our options so far: “underwater”, “marine”, “hydrographic”, “ocean”. Anything else?
Brian: Changing later is hard. Let's put up a Google document and give ourselves 3-4 days to contribute names.
Laura: Idea is that the top level name will go away and subcategories will be a bundle.
Tully: Repository name is irrelevant in the scheme of things. Suggest instead of a Google doc, to make a readme in the repo.
Mabel: Should we post on ROS discourse and link to the doc so other people not in this meeting can contribute?
Laura: I’ve been thinking about waiting for the right time, so now I’m asking this group for advice--are we ready to invite feedback?
Tully: Write a proposal first and then ask for comments. I don't think you'll get that much from ROS discourse.
Laura: Previous efforts stalled out after community feedback.
Tully: Don't consider community comments blocking.
Laura: Next steps. Will someone put in a PR for organization of messages under that.
Brian: I will do that and ping Kris as a reviewer. Laura will you make us maintainers, or do you want us to fork?
Laura: I absolutely will make you maintainers. Any other tasks going forward?
Brian: I’m happy how this came together. This is a good time for us at NPS to do this. We want to capitalize on momentum. I’m happy to jump on a call with a subset or superset of people here.
Laura: I'll also start a PR for the readme trying to get other linked projects that use these packages / messages.
Brian: Kris will you be able to share the work you do for Hercules?
Kris: Yes, Norbit is on a project already sharable. Have talked to Chris.
Ben: Laura, I'll also put you in touch with Stephen Seaberger at WHOI.
Laura: Ian Vaungh at WHOI couldn't make this meeting but is also interested. Sentry is not a move fast break things project at this point so will probably adopt late.
All: Thank yous to Brian and Laura and everyone.