Revision history [back]

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.

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.