Low-cost+robotic+arm+control

=Low-cost robotic arm control= Currently, the assembly of fasteners (nuts, bolts and washers) is usually done by humans. In order to decrease production times and achieve a constant product quality, this process should be automated.

The RAAK project "(G)een moer aan!" is aimed at automating the assembly of fasteners. The aim of the project lies at small to medium size companies. Since they have limited production quantities, for an automated system to be a viable option, it must be possible to quickly adapt the system to new products and operating conditions. Also, the running costs need to be less than the cost of a human operator. In order to maximize flexibility, the automated system will be based upon a robotic arm, which can be equipped with multiple tools. However, most robotic arms used in industry are very expensive, and have fixed dimensions which limits their adaptability. In order to overcome this problem, a low-cost robotic arm needs to be designed which is flexible in itself: it must be possible to reconfigure the submodules to create a new robotic arm tailored at a specific application. For this purpose, a 5 Degrees Of Freedom (DOF) low-cost robotic arm is currently being developed (mechanically) by Stijn Stertefeld.



The goal of this sub-project is to design and implement a modular control system for robotic arms such as the low-cost robotic arm. The control system needs to be designed keeping reconfiguration in mind. It must be possible to use the control system with a wide variety of actuators, sensors and software packages. Also, it must be possible to configure the control system for the geometry of a specific arm.

=Control system design= Since it must be possible to quickly change the degrees of freedom of a robot system, each joint will be equipped with its own controller, referred to as the local controller. Each local controller follows a stream of commands in joint space, which it receives from a governing high level control system (performing tasks like motion planning). Each local controller will be equipped with a standardized interface for feedback and control. By using a local controller for each joint, the joint details are hidden from the governing high level control system. For example, when a new type of joint is implemented with a direct drive DC motor instead of a brushless DC motor, the motion planning system would not need alteration. Only the local controller would need an update. This also allows for a step-by-step development cycle, where functionality or specific component support can be added to the local controllers incrementally.

In order to support robotic systems with any number of degrees of freedom, it should be possible to connect an arbitrary number of joints to the high level control system. This functionality can be created by using a daisy chain bus. With such a bus an arbitrary amount of devices can be connected, only the software needs to know how many devices are actually in place. Daisy chaining is possible in a wide variety of protocols, from which Modbus-RTU is selected for this project. Modbus-RTU requires limited (and relatively simple) hardware to implement. Also, standard software libraries (for both server and client) are available, which will speed up the implementation of the local controllers. Modbus-RTU is well supported in industrial equipment which allows for the local controllers to be used with industrial equipment as well. It is also a likely candidate to be implemented on embedded systems (for example, the Arduino platform has a standard library for Modbus-RTU available), keeping the client’s options open to build an embedded motion planning system in the future. Modbus-RTU is built upon the RS485 standard which specifies the electrical connections. In order to implement Modbus-RTU on the local controllers, RS485 driver circuitry is needed.

The local controllers will mainly consist of a processing unit, running the control and communication software, and peripherals, connecting to physical devices. Since the goal is to keep the hardware offthe- shelf where possible, the Raspberry Pi Zero is selected as the processing unit. The Raspberry Pi has great support and lots of available resources while maintaining a small footprint. It is running Linux, which means there are lots of ready-to-run software modules available which greatly reduces the implementation effort. However, the Raspberry Pi Zero is a relatively young product, and delivery is still unpredictable. Therefore the choice is made to start development using a Raspberry Pi Model 3, which is electrically (and functionally) almost equal to the Raspberry Pi Zero. When developing an add-on board to add peripherals to the processing unit, only the functionality that is present on both Raspberry Pis will be used, so that the Model 3 can be replaced by the Zero when they become readily available. Even though the Raspberry Pi is a fully functional computer on its own, it is not suited for control applications yet. Specific hardware required by the local controllers (for example, RS485 & DXL bus support) will be added to the Raspberry Pi by designing an add-on board (or Hardware Attached on Top (HAT) as they are called in the Raspberry Pi community). This board will contain all hardware needed to transform the Raspberry Pi into a control module suited for this project.

Even though the Raspberry Pi has some IO functionality by itself, a separate micro controller will be added to the add-on board. This micro controller is used as an IO expander, and is necessary because the Raspberry Pi has very limited PWM functionalities and high speed digital inputs are needed (for example, to read the MAE3 encoders. Adding a separate micro controller to the add-on board makes it possible to unload time critical tasks from the Raspberry Pis main software, and adds enough IOs and PWM channels to support the required devices. Power parts (such as motor drivers) are specifically not included on the add-on board. Since the goal is to make a modular and flexible system, which can be reused on various projects, only the control signals are supplied by the local controllers. Power parts are generally very application specific, and including them on the add-on board would either result in less flexibility, or a much higher cost price because they are over dimensioned.

To enable the Raspberry Pi to sense the occurrence of an emergency stop (cutting power from the actuators), a power indication input is included in the design. When the power to the actuator is cut (or restored), the Raspberry Pi can take appropriate action to avoid unexpected behavior.



=More information= More information can be found in the report below