close-circle
Close
0%
0%

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
close
This project aims to build an affordable modular robot platform using open technology.

Features
- 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

Why

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.

Background

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.

Applications

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

MORPH:

Modular
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?

Share

Discussions

Similar Projects

Does this project spark your interest?

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