How to make a robot

The process of making a robot can be clearly separated to a sequence of steps as it is a evolution process with coupling and feedback. There is no perfect strategy for it.

• Design

1. This is the first step to implement your ideas. If you want to make a robot arm or a legged robot, you need to design the size of links and the geometric forms of each link. Then you may need some CAD tools such as Autodesk Inventor and Solidworks.

2. But it is difficult to decide the size of the robot since it also affects the hardware solutions. The most important part in hardware is the actuator. You need to synthesize the task objectives and the purchase of actuators. You may need multiple trials since the verification simulation is based on a system model that relies on rigid body dynamics and actuation limitation. Usually, people only use static mechanics to reduce the design variables design the robot and select the actuators.

• Modeling

Modeling is needed also in design, not only for control. When the design is decided, we can generate the urdf file, which is almost a standard file format to store the dynamic parameters of a robot, of the robot. If you use Solidworks to design the robot, it has a plugin to help you export the urdf file. The dynamic parameters in a urdf file are not accurate since they are directly exported from CAD models, unless they are calibrated by identification. Usually, they are good enough for inverse dynamic control since there will be feedback loop to guarantee stability. For serial robots, we have a lot of tools to compute the kinematic and dynamic models. Here are a brief list:

• RBDL

• Pinocchio

• RobCoGen

• KDL

All of those open-source modeling libraries have the urdf parser to load the urdf file and generate the kinematics and dynamics. For inverse dynamic control, you can easily use a function in the library to get the items of a dynamic equation. Some libraries also has the functionality of solving forward dynamics and giving derivatives for linearisation , for example Pinocchio.

If your robot has parallel mechanisms, unfortunately, there is no third-party modelling libraries on the hand because the internal constraints in the parallel mechanisms are various. You may want to have a look at Roy Featherstone's thought in Chapter 8 "Closed Loop Systems".

• Software development

1. Modules

The necessary modules for a robot include controller, planner and state estimator. A controller, a state estimator and the robot compose a close loop system which can be stable by tuning the controller parameters. The following graph shows a classical control framework where the feedback controller usually is a PD controller. The feedforward loop is usually the inverse dynamic control.

This kind of controller is called instantaneous controller since it only uses the one time step lookahead of x_d. That is different to optimal control where it generate a sequence of optimal control inputs and desired state knots for a forward time horizon.

2. Simulation

Simulation is necessary for robot development to avoid time and money waste. You should make sure everything works in simulation, and then try on real robots. You need a simulator to do simulation. The simulator is just a wrapper of physical engines with other useful plugins such as sensors etc. Using simulators, you can easily send system inputs to the physical engine where the forward dynamics is established by the simulator based on a set of parameters (such as the parameters in a urdf file). The common simulators are listed below.

3. Coding

Writing code is the main work as a roboticist. C++ has the advantage of execution speed so that C++ is usually the default programming language for real time control. It is difficult to achieve 400 Hz ~ 1K Hz control cycle when the code is written in Python. It is suggested to code in C++ for controllers and state estimators in simulation in order to avoid code transfer for real robot test. Here is typical framework for a robot

As we can see from the above figure, the motion planner usually runs at slower frequency compared to the controller and the state estimator. Instantaneous controllers are called low-level controllers. Motor servo controllers should be called embedded controllers running on embedded chips of the motor driver boards. Planners and instantaneous controllers are running on the same onboard computer. Because they usually have different frequency, we usually allot them to different main() functions which represent CPU threads. Consequently, we need a tool to communicate between threads (between controllers and planners). The tool is ROS. Of course, there are also other tools. But ROS is a popular tool for robotic research over the world.

• Hardware development

1. Motors

A Chinese company T-motor is a DC motor supplier for many robotic labs and companies. SOLO is using motors from T-motor. China has more such kind of motor companies. A problem with motors is the backlash of the gearbox. High manufacturing quality of the gear box is required. Otherwise, the backlash will be amplified at the end-effectors.

2. Encoders

Absolute encoders are needed for most of the robots since absolute encoders can remember the zero positions even without power-on. RLS is a good company for encoders.

3. Drives

You can purchase drive boards for DC motors. Also, you can make it by yourself. Elmo and Copley are welcomed in China because the small size of their DC motor drives. If the drive has EtherCAT ports, soem will be a handy driver software to install on your onboard PCs to realize the communication between control PCs and motor drives.

4. IMUs

IMUs are necessary for floating base robots (mobile robots). XSENS and MicroStrain are popular.

5. Onboard PCs

Intel NUC is the onboard PC of Laikago. NVIDIA TX 2 is also widely used. I recommend to install Ubuntu as the OS for onboard PCs as Ubuntu is the most popular OS for robotics.

6. Battery and BMS

7. Force/Torque sensors

Optoforce sensors and SRI f/t sensors are widely seen on robots.

8. Vision sensors

There are too many options for cameras and lidars. Stereo cameras are cheap. Lidars have larger shooting range.

• ROS vs Orocos vs Drake vs Julia

For me, those tool-kits are parallel. They have different advantages. ROS has easy communication systems that are composed of ROS topics, parameters etc. And the simulator Gazebo of ROS is also nice. Orocos starts from real-time control that is the core of Orocos. ROS relies on third-party modeling libraries whereas Orocos specified KDL as the modelling library. Drake was developed in Matlab. Now Drake is an independent robotic tool-kit wrapped with its own libraries. Julia is easy for coding, but it seems not good for real-time control.