ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

Sure. You are free to do anything you want in a ROS node. Just open a UDP socket (using basic C/C++ std runtime support, or Boost, or X ..) and use it like you would normally do.

The only 'restriction' would be that you'd have to give ROS a chance to process its events and do some bookkeeping once in a while. A typical pattern for that is something like:

while (your_own_termination_condition && ros::ok())
{
   handle_your_udp_traffic();

   // other stuff
   ..

   // let ROS do its thing
   ros::spinOnce();

   // maybe sleep a little (but that depends on your application)
   ..
}

If I understand your other question correctly, the 'other stuff' would probably include things like converting the odometry data from your motor controller into proper ROS msgs, and any incoming ROS msgs (most likely geometry_msgs/Twist) into data you can send to your motor controller over your UDP socket.

Sure. You are free to do anything you want in a ROS node. Just open a UDP socket (using basic C/C++ std runtime support, or Boost, or X ..) and use it like you would normally do.

The only 'restriction' would be that you'd have to give ROS a chance to process its events and do some bookkeeping once in a while. A typical pattern for that is something like:

while (your_own_termination_condition && ros::ok())
{
   handle_your_udp_traffic();

   // other stuff
   ..

   // let ROS do its thing
   ros::spinOnce();

   // maybe sleep a little (but that depends on your application)
   ..
}

If I understand your other question correctly, the 'other stuff' would probably include things like converting the odometry data from your motor controller into proper ROS msgs, and any incoming ROS msgs (most likely geometry_msgs/Twist) into data you can send to your motor controller over your UDP socket.


Edit: you might also be interested in using ros_control to base your own node on. Instead of implementing all of the ROS side yourself, you provide ros_control with a hardware_interface (which in your case would implement the communication with your motor controller over UDP) and 'the rest' (twist controllers, differential drive velocity calculation, and the associated ROS API) will be provided for you.

See davetcoleman/ros_control_boilerplate for an example of how to set this up.

Sure. You are free to do anything you want in a ROS node. Just open a UDP socket (using basic C/C++ std runtime support, or Boost, or X ..) and use it like you would normally do.

The only 'restriction' would be that you'd have to give ROS a chance to process its events and do some bookkeeping once in a while. A typical pattern for that is something like:

while (your_own_termination_condition && ros::ok())
{
   handle_your_udp_traffic();

   // other stuff
   ..

   // let ROS do its thing
   ros::spinOnce();

   // maybe sleep a little (but that depends on your application)
   ..
}

If I understand your other question correctly, the 'other stuff' would probably include things like converting the odometry data from your motor controller into proper ROS msgs, and any incoming ROS msgs (most likely geometry_msgs/Twist) into data you can send to your motor controller over your UDP socket.


Edit: you might also be interested in using ros_control to base your own node on. Instead of implementing all of the ROS side yourself, you provide ros_control with a hardware_interface (which in your case would implement the communication with your motor controller over UDP) and 'the rest' (twist controllers, differential drive velocity calculation, and the associated ROS API) will be provided for you.you. If I'm not mistaken, the husky_control pkg is similarly implemented.

See davetcoleman/ros_control_boilerplate for an example of how to set this up.

I sort of assumed here that you're trying to create a differential-drive mobile robot (as you talk about odometry), but if not, ros_control can still be useful.