ros-omni-base: ROS mobile robot base for everyone. (Work in progress)

Foreword or why I'm doing this.

With exploding expansion of basic knowledge about microcontrollers and single-board computers of the first decades of 21st century, coinciding with abundance of cheap parts (Arduino, Raspberry Pi, MEMS IMUs, Kinect, robot vacuum cleaners etc...), it would seem that everyone with a hundred dollars to spare can build an advanced robot nowadays.

Why doesn't it happen as often as one would expect? Most of the projects I'm seeing in DIY community fall into one of the following categories: wheeled line follower robots, servo arms controlled via PC link, self-balancing robots or Arduino-based remote-controlled vehicles. More advanced projects are quite a rare sight.Where are the robots of the more practical kind, something akin to Boston Dynamics' robots, ASIMO or RoboSimian?

I've been thinking about this for a while now, and the most logical conclusion is this: DIY robotics lacks easy template solutions that anyone can use to compose more complex projects. For microcontroller projects - we have Arduino, single-board computers - Raspberry Pi, Wi-Fi enabled microcontrollers - ESP8266 and ESP32, and what kind of ecosystem springs to your mind when I say robots? Some sophisticated readers will say ROS, and that's absolutely right, but that's not (yet) as widespread as any aforementioned ecosystems, and I'll expand a little on the reason for this below.

But first, imagine this: you are a person with average (or even above average) knowledge about software, or electronics, or both. You've done a couple of projects involving microcontrollers, some sensors, perhaps even actuators, but never even dabbled with robotics. You can easily envision how you'd go about automating your home, or making any sort of electronics device, really, considering they all take some input and produce some kind of output. But how would you go about making a robot? A useful one, at that. Something that can not only efficiently navigate its environment, but do things like opening doors, cooking, mowing a lawn, fighting or putting out fires?

Well, you could go the intuitive way and create it completely from scratch. What you'll realize after a year of toil is these things: 1) You've wasted way too much time to build functioning 'vanilla' components that every mobile robot that's ever been built already consists of (i.e. mobile base, power distribution). 2) Your robot (if you didn't give up somewhere halfway) is still an ad hoc solution. To incorporate another function in it, you'll have to code and solder and build, probably even dismantling the whole thing in the process to assemble it again.

An amateur robotics enthusiast in my university years, I've been through this time and again. Robotics competitions change rules (and the functionality of robots pertaining to these rules) at least once in two years. Notable example of this is well-known Eurobot, with contest theme and tasks changing each year.

Motley troop of robots built specifically for contests we took part in. Not all of robots on the picture with a whole crowd'o'bots are ours, evidently, but one of them is.

But robotics contests are beyond the point I'm making, which is: it doesn't matter if you want your robot to compete in ever-changing contests or just want a universal robot for every task you can think up. The key to making a good robot is modularity, software- and hardware-wise, and reusing old modules for new robots unchanged, instead of modifying them. If you write object-oriented code, this should sound familiar - the old composition over inheritance principle is essentially what I've just described.

Now that I've mentioned modularity and ROS, let's imagine that you didn't use the hopeless ad hoc approach and someone advised you to use ROS as the software backbone of your robot (with ROS-compatible hardware as a consequence).

ROS allows for a multitude of various software and hardware options, and while this is great for someone with at least some experience in this platform, it's just plain confusing for newbies. Where to get started? The answer is quite obvious -  tutorials on

Alas, this approach is not going to work for me and people like me - impatient and preferring to learn while playing. These tutorials that I'm supposed to get started with don't look like they concern robots much (they do though, believe me) - messages, topics, publishers, subscribers... When am I going to at least make my robot move? The primary reason Arduino was so successful is that it allowed any owner of any Arduino board make it blink an LED in virtually seconds without any prior knowledge.

Another major hurdle that you'll have to overcome is coming into possession of real platform for your first ROS robot. Granted, as you take your first steps with ROS you can learn with RViz, but eventually you'll want a hardware platform. ROS ecosystem seems to swarm with great robots (full list of ROS robots)- the most famous ROS-compatible robot to get started seems to be TurtleBot:

