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

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 interface it's easy to extend to a different configuration if needed.

Open
Fully open technology, meaning:

  • open source software (also for firmware)
  • open source hardware
  • open design
  • open documentation
  • uses only open projects
  • has an open tool chain
  • has no dependency on a proprietary component for which there is no alternative

I think the VESC project is an excellent example of this. It's fully open source hardware and software, the toolchain is fully open: electronics design is made with Kicad, the BLDC-tool to program the VESC is also released as open source and the firmware is based on the open ChibiOS.
To give some contrast to this: the Turtlebot 2 has the 'open...

Read more »

  • Wheel encoder mount

    Roald Lemmens10 hours ago 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 Lemmensa day ago 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 Lemmens4 days ago 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 Lemmens4 days ago 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 Lemmens5 days ago 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 Lemmens6 days ago 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 Lemmens7 days ago 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 7 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