Revision history [back]

When designing a ROS node, consider how it interacts with other ROS nodes.

Continuous inputs such as commands should be topics (subscribers) Configuration that doesn't change should be parameters Outputs should be topics (publishers)

You should also consider the type for each input, and make sure you choose a type which appropriately represents the data. For example, a std_msgs/UInt16 represents a single 16-bit number, while a geometry_msgs/Twist represents a motion in 3D - up/down speed, left/right speed, forward/back speed, and rotation about all three axes.

For controlling a simple servo, your input should be a single number, the desired angle. Since you're controlling a servo, we can name this topic "servo". Since this topic is a single number, you can use a type like std_msgs/UInt16 for it.

Your code will have a few major parts:

• The setServo function (which you already have)
• A message callback which extracts the value from the message and calls setServo
• The ROS initialization (borrowed from the rospy subscriber tutorial)
• A subscriber which subscribes to the servo topic, with a type of std_msgs/UInt16, and calls your callback whenever a message is received. (this can be mostly copied from the rospy subscriber tutorial, with a few modifications)

With that node running, you'll have a servo topic which you can use to control your servo through the publish command you mentioned.

You can also record the servo commands you send using rosbag: rosbag record servo Note that the rosbag command has two parts: the action (record) and the topics to record (servo).