You can order one online from one of the numerous distributors, but that's not exactly DIY approach, is it? That was my thought exactly. After some hours of trawling the web I was able to find this extensively documented DIY robot made for ROS: Linorobot

Linorobot support numerous configurations, all of them can be built from scratch.

I wouldn't manage to praise this robot and its creator(s) to do them justice enough (I like to ramble, but alas I'm missing the gift of eloquence) - just let me say that right now, building this robot from the ground up is the best way to get started with ROS for any hacker (i.e. someone who likes to know how things work down to their core).

What me and my teammates are building and sharing here is essentially a concrete implementation of Linorobot base - after all, standing on the shoulders of giants is the way to even greater accomplishments.

ros-omni-base is only the wheeled platform for Linorobot, which is a complete firmware-software-electronics bundle for any robot base with wheels, Linux board and Lidar or Kinect to sense the surroundings.

This project is meant to aid beginners in robotics with the following:
  • Reducing the cost of entering robotics with ROS. Instead of buying Turtlebot, you can make your own.
  • ros-omni-base eliminates the uncertainty still associated with building Linorobot from scratch.
    Linorobot software can control two- and four-wheeled platforms, including Ackermann steering and Mecanum wheels - provided it's loaded with the right firmware, but it doesn't include BOMs, drawings, assembly instructions etc. I think this decision was made intentionally to signify the fact that Linorobot is mostly mechanics-agnostic, but it usually brings more confusion for newbies. ros-omni-base is built upon a concrete set of components.
  • Cheaper and more widespread Arduino Mega instead of Teensy to control motors and read encoders. The aim of this swap is to make part location process as easy on your mind and wallet as possible, without compromising performance at the same time.
  • As an upshot, quickly get you up and running with robotics and ROS.
The end result you're supposed to get after following this guide is a wheeled robot base that can be connected to ROS with USB and controlled via teleoperation (standard Twist messages) using teleop_twist_keyboard package.

What you'll need


  • Arduino Mega2560 x 1.

I've got the original board from Arduino, but any clone will do just as well. For instance, I bought this one on separate occasion and it still works.
  • Pololu Dual VNH5019 Motor Driver Shield for Arduino x 2
Can be bought at Pololu store. Link to product page.
  • Inertial measurement unit x 1
Quite controversially to the motto of the project, the list of supported IMU models is vague, but that's only because it might be the most expensive thing in the whole build. Someone already in possession of one IMU board might not want to buy another just to build this thing. If you have a model of IMU that you successfully used with this base, please send your pull requests to expand the list. ros-omni-base supports following IMUs:
    • Pololu MinIMU-9 v5 Gyro, Accelerometer, and Compass (LSM6DS33 and LIS3MDL Carrier) (link to product page) - that's what I'm using in my build.
    • GY-85 - already supported by Linorobot.
    • MPU6050 - already supported by Linorobot.
    • MPU9150 - already supported by Linorobot.
    • MPU9250 - already supported by Linorobot.
I'd like to eventually expand this short list with other IMU models I have: Sparkfun 9DOF Stick and 5DOF board (both obsolete now)  as well as any other models I can obtain.
  • 99:1 Metal Gearmotor 25Dx54L mm HP 12V with 48 CPR Encoder x 4
This one is manufactured by Pololu as well. Link to product page.
  • LiPo battery x 1

My build makes use of ZIPPY Compact 5800mAh 3S 25C Lipo Pack - it's nominal voltage is 11.1V, more than 12V when fully charged.  But the thing is, ros-omni-base was designed to accommodate a wide variety of lithium and lead batteries, so anything that can put out around 12V can be installed with minimal modifications.
  • XT60 connector male x 1 + female x 1.
The battery mentioned above uses some weird bullet connectors with high short circuiting potential (something like banana plugs). They are not the best choice of battery connector because even a cautious person can accidentally swap positive and negative terminals, rendering mobile robot immobile (hehe) and possibly melting some valuable electronics. I decided to replace them with XT60 - convenient polarized connectors.
Link to Hobbyking. Link to Aliexpress.
  • 5x7cm perfboard x 1

This will accommodate power and signal distribution circuit. Link to Aliexpress.

  • JST XH2.54 connector male x 4 + female x 4
Encoder connector (5V, GND, A, B). This seems to be the most widespread choice for polarized board-to-wire connector. Any other 4-pin polarized connector will do.
Link to Aliexpress. They also sell pre-crimped 20cm lengths of wire with this connector - this way you can avoid any fuss usually associated with crimping.

  • HT5.08 2 pole screw terminal block connectors x 4 pairs

Makes for easy motor plugging and unplugging. Link to Aliexpress.
Can be replaced with any generic 2 pole screw terminal for PCB mounting, but that won't be as convenient! (aliexpress) :

  • Miscellania like capacitors, pin headers, wires, etc. You probably already have all this in your parts bin.


  • Base cut out of aluminum sheet x 1.
Don't mind the useless rectangular hole in the middle - it appeared due to miscommunication!
I believe you will find at least one workshop in your city that will cut an aluminum sheet to shape for symbolic fee. If it's nowhere to be found, replace it with a sheet of acrylic glass or plyboard.
  • Omniwheel with mounting hub x 4.
You can pick any kind of omniwheel you fancy, just make sure the mounting hole's diameter is the same as motor's spindle diameter (4mm in my case), otherwise the motor's rotor won't fit into the hub. I got mine at the usual overseas vendor: wheel, mounting hub.
  • Ordinary 3D printer (printing volume at least TODO) x 1.
Some parts are provided as STL models, so you're gonna need to print them. That's not as exotic in 2018 as it used to be - considering how anyone can build a printer from old printers or scanners and scrap metal or outsource the process altogether.
  • Printed parts (WIP) - I'll publish link to STL files when they are all ready

When everything on the list is ticked, it's time to assemble the base:



  • I suggest filling the gap between motors and hall sensor board with something soft and dielectric, like silicon or rubber, because the board is only held by 2 fragile terminals that will eventually break off due to mechanical stress:


The wire that comes with motors was way too short, so I replaced it with the longer one, replacing the flimsy 6-pin connector with separate connector for power (motor wires) and signals (encoder wires).
  • Crop off the existing wires first. To see which color corresponds to which wire, see table on motor's product page.

  • We are going to separate signal and power lines on this motor. This is actually the best practice in electronics engineering because it minimizes crosstalk between them. Solder a longer wire to red and black wires and insulate them with heat shrink.

  • Let's lengthen the encoder's wires now. There's 4 wires total, 2 of them signal and 2 power wires. Now, which insanely popular cable fits the bill? USB - everyone these days has at least one in their house! Butcher any cable you don't want for perfect pieces of 4-wire cable.

    All done!

  • The opposite ends of motor's cables will need wire-to-board connectors.
    I happen to know a very reliable, battle-proven way to crimp JST connectors:
    1) Strip the insulation off of ends of wires, solder the tips and keep the tip as short as possible.

    2) Clamp the wire in the chute on the inner side of metallic terminal. Needle-nose pliers are just perfect for that.

    3) Smear one tiny drop of liquid flux on the terminal where the wire ends, and solder the wire to the terminal. Crimp the rest of the terminal over the wire.

    4) Plug the terminal into the plastic shell. You're done!

  • To connect motor's wires to HT connector, I'd advise to crimp them as well:

That's what the result should look like:

  • While assembling the robot base, we've installed our electronics on the underside of the dome covering the base. Now you can solder it all together according to this schematics in-place:

Link to PDF schematics.
Note the distribution board mentioned a lot in schematics. That's the part of schematics where battery voltage and 5V are wired to encoders, Arduino and motor shields. It also contains connectors that'll make for easy swapping and disconnecting motors and encoders later on.

Grab the perfboard and arrange the connectors first:

Solder the connectors to the board and the rest is just lots of routing:

PIC PLACEHOLDER - finished distrib board.

Final result is supposed to look like this:

PIC PLACEHOLDER - finished electronics.

Programming - WIP

Trying it out - WIP

1) Ubuntu 16.04.4 Xenial