In the world of robotics, we often live in two separate worlds.

First, there’s the “brain”: the high-level software, often running on the Robot Operating System (ROS). This is where sophisticated algorithms for navigation, perception, and decision-making live. This world speaks in abstracts, like “move forward at 0.5 meters per second and turn at 0.1 radians per second.”

Second, there’s the “brawn”: the physical hardware. This is the world of high-current motor controllers, spinning wheels, and raw torque. This world speaks in low-level serial commands, PWM signals, and packetized data.

The gap between them is vast, and bridging it is one of the most critical steps in building a functional robot. That’s exactly what the protobot project by chrissunny94 on GitHub sets out to do, and it does so by taming a particularly powerful piece of hardware: the Sabertooth 2x32 motor controller.


What is the “protobot” Project?

At its core, protobot (also named “Raiden” in the repository) is a ROS driver node. Its job is to act as a translator.

It listens to the abstract “brain” of ROS and translates its commands into the precise language that the “brawn” of the Sabertooth controller understands.

In ROS, the standard way to command a robot’s movement is by publishing a geometry_msgs/Twist message to a topic, typically named /cmd_vel. This message contains the desired linear velocity (forward/backward) and angular velocity (left/right turn).

The protobot node subscribes to this /cmd_vel topic. When it receives a new Twist message, it does the following:

  1. Reads the linear x velocity and the angular z velocity.
  2. Performs the necessary calculations to convert these two values into two separate motor speeds for a differential drive (tank-style) robot.
  3. Uses the pysabertooth Python library to send the correct serial commands to the Sabertooth 2x32, setting the speed for motor 1 and motor 2.

This simple, elegant solution instantly connects ROS’s powerful navigation stack to one of the most robust motor controllers on the market.


Why the Sabertooth 2x32 Needs a Translator

The Sabertooth 2x32 from Dimension Engineering is a beast. It’s a dual-channel controller that can handle 32 Amps per channel, making it a favorite for heavy-duty applications like:

  • Large-scale autonomous rovers
  • Electric wheelchair-based robots
  • Combat robots

This controller is far too powerful to be driven directly by a Raspberry Pi’s or Arduino’s GPIO pins. It requires a dedicated communication protocol to send it commands, which is where the pysabertooth library comes in.

The protobot repository cleverly wraps this library in a ROS node, creating a reusable and modular piece of software.


How to Use It

Based on the repository, getting it running is refreshingly simple.

  1. Install the Dependency: The project relies on the pysabertooth library, which can be installed with a simple sudo pip install pysabertooth.
  2. Test the Hardware: The repository includes a TEST.py script. This is a critical (and smart) inclusion, as it allows you to verify your wiring and hardware connection to the Sabertooth before you add the complexity of ROS.
  3. Run with ROS: Once your hardware is confirmed to work, you can launch the main ROS node using roslaunch protobot saber.py.

This will fire up the node, which will immediately subscribe to /cmd_vel and wait for commands. You can then use another ROS tool (like rqt_robot_steering) or your own navigation code to send Twist messages and watch your robot move.

This project is a perfect example of the ROS philosophy: creating small,-reusable nodes that do one thing well. It’s a fantastic starting point for anyone building a serious, high-power mobile robot.

You can check out the project for yourself on GitHub: https://github.com/chrissunny94/protobot


This ROS tutorial on controlling motors helps explain the general concept of how motor control systems work, which is the core problem this project solves.

http://googleusercontent.com/youtube_content/0


<
Previous Post
Building a Mars Rover: A Look Inside the URC2017 Project
>
Next Post
Rubbertappingrobot