Design process for open public machinery

General Idea

Our goal of this project is to create a process to build machinery (in  this case a robot system) consisting of components such as software code, design files, controller hardware and build instructions in form of videos and boms.  Every component will be available for review on a open review tool and public repository such as GIT/Gerrit, see picture below. The public community can review every single component and add its approval to them. This means, all components are available in the repository in form of „commits“. „Commits“ can be downloaded by every community member, examined and reviewed in detail. At certain time spots we pick a number of „commits“ with positive review results, create a system from them and test it. During creation of the system, software components are compiled, design files are created by a 3D printer, and controller hardware are ordered automatically. Then we build the new robot upon these components. If we are able to build successfully the robot system and if it is passing all testcases, a new release is created from the picked commits. Then the picked commits are moved into the master repository of GIT for the public download.

design process
design process

The business case for this design methology and design process is to offer a service to the customer to conduct tests from a set of reviewed commits. We provide the resources and the knowledge to this service. After executing the above described process we inform the customer about the test results and the customer can precede improving the system based on the feedback we provide.

Commit dependencies

  • There is a dependency between design files and software code. Updated design files for the robot can cause a new robot geometry layout, therefore the robot’s inverse transformation needs to be adapted inside the software code. So in case there is a change in robot geometry, but the committer did not change in inverse transformation, then we do not pick the design file change. The committer must indicate the dependency between the design file commit and the software code commit.
  • We offer simulation code for simulation tests of newly commited software code. However new design files can cause a new robot geometry layout, so the simulation program must be adapted as well. We suggest to provide a configuration file of the robot’s geometry. We will not pick design file commits, if there was no adaption of the robot’s geometry configuration file.

Automatic testing

  • The first step is that Jenkins extracts reviewed „commits“ and compiles a new driver level of software. The driver is tested on simulation with testcases released in the repository as well.
  • Jenkins loads design files for the robot components automatically into 3D printer and it creates them.
  • Jenkins passes the „commits“ with new robot controller parts to a purchasing software and orders automatically the new robot controller parts.
  • The tester of the robot system assembles the robot with the newly created components (design files and robot controller parts), loads the compiled software to the controllers and tests the system.

Business Idea

  • The customer is asking us for a service to conduct tests from a set of reviewed commits. The commits can be exisiting commits or commits provided by the customer himself.
  • We provide the resources to conduct tests.
  • We retrieve the requested commits and apply them to a process in several phases:

1. First Phase

  • The customer selects the commited software code from our repository, and we pull the sofware code and create a driver from it.
  • We pull simulation software from the repository, if e.g. updated design files require this. This is the case when the design files cause a new robot geometry layout. A new simulation system is build from the new design files.
  • We run and test the driver against the simulation with testcases located in the repository.
  • In case simulation fails, we will create a list of errors and a list of suggestions for improvement (e.g. with a ticketing system) and hand them back to the customer.

If all tests pass in the first phase, we can move to the second phase:

2. Second Phase

  • In case the customer requires new controller hardware showed in „commits“, and the „commits“ passed the reviews, then Jenkins will pull the „commits“ from the repository and orders automatically the hardware components.
  • If there are new design files, Jenkins pulls the commits with design files from the repository and loads them into the 3D printer and it prints the updated parts.
  • From all newly created parts, we build the new robot system.
  • We run testcases against the real hardware. These are the same testcases, which we ran previously int Phase 1. against the simulation.
  • In case the test against real hardware fails, we create a list of errors and a list of suggestions for improvement and hand them back to the customer.

If the second phase passes all tests, then the tester is moving to the third phase:

3. Third Phase

  • We gather all „commits“ contributed in phase 1. and phase 2., and a new release level is created from the „commits“.
  • All „commits“ are merged into the master branch of the repository.

System Components

In the following you find a list of components which can be released into the git repository and a list of software components to set up the process. All components can be openly pulled. Also all components can be reviewed and added comments are shown publicly.

Control Software

  • UML Class Diagrams
  • UML Object Diagrams
  • inverse transformation algorithm
  • point to point movement algorithm
  • linear movement algorithm
  • control program
  • future topic: scheduler
  • future topic: preemptive multitasking code
  • testcases

Simulation software

  • mathematic models (Mathematika export files, source code)
    – pure static model
    – dynamic model (dynamics of motor)
  • configuration file for the robot’s geometry
  • future topic: graphical simulation elements

Robot controller

It is required that not one component is designed. It must be purchasable. Here comes the automatic order process into effect.

  • Controller hardware: Arduino, step motor controller
  • power supply
  • design description
  • complete layout plan with pure standard components.


  • components (design files)
  • 3D printer parts
  • carriages
  • step motors


  • GIT repository
  • Gerrit review tool
  • Jenkins, a continuous integration tool
  • A automatic part ordering tool