ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A

Project Wayfarer

Starting to work on a project I’ve dubbed Wayfarer. My community has a large spread of concrete hike and bike paths that wander through neighborhoods and forested areas. My goal is a robot that can autonomously navigate these pathways.

The chassis is a Wild Thumper, the same as I used in the NASA Sample Return Robot (SRR) challenge. The current plan is to use an Up Board (quad core 64 bit Intel® Atom™ x5-Z8350 Processor 1.92 GHz as the main brain. This came in a Intel RealSense Kit with an R200 RealSense. Originally was going to use multiple Raspberry Pi 3s but the Up is much nicer.

I offload motor control to a Pololu Simple Motor Controller (SMC) and a Pololu Maestro servo / analog in / digital out controller. I’ve completed porting the Windows code for them from the SRR to Linux. Switched to Linux so I can work with ROS. Also competed in the Space Robotics Challenge so have a fair amount of ROS experience at higher levels. As you can see I’m now looking at lower levels for controlling the base.

A long way to go on this but I’m retired so can spend a lot of time on it. The first task is to get base level ROS support for the Pololu controllers. My thought is to write a ‘driver’ for both controllers that accepts messages to control the motors / maestro outputs and publishes the state of the controlled devices.

The unknown is what messages to use for this.

Above the motor controller presumably a twist message will arrive at a higher controller that gets translated into a motor command message for each motor. My thought is that each motor is controlled by a separate node. Since there might be multiple motors the controller nodes could accept a trajectory_msgs/JointTrajectory Message with the name of each motor. The SMC can control velocity and acceleration so can use that from this message.

Similarly, the servos can be positioned with the same message using speed, acceleration, and position.

If the maestro is used for digital output a joint message is heavy. But it should still be a name and value array. Don’t see anything standard that works. Any thoughts? Same thing for reporting on digital inputs.

Also, the SMC has analog and RC inputs plus a lot of status information (voltage, temp, errors). Maybe the latter should be done through a service rather than published?

Okay, a lot of thinking on the fly here. Time to stop and think. Appreciate any comments or suggestions on how to proceed.


I have no experience with any of them, but a quick ros pololu Google turned up quite some results (hansonrobotics/ros_pololu and geni-lab/ros_pololu_servo among others).

In my set-up, ros_control ( on RPi receives join position / velocity commands. Then RPi relays updates/state requests to Arduino over a serial link. When commands are received, Arduino uses Pololu API to set/get parameters on Mini Maestro servo controller. Same thing for VNH5019 motor driver.

ros_control and controller packages are pretty good.

For now, I abandoned the use of rosserial and use a custom protocol and serial I/O between RPi and Arduino. Actually, I just wrote a blog post about it, if interested take a look at


Thanks. I’ve looked at those project but they are limited to controlling servos, despite the ‘motor’ in their descriptions. I also want to access the digital and analog capabilities of the Maestro. They don’t address the Simple Motor Controller at all.


The problem you are working, low level control of a mobile base, has been done more than a few times.

What you need to implement is called a “base controller”. This accepts messages from ROS and controls motors based on the messages. Almost certainly you will be using the “move base” package to do the motion planning. this package expects your base controller to accept “Twist” massages. Even if some other package is used the “standard” is to use “twist” messages.

So to answer your question about “what message type?” the answer should be “twist”.

If you are using the Wild Thumper chassis it is a good choice for a small outdoor robot. I am using the same chassis. (For those who don’t know, this is a 6 wheel drive chassis, one gear motor per wheel) One modification you will need. You really do want to put encoders on the center pair of wheels. Don’t bother with the end pairs. You only need the encoders on the center. As you know the center axel caries most of the weight and the front and rear wheels are intended to slip and skid. Encoders are only useful on the center axel.

As you know, all three motors on the left are wired in parallel as are al the right motors. You can in effect read the Thumper as a two wheel robot, just like “Turtlebot” and most of the turtlebot tutorials apply.

You can add the encoders yourself or buy a Thumper with encoders from the factory in China. I added them myself but would 100% not recommend it. It took a lot of work.

Study the diagram and documentation for "Move Base"
Move Base

All your questions about what could be a service, what massage types and so on. are answered by the above.

This is the wrong l=place to discus the design of Yhumper/ROS robot design. If anyone wants to discus Wild Thumper under ROS (including 3D printed parts, batteries and what not) email me at and we can find a suitable public forum.

This is a great chassis but almost all of them end up being just R/C cars.

Mind to share where you got the encoders from? I still have the original four motors from my wt chassis (4wd) and like to equip them with encoders.

Also, what is the problem discussing a full implementation of a ROS base controller here?

For Rud_Merriam: Do you already have a speed control and odometry for your robot?


While I’m using the Thumper I don’t want to limit this code to that platform so I’m generalizing to handle more than two ‘motors’, i.e. Thumper has 3 per side but controlled as one.

I think twist is a level higher than than I’m talking about.

Move Base >> _twist_ >> Platform Controller >> _JointTrajectory_ >> SMC Driver >> SMC

Something has to translate twist into the speed control commands for the Simple Motor Controller (SMC). JointTrajectory contains the necessary information so probably is the way I’ll go.

I have motors with encoders but they are not installed, in part because I don’t have anything that will read the encoders. I may see if a script on the Maestro can handle it but have my doubts.

I’d be interested in discussing other aspects of the project elsewhere but IMO this project section is appropriate for this discussion. There have been similar ones on other projects.

Most ‘robots’ tend to end up as RC cars. I’ve already used the Thumper for an autonomous competition.



I have speed controller but not odometry. Pololu sells replacement motors with encoders and I’m going to use two of them. Also need to determine how to capture the encoder information. Might fake odometry with timing if I get to the point of wanting to work with Move Base.


I don’t mind here but this forum I thought was for announcements about ROS
itself. Not for people who use ROS. Eventually whoever manages this
list will jump in and tell us.

As for how to obtain a Wild Thumper with encoders there are several options

The 'Thumper is made in China by a company called “Dagu Robots” Dagu has a
lot of interesting products One is this motor.
It is a Wild Thumper motor with encoder.

Also if you email Dagu Customer service and ask. They will sell you a wild
thumper with this motor replacing the standard motor. They charge not
much more than the cost of the motors and BELEIVE ME it is worth it to have
then do the work

Those are two ways where you have to deal with the Chinese factory.

The other way is to notice that the motors Dagu is selling are just normal
25D gear motors. You can buy these from many different vendors. One is

You can buy the samemorte and the same encoder from Pololu. But Pololu
has something else: They sell motors with no gearboxes. These come with
and without encoders. I bought a 25D, 6 volt motor with encoder and not
gearbox and swapped two of these into my stock wild thumper. Logically
it should have been a screwdriver job and take about 15 minutes But the
motors in the wild thumper are press fit into this black plastic holders
another is no room for the encoder leads.

One last comment. You can NOT simple add encoders to the stock Wild
Thumper. Encoders require the motor to have a “back shaft”. This back
shaft is an extension of the motor shaft out the rear of the motor. Wild
thumper meters lack this so you have to replace the motor. When I
found you can buy the motor with no gearbox, that is what I got.

Doing it all over again, I would simply buy the wild thumper from Dagu
directly and save a ton of work. But if yu already own a wild thumper then
you have to swap the motor on the center on each side.

Back to ROS…

You are going to need a source of odometry. So people are using “virtual
odometry” by computing optical flow from video cameras but I think you need
real ground truth to calibrate everything else. BTW I just discovered 360
degree cameras. These have a true SPHERICAL field of view. Yes they see
EVERYTHING. I want to place one of these on this robot. I am working on
software right now to computer optical flow. With a spherical camera, I
think(?) vehicle heading is simply the average optical flow times -1.
These camera cost under $100. So far i have a helmet mounted camera and
I’m walking, collecting test data.

Yes. What you are building is called a “base controller”. Typically
everything done at a lower level than “twist” is done outside of ROS.
ROS is really not very good with real time.

I had the same goal. wring this controller once and reusing it. My other
platform has four wheels and each has it’s own encoders and each wheel is
control independently.

Here is how I did it…

My Base Controller runs on an ARM Cortex-4 micro controller. These are
like Arduino but 40X more powerful at 1/2 the cost. They run a ROS node
using ROS Serial and connect to the larger Linux based system with a serial

The base controller, waits for “twist” messages. For each message it
computes the speed of every motor and stores this as “target speed”. It
is not hard only a little trigonometry is needed and we only get at most 20
twist messages per second

Also running the same Cortex-M are one PID servo control loop for each
motor that neds to be controlled. The PID loop looks at the target speed,
compared this to the measured speed and then does what PID controllers do,
adjusts the motor voltage to reduce the error. I have one loop per wheel.

Finally the last part. An interrupt service routine was called each time
an encoder sends a pulse. Atevery plus it updates the measured position of
the wheel. This can be as fast as 11,000 times per second

In short, the measured speed is kept up to date by an interruption
handler. The target speed to kept updated by the twist message handler.
Then the PID controller runs 20 times per second and looks at the
difference between measured the target speeds and sets the motor voltage up
or down so as to make target equal measured.

You are forced to use a small micro controller if yu are dealing with wheel
encoders. Any computer running linux would never handle the interrupt rate.

One final thing. Recently found out that ARM has a feature where it can
handle quadrature encoders in hardware. I don’t need to us an interrupt
handler. I’ll change this some day. It will save a ton of CPU time I
could simply read the well position from a hardware register.

The same Cortex-M also sends periodic odomerty messages. Also it does
"housekeeping" things like battery voltage

To underline that Chris architecture is a common one I’ll add a draft of my setup which is similar.

I have a 4wd, so 4 motors to control, they are controlled independently by the 4 PWM outputs of an AVR Atmega. For this I use 4 PID controller, which are all calculated on the AVR. The measurements for the PID comes from the 4 quadrature encoders which are polled in the timer overflow interrupt service routine.

The AVR is connected to the computer using a I2C bus. Input is x translation and z rotation parts of the geometry/Twist message. Output of the AVR are the translation (x,y) and rotation (z) parts of nav_msgs/Odometry. The conversion between the I2C protocol and the corresponding ROS message is done with a node on the board computer.

Btw if you don’t need much cpu processing you could do everything on a Beaglebone Blue. It has an additional real time processor “PRU”.

Hope you can find this useful.