openvmp / openvmp

Robotics platform for universal robots that can walk, drive, climb and join bodies to form even bigger robots.

OpenVMP

Join our Discord server!

Open Versatile Mobility Platform (OpenVMP) is a community project with the goal of making it possible for anyone to build multi-modal mobility robots using affordable off-the-shelf parts and open source software. This repository contains all the necessary software, bills of materials and assembly instructions.

The aim is to develop heavy-duty robots that can be controlled remotely. The platform allows anyone, anywhere in the world, to learn how to operate these robots, possibly through simulation environments. Once trained, users can easily operate robots belonging to others, without being limited by manufacturer restrictions or targeted audiences. This approach facilitates the rapid development and deployment of robotics without being impeded by profit or other motives.

These robots can complete tasks either independently or collaboratively. This means that a group of robots can work together in two ways: figuratively (each robot follows its own path to explore more territory) or literally (robots physically connect to form a larger robot).

This is the monorepo of the OpenVMP project. Some of the internal components are git submodules that are also designed to be equally usable as standalone ROS2 packages outside of OpenVMP. But other packages (where the name starts with openvmp_) are made exclusively for OpenVMP.

Key features

Multi-Modal Mobility

OpenVMP robots supports various modes of transportation, including:

• Wheeled driving on or off-road
• Quadrupedal walking or crawling
• Climbing cylindrical objects such as trees, poles, pipes, ropes and cables
• Climbing and driving inside pipes, ducts or tunnels
• Climbing warehouse shelving units

Individual Performance

OpenVMP robots are capable of performing basic mechanical tasks with their limbs, but their full potential is unlocked through the use of extension modules (see 'Modularity' section below). These robots can operate independently for extended periods of time while minimizing power usage when idle. One key application is sending individual OpenVMP units to perform ad-hoc tasks like reconnaissance, communication, supply, and delivery, while temporarily separating from the collective.

Collective Performance

OpenVMP units can improve their mobility by mechanically joining together and sharing resources for computation and communication. This versatility is evident in scenarios such as climbing artificial structures (e.g., buildings, industrial complexes, pipes, poles, fences, and barricades) and overcoming natural barriers (e.g., trees, ravines, and small cliffs).

Modularity

Each OpenVMP unit may have one or more payload modules, typically including:

OpenVMP units can be equipped with one or more payload modules, which typically include interchangeable front and rear modules. These modules enable the units to perform functional tasks using multipurpose or specialized tools, such as mechanical tools, inspection devices, liquid dispensers, or defense mechanisms. They are designed to be hot-swappable for easy replacement during missions.

In addition to the front and rear modules, OpenVMP units can also feature a top module. This module may contain advanced computing units, large robotic arms, extra power supplies, or other components that may significantly enhance capabilities of an entire swarm of robots. Unlike the front and rear modules, the top module is hardwired and cannot be hot-swapped.

What's included

This repository contains the software needed to simulate OpenVMP units, including simulation worlds designed to showcase some of their capabilities. Additionally, it includes some software required for operating real OpenVMP units. The remaining software and hardware blueprints for various OpenVMP unit types currently under development will be published here soon.

All materials in the OpenVMP repositories are available under the Apache 2.0 open-source license. To minimize the risk of patent trolls claiming minor improvements on OpenVMP's work, just in case, contributors have documented the features and ideas they've considered and planned in the claims.

More information

See the following documents for more info:

• How to build OpenVMP software
• How to run a simulation
• How to build a real OpenVMP robot
• How to deploy to a real robot
• Included ROS2 packages
• Roadmap
• License

openvmp's Issues

Add STL files to URDF for more realistic looks

The URDF visuals need to be replaced with STL files cut from the CAD model made in FreeCAD.

The CAD files are not yet in the repo to prevent blowing up the size of the repo until an efficient way to manage CAD files is found.
So the CAD files will be shared with the contributors ready to work on this issue.

Launch error package topic_tools not found

habecker@2023-05-19 10:19:08:~/ws/vmpforks/platform$ ros2 launch openvmp_robot robot.launch.py use_fake_hardware:=true
...
[ERROR] [launch]: Caught exception in launch (see debug for traceback): "package 'topic_tools' not found, searching: [...

Configuration instructions should be clearer

https://github.com/openvmp/openvmp/blob/main/docs/Development.md

• Section "OS prerequisites", part 1, is a copy of one of the 3 variants of the official Humble installation instructions (the debian variant), but the doc does not tell the user that it is a copy or which variant. Copies are either perfect or wrong; in this case, wrong: the line "apt install -y git curl gnupg lsb-release" specifies 3 pkgs that are not in the official instructions. Symptom 1: a user that already followed the official instructions and recognized this copy might not notice the 3 extra packages. Symptom 2: the addition of "git gnupg lsb-release" here suggests that those pkgs are an important requirement of ROS2 rather than of OpenVMP. Symptom 3: if the user has already installed ROS2 via the binary variant, then the remaining OpenVMP instructions for "ROS2 package prerequisites", which are Debian instructions, won't work (because Debian installation and binary installation use different directories). Solution: Instead of copying the official instructions, refer to them. Move the installation of the "git gnupg lsb-release" pkgs to the next paragraph.
• "The following OS packages are required for development and testing purposes." -> "We require these additional OS packages to develop and test OpenVMP."
• Section "ROS2 package prerequisites". "packages might be missing" suggests that the instructions up to this point have been a guess that no one tested. I suspect that the reason for this section is to help a user who didn't follow the instructions up to this point -- the user already has an arbitrary installation of ROS2. The first instruction is to install "ros-humble-desktop-full", which is an option in the official install; therefore, in the previous section, tell the user to choose that install option.

Repo names too generic to fork relative submodules

I was just adding these "Contributing" instructions to Development.md:

We recommend that you work in your own fork and submit pull requests from there. Since this repo includes several other openvmp repos as submodules, and since we define those submodules as relative URLs, your fork of this repo automatically refers to your forks of the submodule repos. However, you first need to create the forks on GitHub.

Problems:

1. If the contributor forks openvmp, then the relative URLs obligate the developer to fork each of the corresponding repos. I have a GitHub client script to do that, but...
2. Relative URLs work only if the contributor is able to create forks with the same names as the original repos. A generic repo name is more likely to be common, which increases the odds that the contributor already has a source or fork repo with the same name. Our current list is:

habecker@2023-05-16 16:28:55:~/tmp/openvmp$ grep 'url = ..' .gitmodules 
	url = ../serial.git
	url = ../modbus.git
	url = ../modbus_rtu.git
	url = ../stepper_driver_em2rs.git
	url = ../stepper_driver.git
	url = https://github.com/jbeder/yaml-cpp.git
	url = ../switch.git
	url = ../switch_r413d08.git
	url = https://github.com/fcastello/ansible-ubuntu-wifi.git
	url = ../remote_hardware_interface.git
	url = ../brake.git
	url = https://github.com/klintan/ros2_usb_camera.git
	url = https://github.com/mattanimation/ros2_berrygps.git
	url = https://github.com/mattanimation/RTIMULib2.git
	url = ../openvmp-models.git
	url = ../brake_switch.git
	url = ../serial_bus.git
	url = ../encoder.git
	url = ../encoder_amt21.git
	url = ../actuator.git
	url = ../microcontroller.git
	url = ../actuator_pwm.git
	url = ../gazebo_ros2_control.git
        # and from openvmp-models.gitmodules...
        url = ../openvmp-parts-gobilda.git

3. Notice gazebo_ros2_control. That's an openvmp fork of ros-controls/gazebo_ros2_control. A contributor who has something to add in that repo is likely to already have a fork of the ros-controls version. We should probably name is openvmp-gazebo_ros2_control.
4. I also notice that ROS uses underscores in their repo names. Style or substance?

Options

1. Maybe don't use submodules. I notice that the ROS build farm uses configurations and scripts to populate the workspace with the necessary clones. We could have a build repo that contains all of the configurations and scripts.
2. If we keep submodules, then the .gitmodules files are the configuration and git is the script. A contributor can modify the local copy of the configuration, but the trick is that they have to clone openvmp/opevmp first, then modify .gitmodules, then clone the submodules.
3. For either option 1 or 2, we should probably default to absolute URLs and leave it to the contributor to specify which repos to fork.

Fix physics parameters in URDF

The robot spawned in Gazebo starts jumping around when in contact with any surface.
The URDF file parameters need to be tweaked (such as joint and surface physics parameters) to fix the simulation.

Use RoboStack

Test OpenVMP on RoboStack.
Update development instructions to use RoboStack.