Conversation with #meeting.ros.org at Mon 11 Oct 2010 04:07:59 PM EDT on ericperko@irc.freenode.net (irc)
(04:07:59 PM) The topic for #meeting.ros.org is: Meeting space for ROS developers | #ros.org
(04:11:50 PM) chadrockey [chad@theprince.STUDENT.CWRU.Edu] entered the room.
(04:12:16 PM) Eric Perko: Hi everyone
(04:12:31 PM) Goncalo_ISR: Hi!
(04:12:43 PM) tfoote: howdy
(04:12:59 PM) chadrockey: hello
(04:13:31 PM) johnjsb: hey
(04:14:19 PM) tfoote: Eric,
(04:14:31 PM) tfoote: do you know of anyone else who's planning to join?
(04:14:48 PM) Eric Perko: don't think so. I don't see anyone else on the reviewer list that indicated they were going to
(04:15:02 PM) Eric Perko: I think we can get started
(04:15:48 PM) Eric Perko: We can just go in order of the comments on the wiki page
(04:16:05 PM) Eric Perko: Looks like first up is the range vs rangearray stuff
(04:16:51 PM) Eric Perko: I believe the consensus was that it was just for convenience and not necessary if we have the frame information in the individual range messages
(04:17:05 PM) Eric Perko: Does that sound right to everyone?
(04:17:12 PM) Goncalo_ISR: yup I agree
(04:17:23 PM) johnjsb: dont see much reason for it
(04:18:04 PM) tfoote: i agree it's not neccessary
(04:19:02 PM) chadrockey: yea, I think stage only does it to make simulations easier by grouping the same types of sensors together, I don't think we need it
(04:19:11 PM) Eric Perko: Okay. We'll leave out an array.
(04:19:22 PM) Eric Perko: Next up is the radiation type stuff.
(04:20:00 PM) Eric Perko: So, I think there are two parts to this. We seem to have an agreement that it is a good idea to include the radiation type, but not necessarily on how.
(04:20:26 PM) johnjsb: i like it could be very useful for mapping various em
(04:20:35 PM) tfoote: that seems accurate from the comments
(04:20:55 PM) chadrockey: I definitally want the distinction between IR and Sonar, not sure what to do about the very long list of types
(04:20:55 PM) Eric Perko: Tully, if we include these as an enum type, can we add new radiation types later without breaking existing code?
(04:21:12 PM) tfoote: yes we can add enums later
(04:21:16 PM) Eric Perko: okay
(04:21:31 PM) tfoote: technically we can even change them, but that's not recommended
(04:21:58 PM) johnjsb: thats why i was thinking of the list i had
(04:22:07 PM) Eric Perko: Ya I figured... I wanted to add more _without_ making everyone else mad when sonars aren't sonars anymore :)
(04:22:28 PM) chadrockey: I think we should only include sensors that are confirmed being used right now
(04:22:34 PM) Eric Perko: I agree.
(04:22:48 PM) johnjsb: sure
(04:22:49 PM) Eric Perko: Especially since we can add more enums later for other radiation types
(04:23:18 PM) johnjsb: what would that entail
(04:23:46 PM) tfoote: i agree too. Adding the additional information from the radar, such as tracking id and velocities warrents a new message.
(04:24:07 PM) Eric Perko: Definitely
(04:24:20 PM) tfoote: Also for the IR yes/no sensor or intensity sensor would warrent a different message as well.
(04:24:24 PM) johnjsb: yea i just threw that in there its certainly a special case
(04:24:25 PM) rosbot [~rosbot@kim-198.ssl.umd.edu] entered the room.
(04:24:32 PM) rosbot left the room (quit: Remote host closed the connection).
(04:24:56 PM) rosbot [~rosbot@kim-198.ssl.umd.edu] entered the room.
(04:25:32 PM) Eric Perko: John, adding a new enum should just mean adding another "uint8 NEWTYPE=x" where X hasn't been used before to the message definition
(04:25:54 PM) johnjsb: ok
(04:26:18 PM) Eric Perko: My main question with the intensity is: is it useful to pair with range information? Are there sensors that do that that would use this message?
(04:26:53 PM) Eric Perko: For example, a lot of lasers can pair intensity with range, but I don't know of an IR or Sonars that do that type of thing.
(04:27:55 PM) chadrockey: for the sharp IR sensors, it might be useful to know if the reading is close or far
(04:27:59 PM) johnjsb: no nothing off the shelf that i can think of some sonars for uav use it i believe tbut that custom
(04:28:05 PM) Goncalo_ISR: for some IR intensity is then used to estimate range, so it's a bit redundant
(04:28:08 PM) chadrockey: you can't know that without an expectation and a map
(04:28:12 PM) tfoote: if there's not IR or sonar sensors with that information it would seem that the Range message could leave that out. And we could create a new message for the new application in the fiture.
(04:28:28 PM) chadrockey: for many of the IR sensor readings, it could correspond to two distances, one very close, and one further out
(04:30:16 PM) Eric Perko: Can you take the IR range reading and easily recompute the intensity?
(04:30:46 PM) Eric Perko: I.e., is it definitely redundant or is it useful information to include with our range estimate?
(04:31:12 PM) johnjsb: it the color i believe that determines intensity so its kind of hard to make acurate distance
(04:31:17 PM) chadrockey: I think it's probably not useful, even for the case I brought up, you wouldn't really know what to do with it without intimate knowledge of the IR
(04:31:32 PM) Goncalo_ISR: well, the range calculated from the intensity will depend on other factors like the surface that is reflecting the light
(04:32:21 PM) Goncalo_ISR: still, from a software point of view we dont want all sorts of data fields from which to run the algorithms
(04:32:24 PM) chadrockey: yea, I don't think anything on the receiving end of these messages will be able to handle any of these problems
(04:32:29 PM) johnjsb: hmm how does it compare to sonar is it actually better
(04:33:18 PM) Eric Perko: what are we comparing exactly? a range reading from an IR sensor vs a sonar?
(04:33:28 PM) johnjsb: yes
(04:33:52 PM) chadrockey: in terms of what?
(04:33:55 PM) Eric Perko: I believe it depends on your environment and such... we could probably stick around and discuss that after the meeting if you wanted.
(04:34:02 PM) johnjsb: how accurate is it really is it worth the trouble
(04:35:02 PM) tfoote: I think that if there are ways to improve the raw output of any specific sensor which provides both range and intensity information. The corrected value should be published from the driver as a Range message after the intensity correction.
(04:35:40 PM) Eric Perko: Yup, that's the idea of the Range message
(04:35:41 PM) johnjsb: true
(04:35:45 PM) tfoote: This provides a simple abstraction which is common across all "Ranger" devices, and the driver can expose a more powerful message/API at a lower level.
(04:35:47 PM) Goncalo_ISR: yup I agree
(04:35:50 PM) tfoote: if desired
(04:36:24 PM) Eric Perko: Okay. So, to recap, sounds like intensity is not so useful for anything other than correcting range? So leave it out of the message?
(04:36:38 PM) chadrockey: sounds good
(04:36:39 PM) Goncalo_ISR: yes
(04:36:47 PM) johnjsb: yea keep it simple
(04:36:47 PM) tfoote: yes
(04:36:56 PM) Eric Perko: Okay.
(04:37:23 PM) Eric Perko: Next up, we have whether to include variance information in the message. It looks like there was no disagreement about leaving that out.
(04:37:46 PM) chadrockey: yea, isn't really a function of the sensors so much as whatever the environment properties are
(04:37:58 PM) Eric Perko: So we'll leave variance out of the message. Agreed?
(04:38:03 PM) tfoote: agreed
(04:38:08 PM) johnjsb: yes
(04:40:00 PM) Eric Perko: Alrighty. As far as the scope of the message, it seems there is a bit more to be done there. There were clearly some questions about whether a yes/no IR could be added.
(04:40:34 PM) Eric Perko: Or used with this message type
(04:40:49 PM) tfoote: I don't feel that a yes/no sensor qualifies as a range message.
(04:40:53 PM) Eric Perko: I agree
(04:40:58 PM) chadrockey: if it doesn't return a range, it shouldn't go here
(04:41:05 PM) johnjsb: yea i dont think so either
(04:41:07 PM) Eric Perko: However, it seems I need to make the distinction clear
(04:41:12 PM) Eric Perko: in the documentation
(04:42:09 PM) johnjsb: could it just be turned on if 1 greater than the min
(04:42:39 PM) tfoote: Yes, i think that if the documentation is clearly stating that this is for expressing a single *range* measurement it should be fine.
(04:42:47 PM) johnjsb: say its set for 2inches if its2.1 its "ON"
(04:42:49 PM) Eric Perko: I think that can go in an action item to be resolved. I'll see about adding some more explicit notes to the range message definition and then email that out as part of the review follow up
(04:42:55 PM) chadrockey: if you "turn it on" with 1 above the min, that would conflict with things trying to map with this
(04:43:15 PM) tfoote: There are definitely ways to hack it in, but things like clearing out data by ray tracing would potentially be broke.
(04:43:36 PM) Eric Perko: Tully, is there anyplace that these messages are documented besides their .msg files? It seems like there aren't really wiki pages for things like LaserScan.
(04:43:55 PM) johnjsb: yep to bad could have been useful for stairs or something
(04:44:18 PM) Eric Perko: It's definitely a useful message. Just needs it's own message to deal with the special semantics involved :)
(04:45:14 PM) tfoote: there's not a specific place. You can create a wiki page for it if necessary. we try to put it into the msg definiton to keep it freestanding. also for tools like rosmsg to view them
(04:45:29 PM) johnjsb: hmm didnt notice before but is there no bumper kind of message
(04:45:36 PM) Eric Perko: Ya I figured. I'll keep it in the message. It should be pretty short.
(04:46:03 PM) Eric Perko: Nope. There are a few messages in the nxt_msgs package that would be useful for these other cases, such as the Contact message.
(04:47:01 PM) johnjsb: does it really need to be part of ros or is it better to hack something like nxt_msgs
(04:47:42 PM) tfoote: In general we like to develop and test things in leaf stacks, and then promote messages as the proove useful to other stacks.
(04:47:57 PM) johnjsb: i see
(04:48:34 PM) tfoote: This way, for nxt stuff we were able to rapidly prototype and iterate within the stack while, and now are going through the review process to make it available to more stacks.
(04:49:04 PM) Eric Perko: It is a good process.
(04:49:13 PM) tfoote: Eric, do you have any outstanding issues left for the review?
(04:50:00 PM) chadrockey: do we want the name of the message to be Range or Ranger?
(04:50:16 PM) Eric Perko: John had brought up a frequency to be added to the message. I don't think it necessary if we have the enums. Agreed?
(04:50:42 PM) Eric Perko: Also, I didn't see much commenting but would like to confirm that we only need a single FOV field.
(04:50:44 PM) johnjsb: i like just range
(04:50:56 PM) Eric Perko: I agree. A Ranger device sends a Range message.
(04:51:19 PM) chadrockey: until we reach the point where the enums are running low or we have "Radar N Hz" "Radar N2 Hz" we probably don't need frequency
(04:51:45 PM) tfoote: I agree "Range" message, no frequency
(04:51:48 PM) johnjsb: agreed
(04:51:54 PM) Eric Perko: okay
(04:52:06 PM) Eric Perko: and a single FOV?
(04:52:59 PM) johnjsb: yea a cone is best for fov i think
(04:53:12 PM) tfoote: I don't see a case for making the more complicated fov
(04:53:18 PM) chadrockey: neither do I
(04:54:15 PM) Eric Perko: Okay. I think that's all I had. Looks like there aren't any changes to the proposed message, just some documentation stuff to be done. Sound right everyone?
(04:54:26 PM) johnjsb: sure
(04:54:40 PM) tfoote: sounds good
(04:54:40 PM) Goncalo_ISR: yup, sounds good :)
(04:54:49 PM) chadrockey: yup
(04:55:12 PM) Eric Perko: Okay. Well, unless anyone has anything else they wanted to discuss for this review, I think we are set.
(04:55:27 PM) tfoote: Great. Thanks for organizing this Eric!
(04:55:43 PM) Goncalo_ISR: yeah thanks :D
(04:55:46 PM) chadrockey: yea, he should do the GPS next >:)
(04:56:00 PM) johnjsb: yes I would love to have GPS
(04:56:48 PM) Eric Perko: No problem Tully. It gets the message into the official stacks so I can more easily use it :)
(04:57:21 PM) Goncalo_ISR: can I just make one more question?
(04:57:25 PM) Eric Perko: Thanks everyone for attending and contributing to the review!
(04:57:25 PM) tfoote: Eric, if you can open a ticket with the resultant message I'll merge it in shortly.
(04:57:26 PM) Eric Perko: sure
(04:57:28 PM) johnjsb: sweet so sonar will be ready next week :)
(04:57:39 PM) Goncalo_ISR: is this new msg going to affect the navigation_stack?
(04:57:57 PM) Eric Perko: I hope it does someday :)
(04:58:14 PM) tfoote: John, I'll release it into unstable in the next week or so. It'll be in the diamondback release targeted for early next year.
(04:58:24 PM) Goncalo_ISR: sweet!
(04:58:40 PM) pvsousa: Hello all... Great Eric, this is very useful
(04:59:38 PM) Eric Perko: Glad you find it useful :)
(04:59:40 PM) tfoote: support for this message can definitely be added to the navigation stack. We don't have any ranger sensors in the building at willow but if you want to try to add it i'm sure Eitan can give you a good starting direction. Now that the message is in the dependency tree
(05:00:04 PM) Goncalo_ISR: we have a bunch of robots with sonars! we'd love to try it here!!!
(05:00:33 PM) Eric Perko: That was the idea. We also did some work to get stage to output it's underlying ranger information, but can't really have StageROS depend on nxt_msgs or some message in my repo :)
(05:00:38 PM) Goncalo_ISR: im sure we cant expect the same performance of a laser range finder, but if it works it would be so great
(05:00:43 PM) Goncalo_ISR: ho I already did that
(05:00:55 PM) Goncalo_ISR: since we have a bunch of sonars we exposed the sonars of stage
(05:01:06 PM) Goncalo_ISR: I can adjust the code to the new msg
(05:01:09 PM) Eric Perko: Sweet
(05:01:11 PM) Goncalo_ISR: and share if ofc
(05:01:21 PM) Goncalo_ISR: I'l take a look at it tomorrow
(05:01:41 PM) tfoote: great
(05:01:42 PM) chadrockey: lol, yea, we made a mess tying NXT, RVIZ, and StageROS together :-P
(05:01:50 PM) chadrockey: dependency hell
(05:03:35 PM) Eric Perko: I'm kinda surprised the PR2 doesn't have any sonars actually... seems like glass would be it's arch-nemesis in that case :)
(05:04:34 PM) Goncalo_ISR: true
(05:05:19 PM) Eric Perko: But anyways, as far as the review goes, I think we can adjourn now. I'll update the message documentation and send out a follow-up for the reviewers to approve. Once everybody has signed off on the final version, I'll make a ticket for Tully.
(05:06:24 PM) tfoote: thanks all!
(05:06:47 PM) Goncalo_ISR: yeah thanks for this opportunity
(05:06:56 PM) johnjsb: later
(05:07:26 PM) johnjsb left the room (quit: Quit: Page closed).
(05:07:27 PM) tfoote: PS for the PR2, with the 3d sensing often there is objects at the top or bottom of the glass which are big enough to block the PR2. For example door frames or crash bars
(05:08:01 PM) Eric Perko: I suppose... I guess I'm just screwed by the fact that one of the environments I work in has floor to ceiling glass walls....
(05:08:19 PM) Goncalo_ISR: what about now that there are a bunch of them out there, no one bumped into any glass problems?
(05:10:05 PM) tfoote: i haven't heard of any problems, but a true floor to ceiling glass could be a problem
(05:10:19 PM) Goncalo_ISR: hehe
(05:11:08 PM) tfoote left the room (quit: Quit: Page closed).
(05:11:20 PM) chadrockey left the room (quit: ).
(05:11:21 PM) Eric Perko: Alrighty, I'm outta here. Thanks again for contributing.
(05:11:39 PM) pvsousa: Thanks