Open ahendrix opened 11 years ago
[blaise] I would like to add that the channel field is not well defined. The major problem I see is that some channel numbers have overloaded meaning depending on whether you are on the 2.4 or 5 GHz (or 3.6 GHz) band. In particular I am thinking of channels 7, 8, 9, 11, 12, and 132-138.
It would make sense to:
[blaise] Not all wireless adapters return all the information that appears in this message. The message should define what value to use when the information is not available.
[wim] This message also does not belong in the pr2_msgs stack, it is not pr2 specific. This causes the wifi_drivers stack to depend on pr2_common. Could we move this message into the wifi_drivers stack?
[blaise] I would love to see a network_msgs package, in some ros-pkg stack. I don't like that linux_networking has to depend on wifi_drivers.
I fear that pr2_msgs/AccessPoint has never been reviewed. It currently contains some fields that do not follow conventions.
The pr2_msgs/AccessPoint contains: {{{ string rate string tx_power }}}
It is being filled out by wifi_ddwrt/ddwrt.py as: {{{ rate: 78 Mbps tx_power: 71 mW }}}
I think that these should be numeric fields, and that the unit should not be stored as part of the message.
Not sure what the right way of fixing this while maintaining compatibility is. Assigning to wim, as he seems to be the one who moved the message into pr2_msgs in r27774.
trac data: