Skip to content
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

pr2_msgs/AccessPoint message does not follow conventions. (ros ticket #4282) #181

Open
ahendrix opened this issue Mar 12, 2013 · 4 comments

Comments

@ahendrix
Copy link
Member

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:

@ahendrix
Copy link
Member Author

[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:

  • replace the channel field with a frequency field
  • add a band field (float representing the band name in Hz)
  • add a band field and a frequency field

@ahendrix
Copy link
Member Author

[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.

@ahendrix
Copy link
Member Author

[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?

@ahendrix
Copy link
Member Author

[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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant