MORPH : Modular Open Robotics Platform for Hackers

An affordable modular platform for open robotics development for hackers. Provides a jump start to build your own robot.

Similar projects worth following
This project aims to build an affordable modular robot platform using open technology.

- modular T-slot frame
- differential drive using two brushless DC hub motors
- driven by two open source speed controllers (VESC)
- uses Field Oriented Control mode to have near silent operation
- can carry a real load (~100KG)
- modular power supply built around a power distribution board with 3 in and 6 out connectors and separate DC-DC converters powered by one or more 10S2P battery pack(s)
- no central control board but separate USB controllers for each part, like ESC, gyro and bumpersensor
- targeting a 1000 euro budget for a mobile base robot which can navigate an environment


The robot revolution is happening and it's in need of more open and modular technology! Providing an open source platform to build a robot will help anyone having a robot solution in mind to jump start development for that solution. Not only a small robot for learn or play, but a real close to human size robot which can carry a significant load in order to perform a real world task. Making a modular and open platform will allow anyone to build this and change this to their own needs. The platform should be affordable, targeting a 1000 euro budget for a mobile base robot which can navigate an environment. This project focuses on the mobile base first, but adding generic end effectors or complete robotic arms is definitely the next step.


There aren't that many robot platforms out there that you can buy and start building your own robot. There are a *lot* toy-scale platforms, but somewhat larger, closer to human-size and able to carry a load, not so much. The ones that do exist either are targeting commercial use and are priced accordingly (~10K euro) or have other serious limitations. When I wanted to build my own robot a year ago and looked for a platform to build it on, there were basically two options which came close. The Turtlebot 2 which uses the Kobuki base and the Parallax Arlo platform. I had a budget in mind with of around 1000 euro. This already excluded the Arlo, which would take up the complete budget and then some, on the mobile base alone. I have some experience with the Kobuki in real life and was generally disappointed with the noise and small payload ability (~5KG) and the relative high price tag of 350 USD (without shipping). At the same time the 'hover'boards became popular, can carry a real load (~100KG), operate silently due to their brushless hub motors and are relatively inexpensive (~200 euro). I remembered seeing the VESC, an open source brushless electronic speed controller project (on Hackaday off-course) and the idea to combine them into a robot platform was born. I wanted to build a robot which I could use, but was also designed with some principles in mind, to allow the project to be open and reusable by others.


The applications are endless. The low price makes it feasible to have a fleet of robots doing specialized tasks. There are a lot of applications that are possible, which are built around a mobile base and do not require a robot arm yet. Here are some ideas:

  • camerabot or robotic tri-pod
  • smart trashcontainer which moves to a central location when it needs to be emptied
  • waiter bot serving drinks or snacks from a tray
  • smart storage container which picks up contents or brings its contents when needed
  • robotic furniture or walls to have a dynamic room layout
  • robotic (vacuum) cleaner
  • robotic lawn mower
  • endless surface CNC-bot
  • robotic (shopping) cart


To be truly modular there should be no limitations up front. The design should be extensible, but also allow parts of it to be replaced by something else. In the end building a robot should be as easy as building your PC, build a frame, add a power supply, wheels, sensors, computer and add or develop software.

  • Total physical modularity: it should be possible to change the appearance or design of the robot to meet a desired solution. This is accomplished with the use of T-slot profiles which allow you to rapid prototype the design of the robot to build the solution you need.
  • Total electronic modularity: instead of one big controller board which is designed up-front with the capabilities required the electronics is build around a modular power supply and modular electronics with separate USB controller boards for each input / output.
  • Total software modularity: the ROS driver is built around the ros_control library with a implementation of the wheel driver interface to allow controlling the wheels in different configurations. Currently the robot is designed as a differential drive mobile base, but with the wheel driver...
Read more »

  • 2 × 350W brushless DC hub wheel motor Can be harvested from a hoverboard
  • 2 × brushless electronic speed controllers (VESC)
  • 1 × 10S2P 36V battery Can be harvested from a hoverboard
  • 1 × T-slot profiles with mounting accessoires Various lengths depending on the design
  • 1 × USB hub I used a cheap 10 port USB hub to allow plenty of expansion possibilities

View all 9 components

  • MORPH base testdrive

    Roald Lemmens10/15/2017 at 20:33 0 comments
  • Panels

    Roald Lemmens07/28/2017 at 08:42 0 comments

    This is just a short update to show the result of added panels. I removed the additional supporting beams which were used to mount the USB hub and Up board. Instead these will be mounted on the panels saving some space. Although the idea is to add a fleece skin to the robot, the panels provide protection for the electronics and make for a more generic base.

    The panels are made from the same 8mm polyethylene as used before (a.k.a. Ikea chopping board). The panels slide in the slots with M4 bolts. The other sides have 5mm rods which provide additional support.

  • Design #5: Stronger enclosed base

    Roald Lemmens07/24/2017 at 08:35 0 comments

    At this point I had a design that worked pretty well. But still there were things I wanted to improve:

    • change the frame to be able to carry a load
    • protect the electronics
    • change to a more generic mobile base
    • improve the caster wheels ground clearance

    So I started another redesign. Which is actually a fancy word for saying I took it apart and started playing. Often I was assisted by my two fellow designers, my 8 year old daughter and 6 year old son, sharing a workspace together.

    I started changing the way the wheels were mounted. Before I focused on modularity having two separate wheel assemblies connected to the frame. But now I focused on creating a small frame which would distribute the load better.

    Read more »

  • Wheel encoder mount

    Roald Lemmens07/22/2017 at 08:26 0 comments

    For the wheel encoders I used the AS5047P development board. As a first attempt to mount the encoder on the new frame I used a piece of MakerBeam connected to two small angle brackets. While this somewhat worked, it relied on visual alignment. This was actually more guesswork since it's very hard to to see if the sensor was properly aligned. This needed some improvement, so I designed some brackets in OpenScad. Basic idea was to have an angle bracket with mounting slots to allow the positioning of the distance to the wheel and a sensorboard holder with mounting slots for further vertical alignment. At first I designed this as a 2 piece design, with the angle bracket as a single piece.

    Read more »

  • Source code morph stack

    Roald Lemmens07/21/2017 at 08:00 0 comments

    I've linked the main repository containing the source code for the morph stack for use in ROS. The stack consists of separate packages, each have their own repository but are linked as submodules from the main repository which is linked.

    • morph_bringup : contains launch files and parameters for bringing up the robot
    • morph_description : provides the robot model
    • morph_hw : provides the robot driver for creating a differential drive mobile base
    • morph_navigation : contains launch files and configuration parameters for using the navigation stack
    • morph_teleop : provides launch files for teleoperation of the robot using keyboard or X-box controller

    I've forked the VESC repository from the MIT-Racecar project in order to merge the commits of pull request 7 which contains changes to publish the rotor position. I've been testing this to get more detailed odometry.

    See the readme of the morph repository for installation instructions. This is very much a work-in-progress but at least it will show the current state of development.

  • Design #4: Improved concept

    Roald Lemmens07/18/2017 at 18:29 0 comments

    With good results from the encoder it was time to address some of the issues and do another (you guessed it) redesign. Let me start by showing the result first, for a change. I will go into the details after the break.

    Read more »

  • Encoder

    Roald Lemmens07/18/2017 at 07:57 0 comments

    In order to improve the odometry data I wanted to add an encoder. The downside of using a brushless DC outrunner hub motor is there is no shaft to mount an encoder to. The shaft fixed to the robot remains stationary and only the wheel turns. The VESC already had support for the AS5047 magnetic rotary sensor and I read a positive experience about that sensor. It seemed doable to mount a magnet to the side of the wheel, so I ordered some development boards. The development board contains the sensor mounted to a small PCB and a diametric magnet of 6mm diameter and 2.5mm depth.

    First step of testing the encoders was removing the RC filters on the hall sensor port as Benjamin describes very clearly in his video.

    Read more »

  • Design #3: Initial concept

    Roald Lemmens07/17/2017 at 08:30 0 comments

    At this stage I had a simple proof-of-concept, but with some flaws I wanted to address:

    • I didn't like the Turtlebot-shape of the robot, I wanted a more close to human size robot (around 1m50 / 1m60) which could carry a load.
    • The wheels mounting brackets were failing. The added weight of the old laptop caused the brackets to misform.
    • The old laptop I used was too slow to run gmapping in order to try to create a map and also had some Wifi reliability issues.
    • The VESC's were driving the motors in BLDC mode, causing a high-pitched noise while driving. I wanted to drive the motors in FOC (Field Oriented Control) mode, which should make them more quiet.
    • The large inrush current caused by the VESC's capacitor banks would trip the safety of the BMS integrated in the battery pack, which meant I couldn't use the switch to turn on the robot, but had to connect each VESC's power one by one.

    So it was time to start over and try a new design. Instead of just a test frame, I started building a first version of the concept I had in mind. Things were changing at a rapid pace and I should have documented better to have something more to show for it.

    Frame design
    I drilled 6mm holes in an 6x2cm T-slot profile beam and mounted the wheels with M6 bolts with the mounting blocks which were harvested from the hoverboard. The frame was made smaller and taller.

    Read more »

  • Design #2: Turtlebot-like test frame

    Roald Lemmens07/16/2017 at 17:48 0 comments

    For the next step, I wanted the robot to be controllable from ROS. I changed the initial design to be more Turtlebot-like to be able to hold a laptop running ROS.

    Changing the frame was the easy part, most of the work has gone into creating the ROS integration. Thanks to the MIT-Racecar project, there already was an open source VESC driver which I could use. This meant I didn't have to implement the serial communication which saved a lot of time. Because I wanted a modular solution I wanted to implement the driver using ros_control. In ros_control a robot driver exposes joints which can be controlled using a velocity, effort or position interface. For wheels this means we need to implement the velocity interface. The velocity interface accepts the desired target speed as a command (in rad/s) and reports the actual speed as feedback of the current state (also in rad/s off course). The joints are controlled using a controller implementation, for which ros_control already provides some, including a differential drive controller.

    Read more »

  • Design #1: Test setup

    Roald Lemmens07/15/2017 at 20:44 0 comments

    This has been a pet project for about a year now, and I would like to start by giving a short summary of the past design iterations. While having a general idea in my head, I didn't start with a clear end-design. Instead I focused on rapid prototyping each step to test each assumption along the way and iterate the design.

    I started out by harvesting the parts from the hoverboard.

    Read more »

View all 10 project logs

Enjoy this project?



Robin Fröjd wrote 2 days ago point

Got the VECS´s and motor running over ROS with your morph stack. :-) 

some questions you maybe can help me answer?

1. With hall sensors what Parameter for enabling rotor position publishing should I use? I saw that you use default="encoder"

2. When I try to echo the rostopic /right_wheel/sensors/core and rotor_position I get no values. Is this because of the default="encoder"?

3. Where Can I calculate this values

<param name="left_wheel_ikv" value="8.543328017" />
<param name="right_wheel_ikv" value="8.821034775" />
<param name="tacho_pulses_per_revolution" value="90" />

here is a video of the test:

many thanks for the ROS drivers! :-)

  Are you sure? yes | no

Roald Lemmens wrote a day ago point

Very nice progress! And cool project, by the way :).
Rotor position publishing is only possible with an encoder which provide an absolute rotor position, so it makes sense you get no values with the hall sensors. I should have kept support for using hall sensors in the code. I still want to do another test with hall-sensors instead of the encoders to see how it performs. I'll lookup the code I had and add support for both type of sensors. Hopefully I will get to this in the weekend.
I determined the 'ikv'-values by calculating the KV for the maximum dutycycle (I used 95%) for the input voltage. I used the values provided by the VESC for the voltage, ran the motor at 95% dutycycle (without load), noted the ERPM, converted the ERPM to RPM (dividing by the motor poles) and divided the RPM by the input voltage. So in short:

((ERPM @ 95%)/motor poles)/input voltage

The value is used to calculate the duty cycle based on the voltage. But there are probably better ways to do this :).  Feedback is always welcome!

- right motor:
    - @ voltage 41.6V => ERPM 0.95 duty cycle: 9814 => 344,35 RPM => 8,277665317 KV
- left motor
        - @ voltage 41.9V => ERPM 0.95 duty cycle: 9830 => 344,91 RPM => 8,231796675 KV

  Are you sure? yes | no

Robin Fröjd wrote a day ago point

thanks! :-) And thanks for answers. Let me calculate this values too see what I get. I tried changing the (encoder) to pid_pos and are receiving some values now when echoing the sensor/core. Haven’t looked into it more. My motors use internal pcb with 120 degrees hall sensors. 

So I’f I where to mount enconders where can I get the AS5047P? I found the AS5047D

And also some other AS5047 with different letters. Will VESC striclty only work with the P type?

I will not be able to mount the enconders on the wheels or the motor.  But I have place for them on the drive shaft that’s uses belt drive from motor (gearing the RPM down) do you think I can mount the enconders on the drive shaft?

Also did you modify the VESC in order to get the enconders to work? I looking for the best possible solution to get exact position.



  Are you sure? yes | no

Robin Fröjd wrote 3 days ago point

Got my new motors up and running now.

Any tips & suggestions to make them more silent and handle lower speeds better?  I am running FOC and Hall sensors.

  Are you sure? yes | no

Roald Lemmens wrote 3 days ago point

Looking at the VESC BLDC-Tool it seems you have measured the hall-sensors but the values are not applied, since the table for the hall sensors values show 255 only, but the table for the detected values show different values. Maybe applying (and for safety saving and restarting the VESC) will help. When I setup a new motor I always perform:

- 'Measure R and L', followed by 'Apply' in the same row

- 'Measure lambda' (I use 3A, 0.05 dutycycle for the hub motors I have)

- 'Calc CC'  followed by 'Apply'

Then detect encoder (at 3A) for the AS5047 I use, or in your case the Detect hall sensors. Finish with 'Apply' and 'Write configuration' . Then you should be able to test the settings.

  Are you sure? yes | no

Robin Fröjd wrote 3 days ago point

Thanks. The motor works fine now :)

The hall sensors is working and feeding me data. I will try out your ROS driver tonight and see how it works out :) 


  Are you sure? yes | no

Robin Fröjd wrote 03/12/2018 at 08:39 point

Love this project! What ROS driver did you use too control the VESC simultaneously? 

  Are you sure? yes | no

Roald Lemmens wrote 03/12/2018 at 11:20 point

I created a ros_control driver which controls the differential drive and uses the vesc_driver package from the mit-racecar project to control the individual wheels. You can check the github link and specifically the morph_hw package. There's still room for improvement to get the wheels to run at exactly the same speed and allow the robot to move in a perfect straight line.

  Are you sure? yes | no

Robin Fröjd wrote 03/12/2018 at 11:23 point

Thanks for the fast reply Roald, Let me have a look at the link. I am going to use two BLDC motor running VESC on my project. I will receive them on friday. Then I can test your package. :)

  Are you sure? yes | no

malvasio.christophe wrote 02/12/2018 at 07:37 point

with 2 motors omnidirectionnal any numbers of wheels chassis are possible

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates