low-cost robotic arm control system - wikispaces robotic arms are generally expensive, and provide...
TRANSCRIPT
L O W- C O S T R O B O T I C A R M C O N T R O L S Y S T E M
jeroen rikken
sn : 2206819
Company: Fontys University of Applied SciencesDepartment: Mechatronics LaboratorySupervisor: Onno Puts
Mentor: Falke HendriksCo-mentor: Frank SchoenmakersCohort: September 2016 - January 2017
9 January 2017 – version 2.0
Jeroen Rikken: Low-cost robotic arm control system, © 9 January 2017
A B S T R A C T
Robotic arms are generally expensive, and provide little support foradaptation to a specific use. But does it really need to be that way?Industry, as well as educational institutes, have shown interest in low-cost and adaptable robotic arms, which can be tailored to their needs.
This report focuses on the control system for such a robotic arm.Steps are taken to explore the requirements for the control system,and an architecture is designed to leverage adaptability, implementa-tion effort and functionality of the control system while maintaininga low unit cost.
Currently, a low-cost robotic arm is in development by the FontysMechatronics Laboratory to be used in the RAAK project "(G)eenmoer aan!". This project is aimed at the automation of assemblingsmall series products, which have a large number of fasteners. Thetask for the low-cost robotic arm is to assemble these fasteners quicker(and cheaper) than a human operator.
The control system designed in this project will be implementedon this low-cost robotic arm. The low-cost robotic arm’s mechanicaldesign will be done in another project [15]. Since the low-cost roboticarm is still in development and actuators and sensors need to be se-lected to finalize the mechanical design, the first part of this projectwill consist of determining actuator and encoder requirements for thelow-cost robotic arm. This will be done using a variety of modelingand simulation techniques. The second part of this project will con-cern the development of the control system itself.
From the work done in this project it can be concluded that someof the requirements for the low-cost robotic arm are in conflict. Ithas proven extremely difficult (if not impossible) to meet the client’srequirements within the expected cost price. Further research needsto be done on how specific requirements influence to cost price of thearm. This will enable the client to alter the requirements of the armin such a way that it will still be a viable product.
The control system design is finished, and is partially tested. Theremainder of the project will focus on further testing of the controlsystem. Since the control system is still in an early stage of devel-opment, numerous recommendations are given on possible improve-ments. The designs created in this project serve as a starting point forfuture versions of the control system.
iii
Apart from this message, this page is intentionally left blank
P R E FA C E
This report documents my graduation project on which I have beenworking from from September 2016 to January 2017. The project wasexecuted for the Mechatronics Laboratory of the Fontys University ofApplied Sciences, with the ultimate goal of creating a low-cost mod-ular control system for robotic arms. With this project focusing onthe development of robotic arms, I could not have thought of a bet-ter project to represent (and finalize, as this is my graduation project)the three pillars of the mechatronics study: mechanics, electronics andsoftware.
I would like to take this opportunity to thank my mentor (FalkeHendriks) and supervisor (Onno Puts) for their support in writingthis document, and my colleagues at the Laboratory for an seeminglyendless supply of components for my tests. I would also like to thankHenk Kiela for his critical look, and for replacing Onno in the finalweeks of the project. Special thanks goes out to my colleague StijnStertefeld, which comprised the other half of our two-man projectteam, for putting up with my endless questions on his mechanicaldesign.
Enjoy reading, or, even better, enjoy using the control system inyour own projects.
Jeroen Rikken
9 January 2017
Eindhoven - NL
v
Apart from this message, this page is intentionally left blank
C O N T E N T S
abstract iiipreface vlist of figures ixlist of tables xacronyms xi
i project description 1
1 introduction 2
2 assignment 3
2.1 Project goals . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Initial situation . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 Project boundaries . . . . . . . . . . . . . . . . . . . . . 5
2.4 Expected costs . . . . . . . . . . . . . . . . . . . . . . . . 5
3 method 6
ii low-cost robotic arm component selection 9
4 introduction 10
5 general research 11
5.1 Cost breakdown . . . . . . . . . . . . . . . . . . . . . . . 11
5.2 Required control rate . . . . . . . . . . . . . . . . . . . . 11
6 actuator selection 13
6.1 Selection approach . . . . . . . . . . . . . . . . . . . . . 13
6.2 Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.3 Selection results . . . . . . . . . . . . . . . . . . . . . . . 16
7 encoder selection 18
7.1 Primary encoder selection . . . . . . . . . . . . . . . . . 18
7.2 Secondary encoder selection . . . . . . . . . . . . . . . . 20
8 conclusions 22
iii modular control system design 23
9 introduction 24
10 requirements 25
10.1 Actuator support . . . . . . . . . . . . . . . . . . . . . . 25
10.2 Encoder support . . . . . . . . . . . . . . . . . . . . . . . 26
11 system architecture 27
11.1 High level control . . . . . . . . . . . . . . . . . . . . . . 28
11.2 Local controllers . . . . . . . . . . . . . . . . . . . . . . . 29
12 testing 33
13 conclusions 35
iv conclusions & recommendations 37
14 conclusions 38
vii
viii contents
15 recommendations 39
15.1 Short term recommendations . . . . . . . . . . . . . . . 39
15.2 Long term recommendations . . . . . . . . . . . . . . . 40
bibliography 43
v appendix 45
a internship contract 46
b dynamic model low-cost robotic arm 53
c use case simulation data 63
d resolution model low-cost robotic arm 65
e overview scara system 69
f component background research 71
g overview high level control system 82
h implementation add-on board 86
i interface design local controller 92
j control loop timing 94
k user manual local controller 97
l statement of originality 104
L I S T O F F I G U R E S
Figure 1 Project approach . . . . . . . . . . . . . . . . . . 6
Figure 2 Derivation actuator requirements . . . . . . . . 13
Figure 3 Actuator selection parameters . . . . . . . . . . 14
Figure 4 Use case effector path . . . . . . . . . . . . . . . 15
Figure 5 Derivation encoder requirements . . . . . . . . 19
Figure 6 Daisy chain architecture . . . . . . . . . . . . . 28
Figure 7 Hardware modules local controller . . . . . . . 30
Figure 8 Geometry low-cost robotic arm . . . . . . . . . 55
Figure 9 Joint actuation system (type 1) . . . . . . . . . 56
Figure 10 Joint actuation system (type 2) . . . . . . . . . 56
Figure 11 Simulation data - velocity per joint . . . . . . . 63
Figure 12 Simulation data - torque per joint . . . . . . . . 63
Figure 13 Simulation data - power per joint . . . . . . . . 64
Figure 14 Resolution worst case position . . . . . . . . . 65
Figure 15 Encoder placement options . . . . . . . . . . . 66
Figure 16 Impression SCARA system . . . . . . . . . . . 69
Figure 17 Geometry SCARA system . . . . . . . . . . . . 69
Figure 18 Board & bus selection chart . . . . . . . . . . . 80
Figure 19 Architecture motion planning . . . . . . . . . . 82
Figure 20 Add-on board design top . . . . . . . . . . . . 89
Figure 21 Add-on board design bottom . . . . . . . . . . 90
Figure 22 Timing overview control loop . . . . . . . . . . 95
ix
L I S T O F TA B L E S
Table 1 Estimated joint costs . . . . . . . . . . . . . . . 11
Table 2 Actuator selection data . . . . . . . . . . . . . . 16
Table 3 Expected resolution . . . . . . . . . . . . . . . . 20
Table 4 Geometric parameters low-cost robotic arm . . 54
Table 5 Joint orientation & reach low-cost robotic arm 54
Table 6 Product requirements low-cost robotic arm . . 54
Table 7 Joint reductions low-cost robotic arm . . . . . . 57
Table 8 Joint simulation data . . . . . . . . . . . . . . . 64
Table 9 Backward resolution calculation . . . . . . . . . 67
Table 10 Encoder preselection . . . . . . . . . . . . . . . 75
Table 11 Board and bus preselection . . . . . . . . . . . 80
Table 12 Pin mapping micro controller . . . . . . . . . . 87
Table 13 Cost price local controller . . . . . . . . . . . . 90
x
A C R O N Y M S
bps Bits Per Second
CAN Controller Area Network
DC Direct Current
DOF Degrees Of Freedom
EMC Electro-Magnetic Compatibility
FK Forward Kinematics
FPGA Field Programmable Gate Array
GUI Graphical User Interface
HAT Hardware Attached on Top
IC Integrated Circuit
IK Inverse Kinematics
IO Input Output
LED Light Emitting Diode
MCU Micro Control Unit
OEM Original Equipment Manufacturer
OSI Open Systems Interconnection
PCB Printed Circuit Board
PWM Pulse Width Modulation
ROS Robot Operating System
SBC Single Board Computer
SCARA Selective Compliance Articulated Robot Arm
SD Secure Digital
SDK Software Development Kit
SMD Surface-Mount Device
SOM System On Module
SOC System On a Chip
xi
xii acronyms
TTL Transistor-Transistor Logic
SPI Serial Peripheral Interface
UART Universal Asynchronous Receiver/Transmitter
URDF Universal Robot Description File
USB Universal Serial Bus
VAT Value Added Tax
Part I
P R O J E C T D E S C R I P T I O N
1I N T R O D U C T I O N
Currently, the assembly of fasteners (nuts, bolts and washers) is usu-ally done by humans. In order to decrease production times andachieve a constant product quality, this process should be automated.The RAAK project "(G)een moer aan!"1 is aimed at automating theassembly of fasteners.
The aim of the project lies at small to medium size companies. Sincethey have limited production quantities, for an automated system tobe a viable option, it must be possible to quickly adapt the system tonew products and operating conditions. Also, the running costs needto be less than the cost of a human operator.
In order to maximize flexibility, the automated system will be basedupon a robotic arm, which can be equipped with multiple tools. How-ever, most robotic arms used in industry are very expensive, and havefixed dimensions which limits their adaptability. In order to overcomethis problem, a low-cost robotic arm needs to be designed which isflexible in itself: it must be possible to reconfigure the submodulesto create a new robotic arm tailored at a specific application. For thispurpose, a 5 Degrees Of Freedom (DOF) low-cost robotic arm is cur-rently being developed (mechanically) by Stijn Stertefeld [15].
The goal of this sub-project is to design and implement a modularcontrol system for robotic arms such as the low-cost robotic arm. Thecontrol system needs to be designed keeping reconfiguration in mind.It must be possible to use the control system with a wide variety ofactuators, sensors and software packages. Also, it must be possible toconfigure the control system for the geometry of a specific arm.
To get an idea of the structure of this report refer to Chapter 3.
1 http://www.sia-projecten.nl/projectenbank/project/geen-moer-aan
2
2A S S I G N M E N T
2.1 project goals
The goal of this project is to design and implement a low-cost anduser friendly robotic arm control system. In order to allow for quickreconfiguration of the end products (the low-cost robotic arms) thecontrol system must be modular on various levels. More informationon the assignment can be found in Appendix A.
To reach the project goals, the project is broken down into sev-eral sub-projects, each with their own requirements. The next sectionsgive a more in depth overview of the goals of each sub-project.
Component selection low-cost robotic arm
To finalize the mechanical design of the low-cost robotic arm, actua-tors and encoders need to be selected. The first part of the project willfocus on deriving the requirements of the actuators and encoders, aswell as the selection of suitable parts. This is done in close coopera-tion with the mechanical engineer of the low-cost robotic arm (StijnStertefeld).
Control system design
The goal of this sub-project is to design and implement a controlsystem suitable for low-cost robotic arms. Since it is to be expectedthat the low-cost robotic arm is not finished prior to the end of theproject, the control system should be implemented and tested on theSelective Compliance Articulated Robot Arm (SCARA) system, whichis supplied by the client (see also Section 2.2).
The control system has the following requirements:
• Robot level modularityIt must be possible to add and remove joints to a robotic system
• Joint level modularityIt must be possible to use the control system with multiple typesof actuators and sensors
• Robot Operating System (ROS) integrationMotion planning must be implemented using ROS
• Electro-Magnetic Compatibility (EMC) normsThe system must not exceed EMC norms when in operation
3
4 assignment
• ShieldingPhysical parts of the control system must be shielded from theuser
• Tool controlThe control system must support tool control
User interface design
When there is sufficient time a generic user interface will be designedto control and program robotic arms. First, a Graphical User Inter-face (GUI) will be designed which can be used to program the arm foruse in a production environment. The GUI has the following require-ments:
• User friendlinessProgramming the robotic arm must be user friendly and easy.The RAAK project describes this requirement as "smartphonelevel user friendliness"
• Set and recall posesIt must be possible to set and recall robot poses using the GUI
• Tool controlIt must be possible to control a tool using the GUI
• Action sequencesIt must be possible to create sequences of actions, to create com-plex programs
• Handling of exceptionsException handling must be simple and clear
Besides GUI based programming of the robot, a "drag and hold" (orgravity compensation) method is desired. With such a method itshould be possible to move the arm to a position by guiding it byhand. The position can then be stored and used in programming.Such a method is incorporated at various robot systems in the lab,and it should be investigated how (and if) this can be integrated inthe modular control system as well.
2.2 initial situation
At the start of the project, two low-cost robotic arms are supplied asimplementation targets: the low-cost robotic arm designed by StijnStertefeld [15] and a SCARA system which was designed in previouslab projects. Both arms lack a complete control system. It must bepossible to employ the control system designed in this project on
2.3 project boundaries 5
both systems, and they will be used to derive requirements for themodular control system.
The mechanical design of the low-cost robotic arm will overlapwith this project, and this project must yield recommendations forthe actuators and sensors needed. These recommendations can thenbe used to finalize the mechanical design of the low-cost robotic arm.
The SCARA system is mechanically functional yet it is still lacking aproper control system. Since this system is already mechanically com-pleted (including actuators and encoders) at the start of the project,this system will be used to test the control system.
2.3 project boundaries
The following tasks are specifically out of scope of this project:
• Mechanical design of a robot arm
• Tool design
• Design of an embedded kinematics solver
• Design of the safety system
2.4 expected costs
Since one of the goals of the project is to design a low-cost control sys-tem, component cost will be a major selection factor. At the start ofthe project, it is unknown what the lowest possible cost price is, there-fore there is no strict budget set. As a guideline, the project owner ex-pects the total cost price of the control system (when applied on thelow-cost robotic arm, including actuators and encoders) to be under€2000,–.
3M E T H O D
As mentioned in Section 2.1, this project can be broken down intomultiple sub-projects. Since the GUI design is only done when thereis sufficient time, this is not taken into account in the initial planning.
Research on the low-cost robotic arm and the design of the con-trol system can be seen as two separate sub-projects, which inter-act loosely with each other. For example, the requirements followingfrom the research will be used in the control system’s design process.The general approach to the sub-projects can be seen in Figure 1.
Research on the low-cost robotic arm will start by modeling thearm’s mechanical properties. The requirements for the actuators andencoders will be defined by simulating use cases, which will be de-fined in consideration with the client.
The design of the control system will start by defining functionalrequirements. This will result in a basic system architecture. Usingthe component requirements generated by the research, suitable com-ponents will be selected. With these components, the final design iscreated which will be implemented and tested on the SCARA system.
Figure 1: Project approach
6
method 7
This report is structured in parallel with this method. First the re-quirements for the actuators will be derived in Part ii. Then, the de-sign for the control system is discussed in Part iii. This is followed bythe project conclusions and recommendations par:conclusions.
Apart from this message, this page is intentionally left blank
Part II
L O W- C O S T R O B O T I C A R M C O M P O N E N TS E L E C T I O N
4I N T R O D U C T I O N
In order to finalize the mechanical design of the low-cost robotic arm,actuators and encoders need to be chosen. The goal of this sub-projectis to derive requirements for these components using the mechanicalproperties of the low-cost robotic arm. These components can then beappended to the mechanical design. Since choosing specific modulesalters the mechanical design itself, this will be an iterative processwhich will take place in close cooperation with the mechanical engi-neer designing the low-cost robotic arm [15].
Since robotic arms are complex systems, with a lot of interdepen-dent parameters, the general approach will be to derive requirementsbased on use cases. These will be defined in consideration with theclient, and combined with modeling and simulation, this will resultin a set of requirements for the components. When applying this pro-cess, there are slight differences in the approach for actuator and en-coder requirements (see also Chapter 6 and 7), therefore they are han-dled separately.
Besides actuators and encoders, this research gives some indica-tions for additional components, such as the joint’s control systems.
10
5G E N E R A L R E S E A R C H
5.1 cost breakdown
Because the arm is aimed to be low-cost, the cost of components willbe a major factor in the selection process. In order to start selectingcomponents, a rough estimate is made for the costs of each compo-nent (see Table 1). These estimates are by no means fixed, but howeverdo give a fair indication of the budget’s breakdown. The expected to-tal joint cost is specified by the client (see also Section 2.4). Since thefirst joints will need far better components (more motor power, betterencoder resolution) than the latter joints, it can be expected that someof the budget for the latter joints will move to the first.
5.2 required control rate
Because the effector needs to move with a speed of v = 1000mm s−1
and the maximum error is e = 0.2mm, the control rate should be min-imally v
e = 5000Hz and preferably an order of magnitude higher, inorder to allow for compensation. If the control rate is exactly 5000Hz,the best possible performance is that the desired position is reachedexactly in time, but there will be no room for compensation if theposition is not reached exactly in time, resulting in an error greaterthan 0.2mm and a speed slightly higher or lower than 1000mm s−1
(depending on lagging or overshooting behavior).At this point only limited information is available on the dynam-
ics of the low-cost robotic arm. For example, it is unknown wherethe eigen frequencies of the arm are placed. Until this information
product price
Actuator €200,–
Encoders €100,–
Actuator driver €50,–
Control board €50,–
Total joint cost €400,–
Table 1: Estimated joint costs
11
12 general research
becomes available, there will be no further research on the frequencybehavior of the arm.
6A C T U AT O R S E L E C T I O N
In order to find suitable actuators, the minimum requirements needto be known. The movement of the effector is usually achieved bymovement in multiple joints, which can boost each other (for exam-ple, when two joints are rotating in the same direction) or countereach other (for example, when two joints are rotating in opposite di-rections). Since multiple joints need be evaluated at once, the choiceis made to define models and use cases which can be simulated tofind the actuator requirements.
It is expected that this approach results in a better understandingof the requirements for each actuator than calculating the require-ments based on single joint movement. This reduces the risk of overdimensioning the actuators, which could lead to a higher cost price.
6.1 selection approach
There are several steps that need to be taken to derive actuator re-quirements. First, use cases need to be defined. These use cases definethe arms parameters, as well as a description of the effector’s motionin 3D space. To get an indication for the actuator’s requirements, asimple worst case scenario is used (see Section 6.2). The use case isfirst to be translated into an effector-space motion profile (see Sec-tion B.3). Using an Inverse Kinematics (IK) solution (see Section B.1.4)joint-space motion profiles are calculated out of the effector-space mo-tion profiles. The joint-space motion profiles describe how each jointneeds to rotate over time to comply to the desired effector motion.The joint-space motion profiles are used to drive a dynamic simula-tion (see Section B.2).
The simulation yields the torque (and power) required by each jointto comply to the motion profile. Using the reductions present betweenthe actuators and the joints (also referred to as the joint actuationsystems, see Section B.1.2.4) the requirements for the actuators canbe calculated. A graphical depiction of this process can be found inFigure 2.
Figure 2: Derivation actuator requirements
13
14 actuator selection
It is worth noting that the arm’s links and joint actuation systemsare currently considered to be infinitely stiff and exempt of frictionlosses. The inertias of the actuators and joint actuation systems is ne-glected as well. This is assumption is made to simplify (and speedup) the calculation of actuator requirements. Due to these simplifica-tions the actuator requirements are only to be used as an indication.Either they should be appended with a safety factor to compensatefor non-ideal components, or the models should be improved in thefuture (which would be the preferred option).
In order to get an indication for which actuators are suitable, sev-eral parameters can be evaluated. Usually, an actuator’s capabilitiesare specified using a torque-speed graph (as shown in Figure 3). Sev-eral points on this graph can be checked for compliance with thecalculated requirements, which gives a fair indication of an actua-tor’s suitability. Of course there are many other actuator parameterswhich are of importance, for example, frequency behavior or rotor in-ertia. Yet, these parameters are not necessarily needed for the initialindication. When the arm’s models are improved in the future, it isrecommended that these parameters are evaluated as well.
Stall torque (Ts) can be defined using the static load on an actua-tor when the arm is in full extension. This would be the worst casescenario where the arm is barely moving, but the actuator would stillneed to supply torque to support the mass of the arm. Two otherpoints of interest are the maximum torque and velocity. These valuesfollow from the maxima found in the simulation data. Together withtheir counterpart (for example, Tmax and its counterpart ω@Tmax) itcan be verified that an actuator is capable of coping with these max-ima. In general, a good indication of the actuator’s suitability is themaximum power it can deliver. The required power can be calculatedfrom the simulation data as well.
Figure 3: Actuator selection parameters
6.2 use cases 15
6.2 use cases
The robot’s reach is separated in two zones: the full reach and theoperating zone. The operating zone is set in consideration with theclient (see also [15]) and is specified as a bounding box in which tearm needs to comply to the velocity requirements (see Table 6). Thisdoes not mean that the arm is unable to operate outside this zone,but outside of this zone it will be significantly slower.
As an initial use case, the test path is specified as a square trajectoryon the far end of the operating zone. A detailed drawing of the effec-tor’s path can be found in Figure 4. The path is drawn as seen fromthe base of the robot, looking past the X axis (see Figure 8). The ef-fector will be kept perpendicular to this plane. When traversing overthis path, the acceleration and deceleration of the effector are at theirmaxima. The effector stops on each corner of the test path.
Figure 4: Use case effector path
This specific test path is chosen because the influence of static loadson the joints is at its maximum (due to the maximum extension ofthe arm). Also, the acceleration and deceleration are equal to themaximum requirement. The arm accelerates and decelerates in fourdirections, which causes the dynamic loads to change sign. In thesimulations, the arm is loaded with its maximum payload. This usecase serves as a good worst case scenario, and is useful to generatean indication for the actuator requirements. Further use cases can bedefined to better understand the limitations of the arm, yet, since the
16 actuator selection
j1 j2 j3 j4 j5 unit
Ppeak 40.12 101.65 56.05 15.37 1.81 W
Ts 4.31 1.73 6.99 2.28 N m
Tmax 8.82 7.14 2.86 2.86 2.34 N m
ω|Tmax5.62 4.65 0.71 0.57 0.55 rad s−1
n|Tmax50.00 44.00 7.00 5.48 5.25 min−1
ωmax 8.70 16.30 30.25 2.03 0.97 rad s−1
nmax 83.00 156.00 289.00 19.39 9.23 min−1
T |ωmax 0.48 3.90 1.46 5.86 0.20 N m
Table 2: Actuator selection data
goal of this project is to find out the actuator requirements no furtheruse cases are defined at this point.
6.3 selection results
Simulation of the use case defined in Section 6.2 yields a set of jointrequirements. Using the reductions listed in Section B.1.2.4 and theinformation supplied by [15], the requirements for the actuators arecalculated out of the joint requirements. The calculated actuator re-quirements are listed in Table 2. The original joint requirements arelisted in Appendix C.
With the requirements given in Table 2 and the background re-search on various actuator types (see Section F.1), it can be concludedthat high end actuators are needed to comply to the arm’s require-ments. Especially joints one, two and three require high powered ac-tuators. It is to be expected that the cost price for these joints willgreatly exceed the expectations of the client.
This leads to the conclusion that some requirements are in con-flict. In order to find out which requirements can be altered, fur-ther research is needed. Some quick simulations show for examplethat lowering the payload from 5 kg to 3 kg greatly reduces the re-quired torque (and thus the cost price of the actuators), since thedynamic loads on the actuators are reduced greatly (less torque andless power). Decreasing the reach of the arm reduces peak torque, yetrequires the same power. This is due to the fact that when the reach isdecreased, the torque is lowered significantly. But when a test path ofthe same size is traversed, the arms joints need to move significantlyfaster. Roughly, the torque advantage and speed disadvantage seemto cancel each other out (in a simulation shortening the arms reach to
6.3 selection results 17
800mm, without lowering the masses of the links). It is to be expectedthat the benefits of shortening the reach of the arm prove to be morebeneficial when the mechanical design of the arm is updated com-pletely (also taking into account the lower mass of the links). Also, itwould be possible to add balancing springs to certain joints. As can beseen in Figure 12, the torques on joint two and three are not centeredaround zero because of the influence of static loads. This results inhigh peak torque requirements. Using balancing springs it could bepossible to center the torque profile around zero, reducing the peaktorques and therefore the actuator requirements.
Future research should focus on the influence of various designparameters on the cost price of the arm, so that the client can decidewhich requirements can be altered.
7E N C O D E R S E L E C T I O N
In order to find suitable encoders, there are two important selectioncriteria: the maximum velocity of the measured axis and the requiredresolution. The maximum velocity follows from the simulations donein Chapter 6. Encoders can be mounted on various positions in thejoint actuation system (for example, either on the joint’s axis or onthe actuator’s axis, see also Section D.2). For the following calcula-tions the encoders are assumed to be mounted on the actuator’s axiswhere possible, taking advantage of the reductions in the joint actua-tion systems to enhance the joint’s resolution. Therefore, the encodersshould be able to cope with the actuator’s peak velocity (see Table 2).
Generally, to avoid the need for recalibration every time the armis used, the encoders must be absolute. This will result in safer op-eration of the arm, since there will be no movements required tohome the encoders. The component selection is limited to absoluteencoders.
Mounting the encoders on the actuator axes breaks absolute behav-ior. For example, when the joint axes rotate a single time, the actuatoraxes rotate multiple times. At startup, there is no way for a controlsystem to determine what the current number of rotations is. To over-come this problem, secondary absolute encoders are needed on thejoint axes to determine the rotation count of the actuator axes. Theencoders mounted on the actuator axes will be referred to as the pri-mary encoders, since they determine the resolution of the arm. Theencoders mounted on the joint axes will be referred to as the sec-ondary encoders.
The next sections give information about the selection procedurefor the primary and secondary encoders.
7.1 primary encoder selection
7.1.1 Selection approach
The function of the encoder mounted on the actuator’s axis is to givethe arm its required resolution. The resolution requirement of the armcan be seen as the maximum sphere in which position uncertainty isallowed. For example, for every requested position of the effector,a sphere around that position with radius r (r being equal to theresolution requirement of the arm) can be defined. As long as theactual position of the effector remains within the sphere, the armcomplies to its resolution requirement.
18
7.1 primary encoder selection 19
In order to determine the minimum encoder resolution for eachjoint, the arm is placed in a worst case position. The arm is placedat full extension with joint two rotated 90° around the Y axis. In thisposition the influence of joint one on the resolution of the arm isat its maximum (see Appendix D). The arm is built out of severalindependent links, working in different directions. In the worst casescenario, they rotate in two planes (XY for joints one and five andXZ for joints two, three and four). The uncertainties in each jointcombine to a position uncertainty in their respective plane. This isshown graphically in Figure 14. The separate uncertainties of eachplane combine to one total position uncertainty.
Because multiple joints influence the position uncertainty in a sin-gle plane, the resolution requirements of the encoders cannot be cal-culated mathematically (for each resolution of the arm multiple solu-tions exist). Therefore, an iterative process will be used. First, an in-dication for the resolution requirement for each joint is calculated byassuming the rest of the arm (both the links and the joints) stiff. Thisgives an indication for the individual encoder requirements. Then, fora limited selection of encoders, the expected resolution of the arm canbe calculated in order to verify that the encoder selection set meetsthe arm’s requirements. If the arm’s requirements are not met, someencoders can be replaced by more accurate versions in the calcula-tions. This process can be repeated until the arm’s requirements aremet. A graphical depiction of this process is shown in Figure 5. Whenselecting components, as a rule of thumb, the influence of the jointsclosest to the base will be of most influence on the arm’s resolution,since they work over the longest length.
Figure 5: Derivation encoder requirements
7.1.2 Selection results
Based on background research (see Section F.2) two encoders are pre-selected for use on the low-cost robotic arm: the AMT20 from CUIand the MAE3 from US Digital. Both encoders have a resolution oftwelve bit (4096 ticks per revolution) and fall in the sub €100,– priceclass, making them suitable for this application. Encoders with betterresolution exist (mostly optic types), yet they are considerably moreexpensive.
20 encoder selection
j1 j2 j3 j4 j5 unit
Ticks 4096 4096 4096 4096 4096
Reduction 1:9 1:16 1:16 1:1 1:1
fenc 5.21 5.48 4.99 1.42 0.22 kHz
Arm length 1076.50 1076.50 529.00 140.00 46.50 mm
Influence 0.18 0.10 0.05 0.21 0.07 mm
Plane XY XZ XZ XZ XY mm
Resolution 0.45 mm
Table 3: Expected resolution
Using the equations in Section D.4, the expected resolution of the armcan be calculated when the selected encoders are used. The resultsare shown in Table 3. The minimum update frequency (fenc) is basedon the resolutions of the encoders and the velocity requirements forthose encoders (equal to the actuator velocity requirements as listedin Table 2).
From these calculations it can be concluded that the clients’ reso-lution requirement cannot be met within budget. A better resolutionfor the arm can be reached by selecting encoders with a higher resolu-tion, which would require a larger budget, or by decreasing the reachof the arm. Shorter links lead to smaller influences of each encoderon the resolution of the total arm, making it more precise with thesame encoder type.
7.2 secondary encoder selection
7.2.1 Selection approach
The function of the encoders on the joint axis is to indicate the cur-rent rotation count. This indication is only needed at startup, or insome error cases. It is not necessary to continuously read these en-coders, therefore they do not have to be able to cope with the joint’saxis maximum velocity. The resolution requirement of these sensorsis determined by the reductions between the actuator’s axis and thejoint’s axis. For example, for joint one the reduction would be 1 : 9
(see Section B.1.2.4), so, for one rotation of the joint, nine rotationsneed to take place, requiring only a resolution of nine ticks per revo-lution on the joint’s encoder to correctly indicate the current rotationcount.
7.2 secondary encoder selection 21
7.2.2 Selection results
Given that the secondary encoders require limited speed and verylimited resolution, these encoders could be custom made for theserobot to minimize cost price. For example, for joint one, the repeatabil-ity required is nine ticks. This can be encoded using 4 bits (log2(9) =
3.17 ≡ 4 bits). A simple four bit encoder with nine absolute positionscan be built out of a laser cut disk with a four bit binary code cutout, combined with four Light Emitting Diode (LED) - photo transis-tor pairs. The cost price of such a system would be far less than thatof an of the shelve product, with limited engineering effort.
8C O N C L U S I O N S
After researching requirements on the actuators and encoders, it be-came apparent that the requirements of the client are very difficultto realize with the expected budget. It can be concluded from thisresearch that it is needed to do additional research on how specificrequirements of the arm influence the component costs. This infor-mation can then be used to alter the requirements in such a way thatthe low-cost robotic arm will still be a viable product. Also, thereare some opportunities to enhance the mechanical design (withoutaltering any requirements), for example by reducing the weight ofthe arm itself or by adding balancing springs to decrease actuator re-quirements, which should be investigated further prior to making thefinal actuator selection.
In consideration with the client, the choice is made to focus theremainder of the project on the design and implementation of themodular control system (as described in Part iii), instead of doingmore research on the specifics of the low cost robotic arm. This will bedone by future project teams which can use the research and modelscreated in this project as a starting point.
22
Part III
M O D U L A R C O N T R O L S Y S T E M D E S I G N
9I N T R O D U C T I O N
The goal of this sub-project is to design and build a modular controlsystem. The modular control system must be capable of controllingrobotic arms, and it must be possible to adapt it to a variety of sys-tems, with different geometric arrangements and built with differentcomponents. Initial implementation and testing of the control systemwill be done on the SCARA system present in the laboratory (see Sec-tion 2.2).
The control system design will consist of a complete solution, frommotion planning implemented in ROS, up to the control and use ofactual actuators and encoders. As noted in Section 2.2, the design ofa GUI will be out of scope.
The first step in the design process will be to list the requirementsfor the modular control system. The requirements follow from thecomponent selection for the low-cost robotic arm (see Part ii), as wellas from the specifications of the existing SCARA system (see also Ap-pendix E). However, the goal of the design will be to keep it as flexibleas possible, it should be possible to use the designed modules in otherprojects as well.
With the requirements known, the system architecture will be de-fined. The system architecture defines the general components needed(and their arrangement) to build the modular control system as awhole.
With a defined system architecture, the individual components inthe architecture can be designed, which ultimately leads to the imple-mentation and testing of the complete modular control system.
24
10R E Q U I R E M E N T S
The modular control system must be capable of converting high levelinputs (such as commands given by an operator) to physical motions.The main focus of the design will be te make the system as modularand flexible as possible. It must be possible to configure the controlsystem for a variety of robotic systems, with different tasks. On arobot level this means that it must be possible to quickly reconfigurerobotic systems (that is, adding or removing DOFs by changing thenumber of joints).
On the joint level, multiple joint types must be supported (mainlyprismatic and revolute joints). To control these different joint types,multiple types of actuators (see also Section 10.1) and multiple typesof encoders (see also Section 10.2) must be supported.
Besides controlling the motion of joints, it should be possible tointegrate tool control as well, as this is a common function amongstrobotic arms.
Within the higher levels of the control system, some form of motionplanning is needed. Motion planning must be implemented in ROS
(as requested by the client). However, for future projects it might benecessary to perform motion planning (or individual joint control)from an embedded device. This must be taken into account in thedesign process.
10.1 actuator support
The SCARA system is built with Dynamixel MX64 and AX12 servosfrom Robotis (all Transistor-Transistor Logic (TTL) types, see also Ap-pendix E). TTL type Dynamixel servos are controlled using a half-duplex serial connection and a custom communication protocol (seealso Section F.1.5.1).
Joints one to three of the low-cost robotic arm will most likely bebuilt with either directly powered or brushless Direct Current (DC)motors (see also Section 6.3). For joints four and five Dynamixel ser-vos will be used (see also [15]).
Directly powered DC motors are usually controlled using a PulseWidth Modulation (PWM) signal (determining the speed) and a digitalsignal (determining the direction of rotation). Brushless DC motorscan be driven directly by reading a set of hall sensors and drivingthe motor’s coils (the number of inputs and outputs depends on thenumber of phases the motor has, see also Section F.1.3), or by using
25
26 requirements
a smart motor controller which is connected using some form of acommunication protocol.
10.2 encoder support
The SCARA system is built with MAE3 encoders (12 bit PWM version)from US Digital (see also Section F.2.2). The MAE3’s value can beread by measuring the duty cycle of the PWM signal generated by theencoder (a resolution of at least 1µs is needed for this task).
During the research on the low-cost robotic arm, the AMT20 fromCUI (see also Section F.2.2) was selected as a viable option for thelow-cost robotic arm’s final design. This encoder is controlled usinga Serial Peripheral Interface (SPI) interface. Since this is a likely candi-date for the low-cost robotic arm, the modular control system shouldat least have a spare SPI interface (and connector) to support thesedevices in the future.
Besides these two specific types of absolute encoders it is wise tosupport incremental quadrature encoders as well. This is used by theSCARA system’s linear slide (see also Appendix E) and is a commonoccurrence in motion control systems. For incremental encoders atleast two digital inputs are needed. Usually a third signal (or refer-ence pulse) is present which indicates that a full revolution has oc-curred, This should be supported as well. The SCARA system’s linearslide also has such a reference pulse, only it indicates the travel often millimeters instead of a full revolution. It is worth mentioningthat the SCARA system’s linear slide is also equipped with two limitswitches. These should be monitored as well, to prevent damage tothe components of the linear slide.
11S Y S T E M A R C H I T E C T U R E
Since it must be possible to quickly change the degrees of freedom ofa robot system, each joint will be equipped with its own controller, re-ferred to as the local controller. Each local controller follows a streamof commands in joint space, which it receives from a governing highlevel control system (performing tasks like motion planning). Eachlocal controller will be equipped with a standardized interface forfeedback and control. By using a local controller for each joint, thejoint details are hidden from the governing high level control system.For example, when a new type of joint is implemented with a directdrive DC motor instead of a brushless DC motor, the motion planningsystem would not need alteration. Only the local controller wouldneed an update. This also allows for a step-by-step development cy-cle, where functionality or specific component support can be addedto the local controllers incrementally.
In order to support robotic systems with any number of degreesof freedom, it should be possible to connect an arbitrary number ofjoints to the high level control system. This functionality can be cre-ated by using a daisy chain bus. With such a bus an arbitrary amountof devices can be connected, only the software needs to know howmany devices are actually in place. A daisy chain bus would allowfor a setup for the robotic arm as can be seen in Figure 6.
Daisy chaining is possible in a wide variety of protocols, fromwhich Modbus-RTU is selected for this project (see also Section F.3).Modbus-RTU requires limited (and relatively simple) hardware to im-plement. Also, standard software libraries (for both server and client)are available, which will speed up the implementation of the localcontrollers. Modbus-RTU is well supported in industrial equipmentwhich allows for the local controllers to be used with industrial equip-ment as well. It is also a likely candidate to be implemented on em-bedded systems (for example, the Arduino platform has a standardlibrary for Modbus-RTU available), keeping the client’s options opento build an embedded motion planning system in the future. Modbus-RTU is built upon the RS485 standard which specifies the electricalconnections. In order to implement Modbus-RTU on the local con-trollers, RS485 driver circuitry is needed.
A downside of using a local controller for each joint is that addi-tional hardware needs to be added to the joints. The local controllersmust be kept as small as possible, or should at least have the optionto shrink them in the future (for example, when an evaluation board
27
28 system architecture
Figure 6: Daisy chain architecture
is used for the initial prototype, this does not mean that the designcannot be made smaller in the future).
The next sections give more details on the high level control sys-tem and the local controllers. Please note that no distinction is madebetween the tool controller and joint controller. The tool controller isessentially a simplified version of the joint controller. For the initialprototype, in order to save costs, the joint controller hardware will beused to test tool functionality as well.
11.1 high level control
The function of the high level control system is to control the roboticarm at the robot level. That is, to translate user input into robot move-ment. A large part of this task comes down to motion planning: de-termining how the robot should move in 3D space to perform a taskwhile avoiding collisions with itself or its surroundings. For now, userinterfaces are also included in this layer since they tend to be robotspecific. In future systems, when more generalized GUIs are designed,they might be moved to a separate layer.
High level control will initially be implemented in ROS (as requestedby the client). Motion planning will be based on the MoveIt package,in combination with the ros_control package to connect the motionplanning to the hardware.
11.2 local controllers 29
The goal of the designs is to keep as much of them as system agnos-tic as possible, to enhance the re-usability of the code. Only a smallpart of the software (the hardware abstraction layer) needs to be robotspecific (that is, most modules in MoveIt and ros_control need to besupplied with robot description files which are robot specific as well.Yet, these settings files can be changed without doing any actual pro-gramming, so this is a matter of configuration rather than customimplementation). Since a large part of the high level control system isavailable off-the-shelf, the design and setup is not discussed here anyfurther. For more information on the high level control system referto Appendix G.
11.2 local controllers
The function of the local controllers is to control the physical motionof the joints. That is, to use closed loop control to ensure the jointsfollow a stream of setpoints received from the governing high levelcontrol system. The state of each joint is reported back to the highlevel control system upon request. In order to support the varioustypes of actuators and encoders (see Section 10.1 and 10.2), the localcontrollers will need to be equipped with a variety of Input Output(IO)s.
It is preferred by the client to use off-the-shelf modules where pos-sible. It is not desired to build fully custom control Printed CircuitBoard (PCB)s. However, since no off-the-shelf local controller is avail-able, custom PCBs will be necessary for at least a part of the system.
In order to save space (and money) it should be possible to combinefunctions on the local controllers as well. For example, a single localcontroller could be used to control a joint as well as a tool.
As the control system is supposed to be used on the low-cost roboticarm, the local controller must be kept low-cost as well. An indicationfor the budget of a single local controller is given in Table 1.
11.2.1 Hardware
The local controllers will mainly consist of a processing unit, runningthe control and communication software, and peripherals, connect-ing to physical devices. Since the goal is to keep the hardware off-the-shelf where possible, the Raspberry Pi Zero is selected as the pro-cessing unit. The Raspberry Pi has great support and lots of availableresources while maintaining a small footprint. It is running Linux,which means there are lots of ready-to-run software modules avail-able which greatly reduces the implementation effort (for more infor-mation see Section F.4.3). However, the Raspberry Pi Zero is a rela-tively young product, and delivery is still unpredictable. Thereforethe choice is made to start development using a Raspberry Pi Model
30 system architecture
3, which is electrically (and functionally) almost equal to the Rasp-berry Pi Zero. When developing an add-on board to add peripheralsto the processing unit, only the functionality that is present on bothRaspberry Pis will be used, so that the Model 3 can be replaced bythe Zero when they become readily available (more information onthe differences between both Raspberry Pis in Section K.10).
Even though the Raspberry Pi is a fully functional computer on itsown, it is not suited for control applications yet. Specific hardwarerequired by the local controllers (for example, RS485 & DXL bus sup-port) 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 Rasp-berry Pi community). This board will contain all hardware neededto transform the Raspberry Pi into a control module suited for thisproject. The components needed in the local control system are shownin Figure 7.
Figure 7: Hardware modules local controller
Even though the Raspberry Pi has some IO functionality by itself, aseparate micro controller will be added to the add-on board. This mi-cro controller is used as an IO expander, and is necessary because theRaspberry Pi has very limited PWM functionalities and high speed dig-ital inputs are needed (for example, to read the MAE3 encoders, seealso Section 10.2). Adding a separate micro controller to the add-onboard makes it possible to unload time critical tasks from the Rasp-berry Pis main software, and adds enough IOs and PWM channels tosupport the devices listed in Section 10.1 and 10.2.
Power parts (such as motor drivers) are specifically not included onthe add-on board. Since the goal is to make a modular and flexiblesystem, which can be reused on various projects, only the control sig-nals are supplied by the local controllers. Power parts are generallyvery application specific, and including them on the add-on board
11.2 local controllers 31
would either result in less flexibility, or a much higher cost price be-cause they are over dimensioned.
To enable the Raspberry Pi to sense the occurrence of an emergencystop (cutting power from the actuators), a power indication input isincluded in the design. When the power to the actuator is cut (orrestored), the Raspberry Pi can take appropriate action to avoid unex-pected behavior.
For more information on the implementation of the local controllerhardware, refer to Appendix H.
11.2.2 Raspberry Pi software
The software running on the Raspberry Pi will consist of several mod-ules of which some will run in parallel. All multi-threading willbe based on POSIX threads, to ensure portability amongst Linuxdistributions. The Raspberry Pis will run a custom Raspbian imageequipped with a kernel compiled with the real-time patch enabled(for more information see Section F.4.2). This patch enables real-timeconstraints on the execution of threads.
Running the test software, supplied by the real-time Linux project,with eight real-time threads and 300% processor overload shows thatthe execution delay on a real-time thread is at its maximum equal to50µs. Where possible, software libraries and tools from the standardRaspbian repositories will be used.
11.2.2.1 Joint bus software
The joint bus software will receive (and process) requests comingfrom the high level control system. For each joint a set of registersis defined which store important variables like setpoints, states anddebug information. These variables are stored in a shared data blockwhich can be accessed by the other software modules concurrently.
The joint bus software will run in parallel with, for example, thecontrol loop. For this project, the joint bus software will only supportModbus-RTU, but for future projects it might be possible to createadd-on boards based on different protocols. The joint bus software isset up in such a way that it can be reimplemented for an alternativeprotocol with relative ease (see also Appendix I).
11.2.2.2 Control loop software
The control loop software will be responsible for the actual control-ling action of the system. Setpoints can be fed to the control loopusing a data block which is shared with the joint bus software.
Turn around time (the time between measuring the plant’s stateand executing the appropriate action on the plant) should be as con-stant as possible. This enables users to model the controller as a sim-
32 system architecture
ple delay in their models. Delays can influence a system’s stability, sobeing able to model the controller as a delay is essential to ensure thecontroller will not destabilize the plant.
Several methods are used to ensure the turn around time will beas constant as possible. For more information on the timing of thecontrol loop, and maximum control rates, refer to Appendix J.
11.2.2.3 Tool controller software
The tool controller software is responsible for reading and writing aset of IOs which can be used to control attachments to the robot. Ingeneral, a set of control registers can be written (or read) over the jointbus software. These registers are synchronized periodically with themicro controller by the tool controller software. The tool controllerruns as a separate piece of software, and is executed parallel to thecontrol loop.
In order to avoid device contention between the tool controller soft-ware and the control loop, the tool controller software has a muchlower priority, making it preemptable by the control loop.
11.2.3 Micro controller software
The micro controller serves as a simple IO expander. The micro con-troller is connected to the Raspberry Pi using a SPI interface. The SPI
communication is described in detail in Appendix I. The softwarerunning on the micro controller is kept relatively simple, its mainfunction is merely to transfer data from and to the SPI bus from aset of control registers which are periodically synchronized with thephysical IOs.
In order to program the micro controller, a header will be addedto the local controller’s add-on board. Another header will be addedwhich connects to one of the micro controller’s additional SPI inter-faces. This allows for support of the AMT20 encoders in the future,although the SPI bus is not limited to this function. More informationon the micro controllers connections (and capabilities) can be foundin Section H.1.
12T E S T I N G
The design of both hardware and software of the local controllersis finished. A pre-production prototype is created (based on euro-card board) in order to test the functionality of the add-on board’sdesign. Using this pre-production prototype, individual componentsare tested. The goal of these preliminary tests was to verify the func-tionality of the hardware on the add-on board and compatibility withoff-the-shelf software components. The following functionalities aretested and proven to work on the pre-production prototype:
• Reading MAE3 encoders with the Raspberry Pi software (ormore in general, reading PWM inputs)
• Reading incremental encoders with the Raspberry Pi software
• Writing PWM outputs from Raspberry Pi software
• Reading and writing digital IO from Raspberry Pi software
• Controlling the Dynamixel servos from the Raspberry Pi (usingon-board DXL driver, tested up to 115200 Bits Per Second (bps))
• Synchronizing data with the local controllers from a develop-ment machine over Modbus-RTU (using the on-board RS485
driver, tested up to 115200 bps)
• Adding real-time capabilities to the Raspberry Pi
To summarize, on the pre-production prototype, the communicationbetween the Raspberry Pi and the Dynamixel servos (DXL bus), devel-opment machine (Modbus-RTU) and micro controller (SPI) are testedand proven to be functional (yet, they are not stressed to their lim-its). Interfacing the Raspberry Pi to various components (if requiredthrough the micro controller) is tested and proven to work. The com-ponents that are successfully tested are: Dynamixel MX64 servo (TTL
type), Dynamixel MX12 servo (TTL type), Maxon 135081 directly pow-ered DC motor (powered by an L298N H-bridge, and equipped withan HEDL5540 incremental encoder) and US Digital MAE3 encoders(12 bit PWM type).
Testing these components was done with several separate softwaremodules, which are not fully integrated yet. The production proto-type of the add-on board is currently in fabrication. Soldering andtesting of the production prototype will be done during the remain-der of the project, as well as the integration of the separate softwaremodules.
33
34 testing
The high level control system is not fully implemented for use onthe SCARA system, and remains largely untested. The remainder ofthe project will focus on delivering functional submodules of theSCARA system, for example, ROS based control of the linear slide anda single joint. It is to be expected that the high level control systemcannot be implemented fully during the remainder of the project.
In order for future project teams to get started with developmenton the local controllers, a user manual is created. This user manualcontains general methods and guidelines to start working with thethe local controllers. The manual can be found in Appendix K.
13C O N C L U S I O N S
The modular control system is currently in the prototyping phase.Several modules are tested, yet the control system is still lacking com-plete integration. The remainder of the project will focus on furtherintegrating the separate modules that are tested up to this point.
The modules developed in this project should be seen as an initialprototype, which can serve as a starting point for future projects. Therecommended improvement strategy would be to attempt to imple-ment these devices on multiple types of systems, in order to furtherrefine functional requirements. With these additional requirements, aredesign can be done to improve the current design concerning costs,size and modularity. Ultimately, this could lead to a set of moduleswhich can be produced in larger quantities, further decreasing unitcosts.
A logical first step is to redesign the board for use with the Rasp-berry Pi Zero. This would already reduce the size and cost price ofthe local controllers, with limited effort.
35
Apart from this message, this page is intentionally left blank
Part IV
C O N C L U S I O N S & R E C O M M E N D AT I O N S
14C O N C L U S I O N S
Research on component requirements of the low-cost robotic armshows that some requirements are in conflict. Further research needsto be done to find out which requirements are interdependent, andhow they can be altered in a way that still delivers a viable productfor the client. The models and methods created in this part of theproject can serve as a starting point for future research on the low-cost robotic arm.
The design of the modular control system’s prototype is completedand the system is partially tested. Yet, it is still lacking integrationon the SCARA system. To move the modular control system towardsa production version, it is recommended to test the prototypes withas much systems as possible. This should lead to additional require-ments which can be taken into account in the final design of the pro-totypes.
The high level control system remains largely untested at this point.Time has proven insufficient to start development on a GUI for the low-cost robotic arm. The remainder of the project will focus on furtherintegration of the separate modules of the modular control system.
Since the modular control system is in a very early stage of devel-opment, there are numerous recommendations and possible improve-ments to investigate. They are listed in Chapter 15.
38
15R E C O M M E N D AT I O N S
The recommendations can be separated in short and long term im-provements that can be made on the models and designs developedin this project. The next sections list those possible improvements.
15.1 short term recommendations
15.1.1 Model improvements
It is to be expected that the low-cost robotic arm’s mechanical designwill be updated in the near future. This, of course, needs to be takeninto account in the current models of the arm. The current models(described in Appendix B) can already be improved by adding thejoint actuation systems to the model. This will add the possibility toinvestigate the frequency behavior of the low-cost robotic arm.
It would also be good to create a model of the local controllersin Simulink. When possible, it would be best if the local controllersalso get an interface to Simulink. This would enable a user to simu-late (and verify) behavior of the controller and the plant, for example,by sending a reference signal to a modeled controller and plant, andsimultaneously to a physical controller and plant. Then, by compar-ing the model’s output and the physical output, the models can beverified.
15.1.2 Local controller improvements
As mentioned in Section 11.2.1, the local controllers need to be mi-grated from the Raspberry Pi Model 3 to the Raspberry Pi Zero. Inorder to do this, the add-on board needs to be redesigned to accom-modate for the smaller footprint.
Another short-term improvement that can be made to the add-onboards is to connect the micro controller’s pins 28 and 29 to the ex-pansion header, rather than pins 4 and 5 (see also Section H.1). Thisis a mistake made in the design of the add-on board. Using pins 28
and 29 would give the add-on board even more capabilities (an I2Cinterface and two additional 16 bit timer IOs to be exact).
Also, the stand alone capabilities of the add-on board could beimproved. As mentioned in Section H.6, the add-on boards couldalso be used as a stand alone control board for simple tasks. It isrecommended to investigate this further, to make the add-on boardseven more flexible.
39
40 recommendations
15.1.3 Control software
In the local controller’s software it is recommended to further inves-tigate the limits of the components. As mentioned in Chapter 13, theDXL bus is only tested up to 115200 bps. Also, the real-time capabili-ties of the Linux kernel are now tested on the Raspberry Pi Model 3,and this should be tested further on the Raspberry Pi Zero.
It is recommended to further investigate how the local controllerscan be set up in a user friendly way. At the moment, all settings aremade on a very low level (such as text based settings files). It shouldbe investigated how this can be done more user friendly in the future,for example, by using the micro controller’s Universal Serial Bus (USB)slave capabilities (see Section H.1).
In the high level control system’s software it is recommended tofurther implement the SCARA system, as only separate modules aretested at this point. Also, it would be useful if there was a simple tem-plate project for the high level control system (including a GUI). Thiscould be used for quick robot testing, and should make it possible toquickly get a new robotic arm up and running.
15.2 long term recommendations
15.2.1 Additional communication protocols
At this moment, only Modbus-RTU is supported by the local con-trollers. For future projects it might be useful if the local controllerscan also be used with systems that use other communication pro-tocols (for example, Controller Area Network (CAN) or EtherCAT)which are usually found on industrial devices. It should be investi-gated if these communication protocols can be added to the existingadd-on board, or that different versions of the add-on board shouldbe designed, each supporting a different communication protocol.
15.2.2 Additional boards
As mentioned in Section 11.2.1, the add-on boards specifically do notinclude any power parts. Also, they only support PWM based inputs.It might be useful to design some additional interfacing boards, to beable to connect the local controllers quickly to a lot of systems.
Of course, a large variety of power parts are available to be usedwith 5V logic (such as the local controller’s add-on board), but itmight be useful to create some custom boards for these purposes. Forexample, simple boards with a number of high-powered transistorson them would enable the local controllers to switch bigger loads.Also, boards can be created with an H-bridge for DC motor control(although these are very common off-the-shelf) or for brushless DC
15.2 long term recommendations 41
motors (specialized Integrated Circuit (IC)s are available for this pur-pose, see also Section F.1.3).
As mentioned in Section H.4, a simple board containing an NE555
timer IC to generate a PWM signal out of an analog voltage would beenough to add simple analog inputs to the local controllers.
Another useful add-on board would be a board which creates asingle ended 5V digital signal out of a differential signal. Differentialsignals are very useful in high-noise environments, and they are sup-ported by many industrial components (such as the SCARA system’slinear slide, see also Appendix E). At this moment, the signal lines areall used as single ended inputs, using the differential signal would bea great electrical improvement in terms of noise resistance. This couldalso be a starting point to verify that the local controllers comply toEMC norms.
These additional boards could be build as stand alone, that is, a sep-arate board which are connected with wires. It might also be possibleto create stacks with multiple PCBs, for example, a Raspberry Pi Zerowith on top a local control module (without connectors, but with a setof headers) and on top of that a board with power electronics, NE555
timers or differential inputs (and of course, connectors). This wouldresult in a very easy to use setup in which complicated designs canbe stacked together with ease.
15.2.3 Alternative processing units
Since for this project it was not desired to build fully custom controlPCBs, a lot of processing units where already out of scope. For future(production) versions of the local controllers, it could be interesting toreview these devices as well. Possible candidates are, for example, theXillinx System On a Chip (SOC)s. These devices employ both an ARMprocessor and an Field Programmable Gate Array (FPGA) in a singleIC. The ARM processor can be used to run embedded Linux takingcare of high level software tasks (as is the function of the RaspberryPi on the local controllers), while the FPGA can serve as a real-timemodule interfacing to the hardware (as is the function of the microcontroller on the local controllers). These types of devices could leadto an even smaller and faster system. A downside of these devices isthat they require substantially more implementation effort comparedto the local controllers as they are set up now, yet it might be a viablesolution for larger production quantities, given that development isspread out over a longer period of time.
Apart from this message, this page is intentionally left blank
B I B L I O G R A P H Y
[1] Brushless Motor Fundamentals. AN047. Rev. 1.0. Monolithic Power.Dec. 2016. url: https://www.monolithicpower.com/Portals/ 0 / Documents / Products / Documents / appnotes / Brushless %
20DC%20Motor%20Fundamentals.pdf.
[2] Capacitive Absolute Encoders AMT20 Series. Nov. 2016. url: http://www.cui.com/product-spotlight/capacitive-absolute-
encoders-amt20-series.
[3] Device Trees, Overlays, and Parameters. Jan. 2017. url: https://www.raspberrypi.org/documentation/configuration/device-
tree.md.
[4] Guidelines for Proper Wiring of an RS-485 (TIA/EIA-485-A) Net-work. Dec. 2016. url: https://www.maximintegrated.com/en/app-notes/index.mvp/id/763.
[5] Installing Operating System Images on Linux. Jan. 2017. url: https://www.raspberrypi.org/documentation/installation/
installing-images/linux.md.
[6] Kernel Building. Jan. 2017. url: https://www.raspberrypi.org/documentation/linux/kernel/building.md.
[7] M.P. Koster, W.T.C. van Luenen, and T.J.A. de Vries. Mechatron-ica. 5th. Enschede, NL: Faculteit Elektrotechniek, UniversiteitTwente, 1999.
[8] MAE3 Absolute Magnetic Kit Encoder. Dec. 2016. url: http://www.usdigital.com/products/encoders/absolute/rotary/
kit/MAE3.
[9] MAX485 Product data sheet. MAX1487-MAX491. Rev 10; 9/14.Texas Instruments. Dec. 2016. url: https://datasheets.maximintegrated.com/en/ds/MAX1487-MAX491.pdf.
[10] ROBOTIS e-Manual - Overview of Communication. Jan. 2017. url:http://support.robotis.com/en/product/actuator/dynamix
el/dxl_communication.htm.
[11] ROBOTIS e-Manual. Jan. 2017. url: http://support.robotis.com/en/.
[12] Real-Time Linux Documentation. Jan. 2017. url: https://wiki.linuxfoundation.org/realtime/start.
[13] SC16IS752 Product data sheet. SC16IS752_SC16IS762. Rev. 9 – 22
March 2012. NXP. Dec. 2016. url: http://www.nxp.com/documents/data_sheet/SC16IS752_SC16IS762.pdf?.
43
44 Bibliography
[14] SN74LVC2G241 Product data sheet. SN74LVC2G241. Rev. Decem-ber 2015. Texas Instruments. Dec. 2016. url: http://www.ti.com/lit/ds/symlink/sn74lvc2g241.pdf.
[15] Stijn Stertefeld. Development of a low-cost robot arm. Tech. rep.Eindhoven, NL: Mechatronics Laboratory, Fontys university ofapplied sciences, Nov. 2016.
[16] Ioan A. Sucan and Sachin Chitta. MoveIt! Dec. 2016. url: http://moveit.ros.org.
[17] TXS0108E-Q1 Product data sheet. TXS0108E-Q1. Rev. February2016. Texas Instruments. Dec. 2016. url: http://www.ti.com/lit/ds/symlink/txs0108e-q1.pdf.
[18] XMEGA AU MANUAL. 8331F-AVR-04/2013. Atmel. Dec. 2016.url: http://www.atmel.com/Images/Atmel-8331-8-and-16-bit-AVR-Microcontroller-XMEGA-AU_Manual.pdf.
[19] ros_control - Package Summary. Dec. 2016. url: http://wiki.ros.org/ros_control.
Part V
A P P E N D I X
AI N T E R N S H I P C O N T R A C T
46
Formulier 4 Stage- en afstudeerstartformulier
Tripa rtite-ove reen komst
Ondergetekenden,
1. Student (naam, voorletters) , ß4!** . TUT ?Adres ' i t^t"""r,ef4f"-^fpostcode/woonplaats : l't lz AEgeb. datum i Z'1 - a$ - l14Zhierna te noemen opdrachtnemer;
t2n"t'2-l¿tt
tv./*ir..-:^ tJ2. De directie vanNaa m vertegenwoordigerAdres Tpostcode/plaats : fþe f1hhierna te noemen opdrachtgever;
3. Fontys Hogeschool Engineeringgevestigd te : Eindhovenvertegenwoordígd door : Marc Mussaeus, stage- en afstudeercoördinator Mechatronicahierna te noemen : Fontys Hogescholen
verklaren te zijn overeengekomen dat de opdrachtgever de opdrachtnemer, in de gelegenheid zal
stellen om een stage-/ afstudeeropdracht uit te voeren gedurende een beperkte periode van een vande bachelor opleidingen Engineering van Fontys Hogescholen Eindhoven. Deze overeenkomst betrefteen (aanvinken wat van toepassing is):
StageopdrachtAfstudeeropdracht
Deze overeenkomst wordt beheerst door de navolgende artikelen
7
ArtikellDe opdracht betreft een stgdiebelasting van 840 uur. Ten behoeve van deze opdracht zal de studentin de periode van Q.l:P9:l&ot2*9.:.1.f ln h"t bedrijf aanwezig zijn.
Artikel2De opdracht is nader geformuleerd in een afzonderlijke opdracht die deel uit maakt van dezeovereenkomst en als bijlage I is toegevoegd.
Artikel31. De opdrachtnemer zal de in het belang van de orde en veiligheid gegeven gedragsregels,
voorschriften en aanwijzingen, zoals deze voor het personeel van de opdrachtgever vantoepassing zijn, in acht nemen en overigens elke onveilige handeling vermijden.
2. De opdrachtgever is gerechtigd terstond de opdracht te beëindigen, índien naar het oordeel vande opdrachtgever de in zijn bedrijf geldende gedragsregels, voorschriften en aanwijzingenonvoldoende door de opdrachtnemer in acht worden genomen.
20160608 Formulieren bij de Semestergids Mechatronica S5 en S8.docx
Artikel4De dagelijkse leertijd is voor de opdrachtnemer in overeenstemming met de arbeidstijd welke geldtvoor de afdeling waar hij/zij geplaatst is, tenzij dit anders is overeengekomen en voor zover niet instr¡jd met de arbeidswetgeving met betrekking tot jeugdigen.
Artikel5ln geval van verzuim of het voornemen daartoe is de opdrachtnemer verplicht de opdrachtgever opde hoogte te stellen of te doen stellen op een wijze zoals die in de onderneming van deopdrachtgever gebruikelijk is.
Artikel6L. De opdrachtnemer ontvangt een vergoeding per maan;)
en een onkostenvergoeding per maand van €-..,,1.. "^"r.þ?.=75,2. De opdrachtgever zal de uit deze tripartite-overeenkomst voortvloeiende premies van de sociale
verzekeringswetten voldoen. De verschuldigde loonbelasting zal door opdrachtgever wordeningehouden.lndien er geen sprake is van een verplichting in het kader van de Loon Belasting dientopdrachtgever toch melding te maken bij de bedrijfsvereniging in verband met de WAO-dekking.
ArtikelTDe opdrachtnemer is gehouden tot strikte geheimhouding omtrent aangelegenheden deopdrachtgever betreffende, waarvan het vertrouwelijke karakter geacht kan worden hem/haarbekend te zijn.lndien opdrachtnemer een verbetering vindt of een uitvinding doet, of bijdraagt tot het vinden vaneen verbetering of het doen van een uitvinding, die geheel of gedeeltelijk gebaseerd is op genoemdevertrouwelijke informatie en op zijn relatie tot, resp. werkzaamheden in verband met deopdrachtgever, zal uitsluitend opdrachtgever gerechtigd zijn ten eigen bate daarop octrooi of eensoortgelijk recht te verwerven.Bovenstaande laat onverlet dat de student kan afstuderen volgens de geldende regels envoorschriften.
ArtikelSDe opdrachtnemer zal bij afloop van de afstudeeropdracht de bedrijfseigendommen, alsmedecorrespondentie enz., betrekking hebbende op bedrijfsaangelegenheden, bij de leiding inleveren
Artikel9De opdracht wordt vervuld onder verantwoordelijkheid en supervisie van Fontys Hogescholen
Artikel 10De opdrachtgever zal een lid van zijn personeel belasten met de zorg voor en het toezicht op deopdrachtnemer, alsmede met de contacten met de vertegenwoordigers van Fontys Hogescholen
Artikel 11
Fontys Hogescholen wijst ten behoeve van de begeleiding van de opdracht één van haar docenten alsbegeleider aan.
Artikel12De opdrachtgever is verzekerd tegen het risico van aansprakelijkheid op grond van wanprestatie enonrechtmatige daad van ondergeschikten, waaronder begrepen opdrachtnemer.
Artikel 13Fontys Hogescholen zorgt voor een voldoende verzekering tegen het risico van ongevallen enwettelijke aansprakelijkheid gedurende de gehele periode van de afstudeeropdracht.
20160608 Formulieren bij de Semestergids Mechatronica 55 en S8.docx
Artikel14Fontys behoudt zich het recht voor opdrachten in te trekken c.q. ongeldig te verklaren indienopdrachtgever en/of opdrachtnemer zich niet houden niet aan de afgesproken onderwijsdoelstellingzoals opgenomen in de bijbehorende Onderwijs- en examenregeling, semestergids enopdrachtomschrijving (bijlaee l). Opdrachtgever en opdrachtnemer verklaren kennis genomen tehebben van de voor de opdracht van belang zijnde onderdelen daarvan. Fontys zal daartoe nietovergaan dan nadat overleg gevoerd is met de begeleider van opdrachtgever. Zo mogelijk wordtopdrachtgever nog een aan te geven periode de gelegenheid gegeven de opdracht / afspraken aan tepassen aan de eisen van Fontys."
Artikel15lndien de student niet heeft voldaan aan zijn studieverplichtingen om in aanmerking te komen voorhet uitvoeren van de stage- c.q. afstudeeropdracht dan heeft Fontys Hogescholen het recht om dezeovereenkomst binnen 1 maand na de startdatum (zie artikel 1) eenzijdig te ontbinden.
Aldus overeengekomen,
Namens Fontys Hogescholenstage- en afstudeercoördinator
Naam: Marc Mussaeus.......
Lo-l-41.(handtekening)
Deze tripartite-overeenkomst dient geheel ingevuld ingeleverd te worden met bijlage. Deze bijlagedient minimaal te bevatten:- Probleemstelling- Doelstelling- Opdrachtomschrijving- Eventuele aanvullende afspraken
"a: Q.É.: ?þt L
Namens de opdrachtgever (bedrijf) Naam
d.d dtekening)
a
De opdrachtnemer (student) Naam:...
(handtekeníng)
w lîl!*
-06- t{d.d.:þ-
20160608 Formulieren bij de Semestergids Mechatronica 55 en 58.docx
Versie: 20-6-2016
t\\fontys Bijlage l: Opdrachtomschrijvi n g*
Hoge3<holsn
,\\Fontys
Hogescholen
Opdrachtomschrijvin g afstudeerproject
Fontys Hogeschool EngineeringGoedkeuring opdracht
Datum . 2o*l* 6Goördinator : purrant-r
Handtekening
AfstudeerderNaamlnstituutOpleidingThema/profiel
Jeroen RikkenFontys Hogeschool Engineering EindhovenMechatronica
Studentnummer.E-mailTel. (mobiel)Samen met student n.v.t.
Afstudeerproject
Titel:
User Friendly and Low Cost Robotic Arm Control
Planning
Startdatum: 01-09-2016 Afstudeermaand: Door de opleiding te bepalen.
De student besteedt, binnen de normale werktijden,
gedurende ca. min. 20 (werk)weken, 40 uur per week aan de afstudeeropdracht.
Opdrachtgever
Bedrijfsgegevens naamadrespostcodetel.website
Fontys Hogeschool Engíneering, Mechatronica Lab.Rachelsmolen 1
5612 MA088 507 7233fontys.nl
Bedrijfsbegeleider(afstudeeropdracht)
naamemailtelnr.
Onno [email protected]
naamemailtelnr.
Personeelszaken
Versie: 20-6-2016
Aanleiding van het project (korte beschrijving van de projectcontext)
Het project is onderdeel van het grotere RAAK project: (G)een moer aan! Decentraleondezoeksvraag van dit project luidt: "Hoe kan een operator een robot eenvoudig, snel enveilig inleren om assemblage handelingen te verrichten voor het snel en robuust verbinden vanbouten, moeten en ringen met objecten?"
Binnen het project RAAK (G)een Moer Aan wordt er onderzocht hoe flexibel inzetbare robotstoegepast kunnen worden om bouten en moerverbindingen tot stand te brengen.Hierbij speelt veiligheid tussen mens en machine een bijzondere rol. De nieuwe generatie robots moetzonder veiligheidskooi kunnen operereren. Verder zal er ook in het project onderzocht worden hoeproductie-medewerkers zich prettig voelen om tussen de robots te werken. Een belangrijk deelhiervan is de gebruikers interface van de robot.
Doelstelling van het afstudeerproject
De afstudeerder dient op het eind van het afstudeerproject een gebruiksvriendelijk user interface aante leveren waarmee een low-cost robotic arm aangestuurd kan worden. Om dit te bereiken dient ereerst een motor-control system gemaakt te worden en een path-plannings module voor de robotarm.
Opdrachtbeschrijving (technisch inhoudelijke beschrijving)
Volgend vanuit de doelstelling van het project dient er eerst een motor control systeem ontworpen teworden waarmee de joints van de robotarm geactueerd kunnen worden. Denk hierbij aan de selectievan motoren, encoders en motor regelingen. Dit dient in lijn met de low-cost doelstelling plaats tevinden.
Vervolgens dient er in ROS (het robot operating system) een model van de robot arm gemaakt teworden zodat de path-planning plaats kan vinden. Path planning houdt in dat de robot weet, welkejoint hoe gedraait moeten worden, om een positie te bereiken.
Tot slot dient er na gedacht te worden hoe er een gebruiksvriendelijke grafische user interface (GUl)gemaakt kan worden om de robotarm in te programmeren. De doelstelling van het project is dat eenlaaggeschoolde operator de robotarm kan inleren om bouten en moeren aan te draaien. Hierdoor iseen traditioneel industrieel robot besturingssysteem niet passen, maar willen we meer naar eendrag&teach interface toe. Een voorbeeld interface hierbij is de interface van de Baxter Robot.
2
Versie: 20-6-2016
Werkwijze (benoem methoden, technieken, tools e.d. die zeer waarschijnlijk worden gebruikt)
Als projectorganisatie zal er volgens de SCRUM agile methode gewerkt worden.
Path planning in de ROS omgeving.
User interface ook ROS gekoppeld.
Motorcontrol staat nog open, maar wegens de low-cost focus in een micro-controller omgeving
Eindproducten (op te leveren producten)
EindverslagPresentatie
Keuze en selectie van low-cost high torque motoren.Keuze van low cost encoders.Closed loop aansturing van deze motoren.Path planning module in ROS.User friendly GUl.Communicatie middelen waarmee het geleerde aan opvolgers opgedragen kan worden.
Aanvullende afspraken en opmerkingen
Dit project loopt parallel aan een andere afstudeeropdracht waarin het mechanische ontwerp van eenlow-cost robotarm wordt gemaakt. Jeroen zal samen met deze W-student de motorkeuze uitvoeren,maar hoeft in eerste instantie niet het mechanische ontwerp te verzorgen. Mocht er onverhoopt eenprobleem ontstaan omdat de andere afstudeerder niet naar behoren functioneerd dan gaat Jeroen welnaar het mechanische ontwerp kijken en vervalt de GUI en e.v.t. path planning.
* Deze opdrachtomschrijving verplicht opnemen als bijlage 1 van het eindverslag
3
BD Y N A M I C M O D E L L O W- C O S T R O B O T I C A R M
b.1 mechanical overview
The first step in the design process is to gather information about themechanical design of the arm. This section gives an in depth overviewof the mechanics of the arm, and how they influence the control sys-tem.
b.1.1 General mechanical information
The low cost robotic arm has five degrees of freedom (effector rotationis fixed in one axis) and is designed to handle a 5 kg payload. Thereach of the arm is 1076.50mm around its base.
An overview of the arrangement of the axes of the arm and geo-metric parameters can be found in Figure 8. Values for the geometricparameters can be found in Table 4.
The upright position (as depicted) is used as the zero position forthe joints. All coordinate systems and rotations follow the right handrule. The coordinate systems for the joints lie in their respective centerpoints (P1, P2, P4, P6, P8 and Pe) and are aligned with the globalcoordinate system (when the arm is in the upright position).
The axes of rotation and limits for each joint are specified in Table 5.For detailed information on the mechanical design of the arm, pleaserefer to Development of a low-cost robot arm [15].
The mechanical requirements relevant for the component selectionare listed in Table 6.
note : The kinematics calculations are based on a system with off-sets (D2 to D5) not equal to zero, which was the original design in-tent for the arm. In the final design of the arm however, the linksare mounted in the centers, effectively removing the offsets. At thispoint in time the models and calculations were already built to takean offset into account, and modifying the model would be very timeconsuming. Therefore, the offsets are set to a relatively small valuefor the final simulations.
b.1.2 Joint actuation systems
The robotic arm consists of 5 independent revolute joints. Since loadis not equal on all joints, there are different mechanical designs for
53
54 Bibliography
parameter value unit parameter value unit
D1 255.0 mm L1 547.5 mm
D2 1.0 mm L2 389.0 mm
D3 1.0 mm L3 93.5 mm
D4 1.0 mm L4 46.5 mm
D5 1.0 mm
Table 4: Geometric parameters low-cost robotic arm
axis of upper lower
joint rotation limit limit
Joint 1 Z 190° −190°
Joint 2 Y 90° −90°
Joint 3 Y 90° −90°
Joint 4 Y 90° −90°
Joint 5 X 90° −90°
Table 5: Joint orientation & reach low-cost robotic arm
requirement must should unit
Effector speed 0.5 1.0 m s−1
Effector acceleration 0.5 1.0 m s−2
Effector deceleration 5.0 10.0 m s−2
Effector position resolution ± 0.1 ± 0.1 mm
Table 6: Product requirements low-cost robotic arm
Bibliography 55
Figure 8: Geometry low-cost robotic arm
the actuation of each joint. The concepts for each joint’s actuation arelisted in the next sections.
b.1.2.1 Actuation concept joint 1
Joint one is driven by a belt drive. A schematic overview of the com-ponents in the joint can be found in Figure 9.
56 Bibliography
Figure 9: Joint actuation system (type 1)
b.1.2.2 Actuation concept joints 2 & 3
In an attempt to limit the required actuator torque, joints two andthree are driven by a transmission in the form of a spindle. The spin-dle drives a nut which is attached to a belt, which on its turn drives apulley attached to the joint’s axis. A schematic overview of the com-ponents in these joints can be found in Figure 10.
Figure 10: Joint actuation system (type 2)
b.1.2.3 Actuation concept joints 4 & 5
Joints four and five are driven directly by an actuator. This simplifiesthe mechanical design and reduces weight which is beneficial for theother joints.
note : In the research and prototyping stage of the arm it is as-sumed that the joint actuation is stiff. The assumption is based on the
Bibliography 57
joint feed radius reduction
J1 1:9
J2 10.0mm 25.5mm 1:16
J3 10.0mm 25.5mm 1:16
J4 1:1
J5 1:1
Table 7: Joint reductions low-cost robotic arm
fact that most mechanical parts are chosen much larger or strongerthan strictly necessary. This assumption simplifies the calculation forthe actuator and encoder requirements. As an optimization step, it iswise to create a more elaborate model for the arm where the joints arecontrolled with a non-ideal joint actuation system. This is especiallynecessary when the arm is pushed to its maximum load, or whenhigh-frequency behavior needs to be evaluated.
b.1.2.4 Reductions
To calculate the velocity and torque requirement of the actuators andsensors, the mechanical reduction between the joint axis and the actu-ator’s axis is needed. For the belt drive, the reduction follows directlyfrom the pulley sizes. For the spindle based joints, assuming all partsstiff, the formula for the reduction is given by Equation 1. In this for-mula f denotes the feed rate of the spindle and r denotes the radiusof the joint’s driving pulley.
is =f
2πr(1)
The current design uses the parameters in Table 7. For more informa-tion on the current joint actuation methods, refer to Section B.1.2.
b.1.3 Forward kinematics
To calculate the position of the effector’s tip (in respect to the worldsorigin) for a given set of joint rotations, an Forward Kinematics (FK)solution is needed. The FK can be defined as a chain of homogeneoustransformations for the coordinate system of each individual joint [7,chapter 7].
The coordinate system of each joint is considered to be alignedwith the global coordinate system when the arm is in the uprightposition (see also Figure 8). Joint angles are numbered using theirjoint numbers.
58 Bibliography
The transformation matrices in Equation 3–8 can be used to con-vert coordinates from each joint’s coordinate system to its parent’scoordinate system. Equation 2 can be used to convert any point inthe effector tip’s coordinate system to the global coordinate system.
For example: to calculate a point pEa (point a in the coordinate sys-tem E of the effector), ~PEe would be equal to (pEax,pEay,pEaz, 1). The 1 isappended because the transformation matrices combine both rotationand translation, resulting in a 4x4 transformation matrix. The result-ing vector would be ~POe = (pOa x,pOa y,pOa z, 1) where pOa x, pOa y andpOa z are the elements of point pOa (point a in the coordinate system O,the origin).
To calculate the effector tip’s position in respect to the global coor-dinate system, ~PEe would be equal to (0, 0, 0, 1).
The forward kinematics calculation is implemented in a Matlabfunction in order to use it in modeling and simulation tasks.
~PO = T1 ∗ T2 ∗ T3 ∗ T4 ∗ T5 ∗ Te ∗ ~PE = TFK ∗ ~PE (2)
T1 =
cos(θ1) −sin(θ1) 0 0
sin(θ1) cos(θ1) 0 0
0 0 1 d1
0 0 0 1
(3)
T2 =
cos(θ2) 0 sin(θ2) 0
0 1 0 d2
−sin(θ2) 0 cos(θ2) 0
0 0 0 1
(4)
T3 =
cos(θ3) 0 sin(θ3) 0
0 1 0 −d3
−sin(θ3) 0 cos(θ3) l1
0 0 0 1
(5)
T4 =
cos(θ4) 0 sin(θ4) 0
0 1 0 d4
−sin(θ4) 0 cos(θ4) l2
0 0 0 1
(6)
Bibliography 59
T5 =
1 0 0 d5
0 cos(θ5) −sin(θ5) 0
0 sin(θ5) cos(θ5) l3
0 0 0 1
(7)
Te =
1 0 0 0
0 1 0 0
0 0 1 l4
0 0 0 1
(8)
b.1.4 Inverse kinematics
In order to convert desired effector poses to joint angles an IK calcu-lation is needed. The set of equations resulting from the FK matrixtransformation are non-linear (since they are based on trigonometry)and under defined (the forward kinematics solution does not givethe orientation of the effector, only the position). Generally, when amanipulator is equipped with two intersecting axes controlling therotation of the effector, the IK problem can be separated in a posi-tion problem and a rotation problem, which can be solved separately.Since this is not the case for this system (because of the offsets onthe joints) a geometry based approach will be used to calculate theinverse kinematics. The IK approach is explained in the next sections.
The IK solution is implemented in a Matlab function, which allowsit to be used on modeling and simulation tasks.
b.1.4.1 Calculation
The effector position will be given by the point Pe in respect to theglobal coordinate system. The rotation of the effector will be given byθx and θy which are the angles of rotation around the X and Y axis ofthe effector’s coordinate system. The rotation around the Z axis of theeffector (θz) follows from the effector pose and cannot be changed.
In order to calculate the inverse kinematics, certain geometric fea-tures of the arm will be exploited. The arm has three parallel axes(joints two, three and four). This means that the points P6, P7 andP8 will always lie in a plane Pl which rotates around the origins Zaxis. The distance d from the Z axis to this plane is equal to d =
D2 −D3 +D4. With the distance d and θ1 (the rotation of joint one)a vector can be defined which must be normal to the plane Pl. Usingthe dot product between the vector and plane Pl, Equation 9 can bederived. Since point P8 can be calculated using the effector’s pose in-
60 Bibliography
formation, Equation 9 can be solved numerically (or inverted usingcomplex numbers) for θ1.
x8 sin(θ1) − y8 cos(θ1) + d = 0 (9)
Given that θ1 is known and that point P7 lies in the plane Pl Equa-tion 10 can be derived using the normal representation of a plane.Point P7 needs to be rotated around joint 1 with θ1 to be able to useEquation 10. Solving Equation 10 results in θz.
x7 sin(θ1) − y7 cos(θ1) = x8 sin(θ1) − y8 cos(θ1) (10)
Now that P7, P8, Pe and θ1 are known, θ5 can be defined as theangle between the plane Pl and the plane Pe, defined by the pointsP7, P8 and Pe. The angle between the two planes can be calculatedusing Equation 11. Where an and bn are the elements of the normalvectors of the planes.
θ5 = cos−1
|a1b1 + a2b2 + a3b3|√a21 + a
22 + a
23
√b21 + b
22 + b
23
(11)
Since the points P6 and P7 are always in the same plane for all valuesof θ2, θ3 and θ4 and the axis of joints two, three and four are per-pendicular to this plane, the points P6 and P7 can be expressed in thecoordinate system of joint one, and omit the Y values of the points. Tocalculate the joint angles, first point P3 is calculated (in respect to thecoordinate system of joint one). Point P3 is given by the intersectionof two circles, defined by L1 and L2 and the point P6. This leads toEquation 12 which can be solved for x3 and z3. Using this point θ2can be calculated. By transforming the points P6 and P7 over θ2 andL1 the coordinate system will be aligned to joint three, and θ3 can becalculated using P6. This is repeated for P7 which leads to θ4.
[√l21 − z
23 − x6
]2+ (y23 − y6)
2 = l22 (12)
important note : the current implementation of the IK calcula-tion does not return all mathematically valid solutions. Since thereis often more than one path to the desired effector pose, the inversekinematics function is set up to return the most viable. For θ1 thismeans that an estimated value needs to be supplied. The functionreturns the calculated value of θ1 that is closest to the estimate. Forjoints two, three and four, the solution with the biggest Z value forpoint P3 is used. This is chosen since in most use cases the arm willbe mounted on a flat surface, and the solution where the arm is bentupward is favored over the solution where the arm is bent downward,where it would collide with the mounting surface.
Bibliography 61
b.1.4.2 Verification
Since a geometry based IK calculation is used, problems can arisewhen the effector changes quadrant. The IK function is designed tobe robust to these problems, and to ensure functionality a verificationscript is written. This script generates a set of randomized effectorposes in a bounding box. For each pose, the IK calculation is done,and with the resulting joint angles the FK is calculated. The distancebetween the requested pose and the resulting pose is returned, whichindicates whether the solution is correct or incorrect. If the solutionis accepted, the bounding box and range of rotation values can bestored in the model’s parameter structure, and the IK function willreturn an error when a requested position lies outside of the verifiedzone.
b.2 rigid multibody model
The arm can be seen as a multibody system where the links areinfinitely stiff. In order to estimate the required motor torque andpower, an position (motor angle) driven simulation is set up usingSimulink (in particular the Simscape multi body toolbox). The simu-lation takes into account the mass and inertias of the links, as well asan uniform gravitational field.
By driving the model with a stream of joint angles, the requiredtorque and power needed for the joints to comply to the specifiedjoint angles can be calculated. Using the transmissions present in thejoint actuation, the final motor requirements can be calculated fromthis data. This model assumes all links to be infinitely stiff. The cur-rent implementation does not model friction losses in the joints, how-ever this can be included in the simulation with relative ease. It isbest to extend the current model with friction losses as well in futureversions.
In order to simulate the behavior of the arm with non-ideal jointactuation systems (see also Section B.1.2), the model’s joints needto be driven by torque rather than position. The joint actuation sys-tems can then be modeled as a regular mechanical system (with iner-tias, springs and dampers) which can be connected to the multibodymodel. This is not included in the current models, but it is wise to addthis in future versions, in order to better understand high frequencybehavior of the arm.
b.3 set-up generation
In order to simulate some effector use cases, set-up profiles for thejoints are needed. In general, a system is needed where the effectorcan be led past several points in 3D space, specifying parameters like
62 Bibliography
acceleration and velocity. Since no system like this exists within theMatlab environment, these were created from scratch. The createdfunctions essentially generate a time-discrete description of the effec-tors’ motion out of a vector of target points and accelerations. Whena series of time-discrete effector poses is generated using these func-tions, the IK solution (see also Section B.1.4) can be used on each ef-fector pose, generating the required joint-space set-up profiles whichcan be used to drive the simulations (see also Section B.2).
Starting point for the use case creation is a linear acceleration pro-file (that is, acceleration is always specified in the direction of travel ofthe effector) and a set of points in 3D space. The traveled distance andvelocity of the effector over time is calculated as a result from the spec-ified acceleration profile. With the profile for traveled distance, andthe set of points to map it to, the traveled distance can be mappedout in 3D space.
Currently two mapping methods are supported: linear and arc. Inlinear mode, the travel of the effector is mapped between two arbi-trary points in 3D space. In arc mode, the travel of the effector ismapped from a start point to an end point around a specific centerpoint. The functions are designed in such a way that they return oncethe desired end point is reached. By chaining multiple linear and arcmaps, a complete effector motion profile can be generated. Besides po-sition information, the functions can also be fed angular information.Currently, the functions support linear mapping of angles betweenendpoints, that is, a start angle and end angle can be specified, andthese will be calculated while mapping the position information.
CU S E C A S E S I M U L AT I O N D ATA
This section contains the raw simulation data, following from the testpath simulation and gives extended information to Section 6.3. Thesimulation data can be found in Figure 11 to 13. These figures showthe required velocity, torque and power required by the joints to com-ply to the test path.
With these simulation results, the extreme values for the joints ve-locity, torque and power can be found. This is listed in Table 8).
Figure 11: Simulation data - velocity per joint
0 0.5 1 1.5 2 2.5 3 3.5 4
Time [s]
-120
-100
-80
-60
-40
-20
0
20
40
60
T [
Nm
]
Joint torquesJ1J2J3J4J5
Figure 12: Simulation data - torque per joint
63
64 Bibliography
0 0.5 1 1.5 2 2.5 3 3.5 4
Time [s]
-120
-100
-80
-60
-40
-20
0
20
40
60
P [
W]
Joint powerJ1J2J3J4J5
Figure 13: Simulation data - power per joint
j1 j2 j3 j4 j5 unit
Ppeak 40.12 101.65 56.05 15.37 1.81 W
Ts 69.04 27.69 6.99 2.28 N m
Tmax 52.41 114.47 45.88 14.02 2.34 N m
ω|Tmax0.58 0.29 0.04 0.57 0.55 rad s−1
ω|Tmax5.58 2.77 0.42 5.48 5.25 min−1
ωmax 0.97 1.02 1.89 2.03 0.97 rad s−1
ωmax 9.23 9.72 18.03 19.39 9.23 min−1
T |ωmax 4.32 62.55 23.32 5.86 0.20 N m
Table 8: Joint simulation data
DR E S O L U T I O N M O D E L L O W- C O S T R O B O T I C A R M
d.1 general information
The requirement for the resolution of the arm (as specified in Table 6)is that the positioning of the effector tip must be within ±0.1mm.With this information and the arm’s geometry, the required resolutioncan be calculated on various points of measurement (for example, onthe joint axis and on the actuator’s axis see Section D.2).
For the resolution calculations, a worst case scenario is used wherethe base angle of joint two is considered to be 90°, since this is whereits impact on the arm’s resolution is at its maximum. The worst casescenario is shown in Figure 14. This figure shows the orientation ofthe arm and in which plane each joint works in the worst case sce-nario.
Figure 14: Resolution worst case position
d.2 encoder placement
The encoders for the arm can be placed on several positions in thejoint actuation system (see also Section B.1.2). The positions are de-fined in Figure 15. The choice for a specific position results in differentselection criteria for the encoders (or, when an encoder is selected indifferent specifications for the expected performance of the arm). Aquick overview of the pros and cons of each position is given in thenext sections.
65
66 Bibliography
Figure 15: Encoder placement options
Position A - Joint axis
Position A is the most logical placement for an encoder, since thismeasures the joint angle directly. Also, the joint axis is the axis withthe smallest angular velocity which is beneficial in the selection of theencoders. Depending on the joint and its distance to the effector, theresolution requirement gives a minimum resolution for the encoders.It is to be expected that the encoders’ resolution needed when theyare mounted directly on the joints are fairly high.
Position B - Actuator axis
In order to reduce the number of ticks needed, the encoders can beplaced before the joint reduction. A downside of this is that the en-coders need to be much faster. The joint reductions are designed tobe without play and with sufficient stiffness, which simplifies jointcontrol. Since there is a reduction between the encoder and the jointaxis, the encoder will have multiple revolutions in a single revolu-tion of the joint axis. In order to keep the absolute positioning for thejoint axis, there is a need for an additional system which indicatesin which number of rotations the encoder is at any given time. Thisadds additional complexity, however, since the reduction is limited,the indication system does not need great precision and speed andcan be implemented relatively cheap.
Position C - Motor axis
The number of ticks needed can be decreased further by placing theencoder at position C. This leads to the same advantages and disad-vantages as the movement from position A to B. However, since themotor gearbox is an off-the-shelf part, it is not possible to influencethe play in the gearbox (which is usually quite big). Combined with
Bibliography 67
joint ∆θj [rad] ticks ∆θa [rad] ticks
1 1 .86 · 10−433819 1 .67 · 10−3
3758
4 1 .43 · 10−34398
5 4 .30 · 10−31461
joint ∆θj [rad] ticks ∆x [mm] ∆θa [rad] ticks
2 1 .86 · 10−433819 4 .74 · 10−3 2 .98 · 10−3
2111
3 3 .78 · 10−416619 9 .64 · 10−3 6 .06 · 10−3
1037
Table 9: Backward resolution calculation
the high speed needed on position C, this is a large disadvantage ofposition C.
d.3 backward calculation
Using the resolution requirement and the geometry of the arm, anestimate for the required encoder resolution can be calculated. In or-der to calculate the minimum encoder resolution for a specific joint,the rest of the arm is considered stiff and without play. The requiredresolution for the encoder (when mounted on position A, the joint’saxis) ∆θj is equal to ∆p/r, where ∆p is the position resolution and ris the arm’s length.
Using the transmissions in the joint actuation system, the resolution∆a can be calculated as well, which is the required resolution whenthe encoder is mounted on the actuator axis (encoder position B).
For joints two and three, ∆x specifies the required resolution whena linear encoder on the spindle nut was used. The resolution esti-mates can be found in Table 9.
After investigating possible encoders and their cost prices (see Sec-tion F.2), the choice is made to place the encoders on position B (theactuator’s axis) for joints one, two and three. On this position the res-olution of the arm is near the desired value, the speed requirementfor the encoders is still manageable, and there is a limited amount ofplay introduced in the joint angle feedback. For joints four and fivethe joints will be controlled directly (without any reduction), there-fore the encoder will effectively be placed on position A (the joint’saxis).
d.4 forward calculation
In order to calculate the resulting resolution for a known encoder andmounting point, the influence on the resolution for each joint can be
68 Bibliography
calculated separately. The positioning error can be decomposed inthe Z and Y direction, where joints one and five influence the Y errorand joints two, three and four influence the Z error. For joints one,four and five the influence on the resolution can be calculated usingEquation 13, where T is the number of encoder ticks per revolution, nis the transmission ratio between the primary and secondary pulleyand l is the arms length. For joints two and three the influence on theresolution is given by Equation 14, where f is the spindles feed rateand r is the joint pulley’s radius. Finally, the total resolution is givenby Equation 15.
∆p =2π
T·n · l (13)
∆p =f
T · d· l (14)
∆p =√(∆p1 +∆p5)2 + (∆p2 +∆p3 +∆p4)2 (15)
d.5 resolution and control
Please note that the resolution calculated with the formulas in Sec-tion D.4 mainly applies to the steady state error of the arm. It doesnot strictly mean that the control system is able to reach the same res-olution on all points on a path. Since a control system needs time tocompensate for position errors, the tracking error will be significantlybigger than the resolution calculated in Section D.4. So, in order tomake the tracking error smaller, the encoders need to be an order ofmagnitude more precise to allow for compensation.
EO V E RV I E W S C A R A S Y S T E M
The SCARA system is a five DOF robot system consists of four revoluteand one prismatic joint. An impression of the system can be found inFigure 16. For more details on the geometry see Figure 17. The linearslide is not included in this figure, it has a reach of 424mm.
Figure 16: Impression SCARA system
Figure 17: Geometry SCARA system
Three of the revolute joints are equipped with MAE3 encodersfrom US Digital (12 bit PWM type) and Robotis Dynamixel servos(MX64 TTL types). The servos are connected to the joint with a re-duction of 1:2. One revolute joint is equipped with a Robotis Dy-namixel AX12 (TTL type without additional encoder). The prismaticjoint is based on a ball screw spindle driven by a Robotis DynamixelMX64 (TTL type). The prismatic joint’s position feedback is given bya Heidenhain LS403C incremental linear encoder1. Together with the
1 http://product.heidenhain.de/JPBC/image/HWP.EN/hlr-system/816553-90.pdf
69
70 Bibliography
Heidenhain IDP101 control board2, this encoder produces a differen-tial quadrature encoder signal (0.01mm resolution), with a referencepulse every 10mm. These outputs can also be used with single ended5V logic. The linear slide is also equipped with two limit switches(with pull-up resistors built in for 5V logic).
The actuators are powered by a 12V power supply. To processthe linear encoder and limit switches, an Arduino Mega is installedwhich connects to ROS over a serial connection (using the rosserialpackage3). The Arduino is powered over USB. Following from previ-ous projects, Universal Robot Description File (URDF) models of thesystem are available. For more information on the SCARA system’s ex-isting (partially functional) control code (which is completely basedon ROS), see the project’s github page4.
2 http://product.heidenhain.de/JPBC/image/HWP.EN/hlr-system/269339-92.pdf
3 http://wiki.ros.org/rosserial
4 https://github.com/MinorAR/Fontys_SCARA_Arm/
FC O M P O N E N T B A C K G R O U N D R E S E A R C H
f.1 actuator overview
The actuators needed for the arm are fairly high-grade. The require-ments of the arm include a relatively high payload, a large operatingrange and high speed operation. All of these factors contribute tohigh power, torque and speed requirements for the actuators. Thereare several actuator options for the arm which are described in thenext sections.
f.1.1 DC - standard
Standard DC motors are relatively cheap, but have brushes whichwear out increasing the need for additional maintenance. Because ofthe brushes and relatively heavy rotors, they are not always suited forhigh speed operations where loads change direction quickly. A big ad-vantage of standard DC motors is the simple electronics required tocontrol them. Generally these are controlled with an H-bridge, witha PWM signal controlling speed, and a digital signal controlling thedirection.
f.1.2 DC - coreless
Coreless DC motors are comparable to standard DC motors but witha very light rotor. Because of the light core, they are better suitedfor large accelerations (which are to be expected in the robotic arm).However, they still have brushes which does call for periodic mainte-nance. A big advantage of coreless DC motors is the simple electron-ics needed to control them. Generally these are controlled with anH-bridge, with a PWM signal controlling speed, and a digital signalcontrolling the direction.
f.1.3 DC - brushless
Brushless DC motors are usually very fast and do not have brushes,which is beneficial for maintenance. However, brushless DC motorsare relatively expensive, and require specialized controllers to controlthe commutation, which only adds to the cost. A lot of the brushlessDC motor manufacturers target the high and market, and they can befound for a wide variety of specifications.
71
72 Bibliography
The controllers for brushless DC motors are usually stand alone,and connected to a motion control system using some form of a com-munication protocol. It is also possible to directly control brushlessDC motors, by powering each phase individually. Depending on theamount of phases the motor has (usually two, three or four) this re-quires a certain amount of high power outputs (to turn the phase onor of) and digital inputs (to read hall sensors indicating the positionof the motors) see also [1].
f.1.4 Stepper motors
Stepper motors are relatively cheap, and usually offer great torquecharacteristics. However, they are usually only usable up to limitedspeeds, or the torque output will drop drastically. Besides that, step-per motors have a fixed step angle which could be of great influenceon the resolution of the arm. Stepper motors require power electron-ics to power the phases in a specific sequence. A lot of off-the-shelfoptions are available, and this can also realized with a custom solu-tion with relative ease.
f.1.5 Servos
Servo motors are packages of a motor, encoder and controller. Theyare usually well engineered for a specific task and can be found for awide variety of specifications. Downside of existing servo systems isusually the price. Also, since the goal of this project is to create uni-versal joint controllers (which are a motor controller in itself) thereis a bit of overhead in cost since there are essentially two motor con-trollers running in parallel.
f.1.5.1 Dynamixel servos
A commonly used servo in the laboratory is the Dynamixel seriesservo from Robotis (see also [11]). These servos have a good price toquality ratio, and are controlled using either a half-duplex UniversalAsynchronous Receiver/Transmitter (UART) connection (by Robotisreferred to as TTL type) or RS485. The TTL type is most common in thelab. Usually a converter from the Robotis company is used to connectto the Dynamixels, but this can be done with custom components aswell.
The Dynamixel servos use a custom communication protocol (theDXL protocol), and the Robotis company supplies an Software De-velopment Kit (SDK) for a variety of platforms and programming lan-guages, most notably C++. The DXL protocol uses an 8N1 setting:eight data bits, no parity bit and one stop bit. The DXL protocol basi-cally works by sending a fixed series of bytes to the devices. First, two
Bibliography 73
bytes are send, both with the value 0xFF. Then, the ID of the targetedDynamixel is send (ID 254 means broadcast to all Dynamixels, this isused by the synchronization command). Then the amount of bytes inthe message is sent (the number of parameters plus two). Next is theinstruction code (also one byte long) and a number of parameters (thenumber of parameters depends on the executed command, for exam-ple, the synchronization command requires no additional parameters,but writing the position register requires two: one for the high byteand one for the low byte). Finally a checksum is send, which enablesthe Dynamixel to verify all data is received correctly.
After each command received by a Dynamixel servo it will senda response indicating errors (or requested data if that is the case).The response will keep the bus busy, so the response signal shouldbe included in the timing calculations! The response also starts withtwo bytes with the value 0xFF, the ID of the sending Dynamixel andone byte for the length of the response (again equal to the amount ofparameters plus two). The next byte is an error byte indicating anyproblems with the servo. If applicable, the parameters are send. Thefinal byte is again a checksum of the data.
For more information on the DXL protocol see [10].With this information the time it takes for a Dynamixel command
to be send can be calculated with Equation 16. Where n notes thenumber of data bytes, and b notes the bit rate of the device.
t =9 ·nb
(16)
f.2 encoder overview
In order to find suitable encoders for the low cost robotic arm, someresearch is done on various types and their pros and cons in respectto this project. An overview of the different types is given in the nextsections. Also, a preselection is made for some encoders which seemsuitable for the low-cost robotic arm project.
f.2.1 Types
f.2.1.1 Optical
For high precision systems, optical encoders are often used. Thereare a lot of optical encoders available, which can be used for highaccuracy and high speed systems. Optical encoders are contactless, sodo not need periodical maintenance. Also, most types can be used forcontinuous rotation as well. They are however relatively expensive,which limits the use in this particular project.
74 Bibliography
f.2.1.2 Resistive
Simple potentiometers can be used as encoders as well, where theoutput level of the voltage divider is an indication of the position.An advantage of potentiometers is that they are extremely cheap.However, potentiometers have sliders which calls for periodic main-tenance. Also, usually they only work for limited angles. Besides that,the linearity is usually not that great which makes them less suitablefor high precision applications.
f.2.1.3 Magnetic
Magnetic encoders consist of a simple magnet mounted on the rotat-ing axis and a number of hall effect sensors. The voltage over the halleffect sensors is influenced by the magnetic field, and with multiplehall effect sensors the absolute angle of rotation can be calculated.Magnetic encoders can be found up to 12 bit (roughly). The magneticencoders are relatively cheap and contactless which makes them suit-able for this project.
f.2.1.4 Capacitive
Capacitive encoders work similar to the magnetic encoders, however,in this case not the orientation of a magnetic field is measured, buta change in capacity. The capacity change is caused by the rotationof a disk with a certain metal shape etched into it. This disk rotatesbetween two plates, and depending on the rotation, the capacity be-tween the two plates varies. Capacitive encoders can be found up to12 bit as well. Capacitive encoders are even cheaper than magneticencoders, and they seem suitable for this project.
f.2.2 Preselection for the low-cost robotic arm
After research on absolute encoders (see also Section F.2), there aretwo types which show great potential: magnetic and capacitive. Twoencoders with a great price-performance ratio are the AMT20 manu-factured by CUI [2] and the MAE3 manufactured by US Digital [8].Their specifications are listed in Table 10.
It can be noted that the MAE3 is significantly slower than theAMT20. In the low-cost robotic arm project the AMT20 is most likelyto be the preferred choice.
f.3 joint bus overview
An introduction into viable options for the joint bus system is givenin the next sections.
Bibliography 75
parameter amt20 mae3 unit
Resolution 4096 4096 ticks
Refresh rate (max) 10 · 106 250 Hz
Interface SPI PWM
Price €30,– €70,–
Table 10: Encoder preselection
f.3.1 RS485
RS485 specifies layer one of the Open Systems Interconnection (OSI)model: the physical connection. RS485 uses a single differential dataline which makes it half-duplex and noise resistant. RS485 is usedextensively in industrial applications and is for example used to spec-ify the physical part of the ModBUS-RTU standard. Since RS485 onlyspecifies layer one, the actual communication protocol still needs tobe implemented (although there are some off-the-shelf options, suchas ModBUS-RTU). RS485 is half duplex, and is usually implementedwith a master-slave scheme, where there is a single master sendingdata (or requests for data) to the slaves, after which the correspond-ing slaves respond. Sending data over RS485 is usually the same assending data over serial connections such as UART which is generallywell supported in embedded devices. For Linux there is an off-the-shelf library which can be used to create ModBUS-RTU masters andslaves given that the physical interface is present in Linux as a serialdevice.
RS485 supports daisy chaining devices, with a maximum of 32 de-vices per chain (be aware that this varies somewhat between differentversions of driver circuitry, see also [4]).
Due to the presence of off-the-shelf software, and relative ease ofimplementation, RS485 seems very suitable for the low cost roboticarm.
f.3.2 CAN
CAN is primarily designed as a bus to connect controllers inside vehi-cles. Besides the use in automotive, it is used extensively in automa-tion. CAN provides excellent noise rejection and speed. In contrast toRS485, CAN not only specifies the physical connections, but also thecommunication schemes, including arbitration methods where therecan be multiple devices talking at the same time on a single CAN bus.CAN ensures that automatically the device with the highest priorityprevails. This makes CAN half duplex, but suitable for a multi-master
76 Bibliography
multi-slave setup. The CAN protocol is more difficult to implementthan for example RS485, mainly because of the software part.
CAN supports daisy chaining, with a maximum of 120 devices perchain (be aware that this varies somewhat between different versionsof driver circuitry).
Due to its robustness and industrial use, CAN seems like a viablecandidate for the low cost robotic arm.
f.3.3 Ethernet
Ethernet can be used as a daisy-chain type bus as well if used in com-bination with local switches. The biggest downside of an Ethernetbased bus is that the components are quite bulky. Also, it highly de-pends on the type of processing units used whether Ethernet basedcommunication is usable, and what sort of communication it sup-ports. A possible advantage of Ethernet could be that it can be useddirectly to connect ROS systems. Using this, it could be possible torun some embedded implementation of ROS on the joint controllers,and communicate with them using the standard ROS infrastructure,instead of implementing some bus system from scratch.
Due to the large size and additional components needed for anEthernet based bus, it is deemed not viable for the low cost roboticarm.
f.3.4 I2C
I2C is a bus system using only two wires: one for data and one for ashared clock. It is used extensively to connect ICs on PCBs, but in the-ory it could be used to connect PCBs as well. A downside of I2C is thatit is not really usable at longer distances, and is relatively sensitive tonoise. I2C features half-duplex communication and is usually imple-mented in a master-slave scheme where a single master is polling theslaves.
Due to its noise sensitivity and limited long distance capabilities,I2C is deemed not viable for the low cost robotic arm.
f.3.5 SPI
SPI is mainly used to connect ICs on PCBs. SPI features full-duplexcommunication between a master and a slave, where data is sendsynchronously. Every time the master sends a byte, the slave sendsback what is currently in its buffer. The slave that is allowed to talkwith the master is selected with a digital (chip select) line. Every slaveneeds a chip select line, which can be unwieldy at times. SPI is notreally usable at longer distances and is relatively sensitive to noise.
Bibliography 77
Due to its noise sensitivity and lack of long distance capabilities,SPI is considered not viable for the low cost robotic arm.
f.3.6 Half-duplex UART
Half-duplex UART is essentially the same as RS485, only then withoutthe use of differential data lines. Robotis Dynamixel servos employa protocol similar to half-duplex UART called the DXL protocol, al-though this system has some specific electrical properties because ituses a tri-state buffer to convert the full-duplex to half-duplex signal.
Another way to create a half-duplex UART system out of normalUART is to connect the transmitter of the master to the receiver of theslaves, and to connect the transmitters of the slaves to the receiver ofthe master with a diode (forward as seen from the slaves). In this way,when the master talks, all slaves receive the signal. When the masterasks a specific slave for data, the slave can send it, after which themaster receives. Because of the diodes, the other slaves their transmit-ters are not loaded by the sending slave.
Although this system is electrically relatively simple, there are sometiming and safety issues. Also it can be expected that it takes sometime to design a proper communication scheme for this system. There-fore, it does not seem viable for the low cost robotic arm.
f.4 processing units overview
f.4.1 General device classes
In order to select processing units, it is worth noting that there arethree general classes of processing units can be defined. The nextsections give a short introduction in their pros and cons.
MCU - Micro Control Units
For Micro Control Unit (MCU)s, the main upsides are:
• Small
• Relatively cheap
• Usually a lot of peripherals
Downsides:
• Generally not a lot of ready made software available
• Usually a lot of work to implement
• Usually very hard to do multithreading
78 Bibliography
SBC - Single Board Computers
For Single Board Computer (SBC)s, the main upsides are:
• Generally a of ready made software available
• Amount of work depends on available software modules
• Relatively easy to do multithreading
Downsides:
• Usually big
• Usually lack peripherals
FPGA - Field Programmable Gate Arrays
For FPGAs, the main upsides are:
• Very fast
• Excellent for parallel processing
Downsides:
• Harder to implement
• Limited off-the-shelf options available (apart from bulky evalu-ation platforms)
Basically this boils down to the following: when aiming for a fastand cheap solution choose a micro controller. The downside is thatthis will result in a setup dedicated for a specific task, with limitedoff-the-shelf software. When aiming for maximum speed use an FPGA.The downside is that there is virtually no off-the-shelf software avail-able and this likely requires a fully custom PCB design. When aimingfor maximum flexibility and off-the-shelf software support, pick anSBC. Downside is that this needs to be combined with a real-timeoperating system which could lead to more implementation effort.
f.4.2 Operating system
In the case an SBC is used, an operating system is needed as well.The expectation is that the operating system will not add so muchoverhead that it makes the processing slower than an MCU. Accordingto various sources, the overhead added by running embedded Linuxis 1-2%. This, combined with the significantly higher clock speeds ofthe SBCs (factor 30), the influence of the operating system is expectedto be negligible.
Bibliography 79
Yet, fast execution does not mean that real-time behavior can beguaranteed. In order to add real-time capabilities to the Linux kernel,it needs to be compiled with the RT-PREEMPT patch enabled. Gen-eral instructions to patch an existing Linux kernel with the real-timecapabilities are available on the RT-PREEMPT project wiki (see alsoSection K.6).
f.4.3 Control board and bus selection
In order to start designing the local controllers (see Section 11.2), itis necessary to select the main components: the joint bus system andthe processing units. Main selection criteria for these components istheir size and the design effort needed to implement them. Using thefunctional requirements (see Chapter 10) and the general architecture(see Chapter 11) for the modular control system, suitable hardwarecan be selected.
In order to do a proper selection a lot of individual systems needto be evaluated. To keep the amount of systems manageable, for eachclass of processing unit (see also Section F.4.1), some devices are pre-selected based on a comparison against the competitors in their class.SBCs must run a fairly well supported version of Linux, which meansthat there is a lot of ready made software available, and must besmall. MCUs must support some form of multithreading, and musthave good communication interfaces. Since there are limited FPGA
based boards available which are suited for this application, and theyrequire a lot of work to get running, they are left out of this compari-son. The preselected devices are:
• FriendlyARM NanoPI NEOA very small SBC running Ubuntu snappy core
• Raspberry Pi ZeroA very small SBC running a variety of Linux distributions
• Variscite DART-4460
A very small System On Module (SOM) running Ubuntu 12.04
• NXP mBed LPC1768
A fast and well supported MCU
• Parallax propeller miniA MCU specifically suited for multithreading
These processing units can now be paired with a variety of bus sys-tems, and evaluated. The selected bus systems are RS485 (togetherwith Modbus-RTU), CAN and Ethernet. The configurations are listedin Table 11. Each combination is given a score concerning their func-tionality and implementation effort. The scores are normalized on a
80 Bibliography
id board bus id board bus
A NanoPI NEO RS485 B NanoPI NEO CAN
C NanoPI NEO Ethernet D Pi Zero RS485
E Pi Zero CAN F Pi Zero Ethernet
G NXP mBed RS485 H NXP mBed CAN
I NXP mBed Ethernet J Propeller RS485
K Propeller CAN L Propeller Ethernet
M DART-4460 RS485 N DART-4460 CAN
O DART-4460 Ethernet
Table 11: Board and bus preselection
scale from 0 to 10, where 10 indicates the best option (most function-ality, least implementation effort). The results of the calculations areshown in Figure 18. The scores are based on a weighed calculation,concerning the component specifications.
Figure 18: Board & bus selection chart
This comparison shows that the SBCs look promising, since they aregenerally easer to implement (this is due to the fact that they have alot of ready to run software available). This is a big advantage overthe MCUs.
In the category of the SBCs, the difference between for example theRaspberry Pi or the DART-4460 (which is actually a SOM targetingthe Original Equipment Manufacturer (OEM) market) is that there is alot of information, help and ready made modules available for initial
Bibliography 81
testing for the Raspberry Pi. This greatly simplifies the prototypingstage for a Raspberry Pi based system. For a production version ofthe control system it is advised to look further into the SOM modules,since they are generally more powerful than products aimed at proto-typing (such as the Raspberry Pi). Since both devices run a variety ofLinux, it should be possible to reuse software modules tested on theRaspberry Pi on more industrial oriented systems.
In the prototyping stage it is best to stick with a well supported,and relatively easy to implement solution. Therefore the choice ismade to use the Raspberry Pi Zero in combination with Modbus-RTU(and RS485) in the prototyping stage.
GO V E RV I E W H I G H L E V E L C O N T R O L S Y S T E M
The function of the high level control system is to translate user in-puts to robot movements. The high level control system does this byusing a variety of user interfaces and motion planning techniques.The general setup is shown in Figure 19. The next sections will givea more in-depth overview of the responsibilities of each componentand the communication between them.
Figure 19: Architecture motion planning
g.1 joint bus hardware
In the prototyping stage the USB-RS485-PCBA from FTDI is usedto connect the machine running the high level control system to thejoint controllers. This is a simple PCB with an USB to UART conversionchip (the FT232RQ from FTDI) and RS485 line driver installed. Thisproduct is ordered off-the shelf to make sure the master side of thecommunications works and can be tested. For future versions, thisshould become a custom module, which might have some additionalIO functionalities (for example, to create a remote control for the op-erator).
82
Bibliography 83
g.2 ros modules
Most of the modules in Figure 19 are available as a standard ROS
package and only need setting up. Especially MoveIt [16] related com-ponents (MoveIt itself, joint trajectory controller, joint controllers androbot state publisher) work out of the box when supplied with a de-cent URDF of the robot. The controller modules are part of ros_control[19] instead of MoveIt. The hardware abstraction module is to be cre-ated from scratch, and will contain the connection to the robot’s hard-ware (utilizing the joint bus).
g.3 tool control module
The tool control module will be used as a generic communicationmodule to the tool functions. The tool control module can be imple-mented directly inside the hardware abstraction module as well, sincethe communication with the local tool controller is also done over thejoint bus.
g.4 gui
The GUI will be the main interface through which an operator ac-cesses the functions of the arm, it must be clear and simple. The GUI
will work together extensively with the robot state module, show-ing or hiding controls depending on the state and requesting statechanges where needed. As mentioned in Section 2.1 the GUI will onlybe implemented if there is sufficient time.
g.5 robot state module
In order to use the robot in a production environment, several statesof operation can be defined. The current state of the robot will bestored and controlled using the robot state module. Every modulethat depends on the robot’s state is responsible to take appropriateaction on a state switch. By storing and controlling the robot’s statein a separate module, it is easier to create complex systems with a lotof different user modes. An overview of the operating states is givenin the next sections.
g.5.1 Startup mode
In startup mode, the communication between the machine runninghigh level control and joints is initiated. Also, checks are executed toverify that the robot is operational to ensure that there are no errorsimpeding its usability.
84 Bibliography
g.5.2 Free mode
In free mode the motors are not powered. The robot can be moved byhand while the encoders are being updated (this allows for manualsetting of positions). Also, this mode is useful to verify the models forthe robot and its surroundings, since the robot and its surroundingscan be visualized using tools like RViz for example.
g.5.3 Manual mode - planned control
In this mode MoveIt is used as the main control component. The usercan set and request poses for the robot using a tool like RViz and planand execute motions. Eventually it should also be possible to supplypose requests from the GUI for example, when moving to previouslycreated poses.
g.5.4 Manual mode - effector space control
In this mode the user can move the effector through space. This isdone by planning ahead a path using MoveIt based on operator input.This input can either come from the GUI or a gamepad. By doing thisthrough the MoveIt motion planning layer, the collision detection ofthe robot is preserved.
This type of control appears to be rather rare, and it is unclearwhether MoveIt fully supports these control types (although thereare indications that it does on the ROS forums).
g.5.5 Manual mode - direct joint control
In this mode the joints are controlled directly by the user. This is donein a similar fashion as in the joint space control approach, except nowthe planning is done based on joint space commands.
g.5.6 Program execution mode
In this mode MoveIt is used to move the arm past a series of pre-viously set points. The points are fed to MoveIt which plans andexecutes the motion. The tool controller is used to control the tools.This mode will be the primary mode of operation in an productionenvironment.
Bibliography 85
g.5.7 Error mode
If an error occurs the robot will move to error mode, which disablesthe robot as safe as possible. When leaving the error mode, caution isneeded to re-enable the motors to prevent unexpected behavior.
HI M P L E M E N TAT I O N A D D - O N B O A R D
The local controller is equipped with an add-on board which is de-signed from scratch. The design choices for the components on theadd-on board are discussed here, as well as an overview of the add-on board’s design.
h.1 micro controller
The add-on board is equipped with a micro controller, which servesas an IO expander. The micro controller that is selected for this func-tion is the Atxmega64A4U from Atmel (see also [18]). It is chosenfor its high-speed sixteen bit timer capabilities. Each timer has fourinput or output compare channels and has built-in PWM generationand measurement functions. Please note that these timers can be con-figured to input or output in blocks of four, so four MAE3 encoderscan be read and four PWM signals can be generated at the same time,or eight MAE3 encoders can be read, but then no PWM signals can begenerated, and vice versa.
Atmel’s Xmega series are equipped with a flexible interrupt con-troller, which enables virtually any IO pin to be used as an interruptsource. Also, some pins can be used as a dedicated quadrature sig-nal decoder. Besides timing and IO functionalities, it has an internal32MHz clock (making it more than fast enough to reach the µs res-olution required to read MAE3 encoders), which avoids the need forexternal timing components.
The Atxmega64A4U has several SPI ports (which can be used as amaster or as a slave), as well as its own UART device and an USB slavebus. All of these are connected to a separate breakout header, so thatthe add-on board can be expanded at will.
Sixteen of the micro controller’s IO lines are available at the con-nectors for use, and can be configured as digital input, digital output,PWM input, PWM output or interrupt based digital inputs, which al-lows for all functionality needed for the SCARA system as well as thelow-cost robotic arm. The pins that are available on the connectorsare listed in Table 12. This table lists the micro controller’s pin num-ber (P#), the internal name for that pin (which can be used in themicro controller’s software) and a list of that pin’s functions (FUNC).The functions are noted in code: P means PWM capabilities (capitalP for 16 bit timer and lowercase p for 8 bit timer), I means interruptcapabilities, U for USB, S for UART, C for I2C and B for SPI. Finallythe connector on the board which the pin is connected to is listed
86
Bibliography 87
p# name func con p# name func con
1 A5 I IO3 22 D2 IPS IO10
2 A6 I IO2 23 D3 IP IO9
3 A7 I IO1 24 D4 IpB EXP3
4 B0 I EXP5 25 D5 IpB EXP1
5 B1 I EXP6 26 D6 IUSB EXP2
10 C0 IPC IO16 27 D7 IUSB EXP4
11 C1 IPC IO15 34 PDI PDI
12 C2 IPS IO14 35 RES PDI
13 C3 IPS IO13 36 R0 I RPI
14 C4 B RPI 37 R1 I RPI
15 C5 B RPI 40 A0 IP IO8
16 C6 B RPI 41 A1 IP IO7
17 C7 B RPI 42 A2 IP IO6
20 D0 IP IO12 43 A3 IP IO5
21 D1 IPS IO11 44 A4 IP IO4
Table 12: Pin mapping micro controller
(CON). The connectors marked with EXP (expansion header), PDI(programming data interface) and IO (general IO header) are exclu-sively connected to the micro controller. When connector notes RPI,the micro controller’s pin is connected directly to the Raspberry Pi.
h.2 uart module
The local controller has two serial device based communication ports,Modbus-RTU, relying on RS485, and the DXL bus. The Raspberry Piitself is equipped with one UART port, which is used by the debugterminal. In order to add two UART connections to Raspberry Pi, theadd-on board is equipped with the SC16IS752 module from NXP (seealso [13]). It has two UART modules and works over SPI. This deviceis selected because it has standard Linux device drivers and a devicetree blob in the standard Raspbian image, which requires virtually nowork to get it up and running. Also, this particular device supportsRS485 direction control (which is required for both the RS485 and theDXL bus driver circuitry). Direction control uses a separate pin to put
88 Bibliography
the driver circuitry (the RS485 driver and the tri-state buffer for theDXL bus) in send or receive mode. Be aware that this mode needs tobe switched on by the software at runtime, and it cannot be turnedon persistently.
h.3 line drivers and level shifters
The other main components on the add-on board are the line driversfor the bus connections and the level shifters for the inputs and out-puts.
For the RS485 connection, the MAX485 IC from Maxim Integrated(see also [9]) is used. This is the de facto choice for an RS485 linedriver, and supports up to 32 devices on a single bus.
The DXL bus is based upon the SN74LVC2G241 IC from Texas In-struments (see also [14]). This device employs a dual buffer and drivercircuit with tri-state outputs. One of the enable lines for the drivers isinverted, allowing for the device to be controlled with a single direc-tion control signal (as is supplied by the UART module) signal.
As level shifter for the IOs the TXS0108E-Q1 IC from Texas Instru-ments is selected (see also [17]). This device features eight channel bi-directional level conversion, allowing all IOs to be used set as inputsor outputs in the micro controller without the need for any additionaldirection control circuitry.
h.4 pcb design
The final PCB design for the add-on board is based on the geometryof the Raspberry Pi Model 3. The Raspberry is powered from theboard instead of the other way round (this to avoid damage to theRaspberry Pi). The design is based on Surface-Mount Device (SMD)devices where possible, and has only two copper layers to ensure itcan be produced by PCB prototyping services in small quantities.
The layout of the board can be found in Figure 20 and 21. Notshown in these figures is the ground plane, filling up the remainingspace of the top and bottom layers.
Both SPI buses used by the Raspberry Pi are equipped with jumperpads, which make it possible to disconnect the micro controller andUART module from the Raspberry Pi. Wires can then be soldered onthe jumper pads to connect to other boards for prototyping purposes.Also, soldering wires to the jumper pads (while keeping them con-nected) can be useful to connect the board to a logic analyzer, makingit possible to debug the SPI connections (this is especially useful forthe micro controller, since it is running a custom SPI communicationscheme).
The design is not optimized for size yet, it is recommended that thisis done by future projects (especially when migrating to the Rasp-
Bibliography 89
21-12-1609:43f=4.00/home/jeroen/eagle/LCRA_Modular_Control_FINAL/LCRA_PI_HAT_v1_0.brd
Figure 20: Add-on board design top
berry Pi Zero). For more information on the design of the add-onboard, refer to the schematics.
The add-on board currently only supports PWM based inputs, itmeasures the duty cycle directly from the signal shape instead ofmeasuring it as an analog voltage. In order to interface the board withpotentiometers, a simple board can be used which uses an NE555
timer to generate a PWM signal with a varying duty cycle based onthe potentiometer’s output.
The PWR connector is used to power the board, GND marks theground connection and 5V marks the logic supply. The remainingconnection point can be used to power the DXL bus, or to merelyindicate the presence of actuator power (for example, to detect thatan emergency stop has occurred) even though the DXL bus is notused. The DXL connector is used to connect to the Dynamixel servos,and is wired accordingly. The Modbus connector (marked with MB)is used to connect the local controller to the joint bus. The three sparepins in the upper left corner of the board (marked with GND, RXand TX) can be used to connect to the Raspberry Pi’s debug terminal.For the other connectors (EXP, PDI and IO) refer to Table 12, as theyconnect to the micro controller.
h.5 cost price
Currently the local controller (and the add-on board) is still in theprototyping phase. The prototype is based on Raspberry Pi 3 ModelB, where a future production version will be based on the RaspberryPi Zero. An overview of the costs of the prototype (and the expectedcosts of the production version) can be found in Table 13. The price of
90 Bibliography
21-12-1609:43f=4.00/home/jeroen/eagle/LCRA_Modular_Control_FINAL/LCRA_PI_HAT_v1_0.brd
1
Figure 21: Add-on board design bottom
product prototype production
Raspberry Pi €37,50 €10,–
Add-on PCB €17,36 €8,26
Components €31,51 €31,51
Total €86,37 €49,77
Table 13: Cost price local controller
the add-on PCB is based on the prototype add-on board (Raspberry PiModel 3 size). For the prototype the cost price is based on a produc-tion quantity of four pieces, for the production version, the cost priceis based on a production quantity of 20 pieces. Component price isbased on per-piece ordering.
It should be possible to further decrease the cost price of the localcontrollers if the components are ordered in bulk, and the add-onboard is produced in larger series. All prices listed are excluding 21%Value Added Tax (VAT). PCB prices are based on euro-circuits protopool manufacturing service, and exclude fabrication of stencils (asthey are only to be ordered once).
h.6 alternative uses
The add-on board is designed to be used in combination with a Rasp-berry Pi. However, for specific cases where extremely low costs arerequired and only limited functionality is needed, it is worth noting
Bibliography 91
that the add-on board will function on its own as well. Since the mi-cro controller is not powered by the Raspberry Pi, but instead theRaspberry Pi is powered by the add-on board, the micro controllerwill remain functional even if the Raspberry Pi is removed. Of course,this will remove functionalities such as the DXL bus and Modbus-RTU.
II N T E R FA C E D E S I G N L O C A L C O N T R O L L E R
Various interfaces are needed to make all components in the controlsystem work with each other. The next sections give a short intro-duction into the various interfaces. For implementation details pleaserefer to the software itself.
i.1 micro controller interface
The interface to the micro controller is based upon SPI. A series ofparameters are defined, which control specific functions of the microcontroller. The next sections give an overview of the inner workingsof the interface.
i.1.1 SPI transfer
In order to transfer data from and to the micro controller, a SPI bus isused. Data is transferred synchronically in the SPI protocol, so sendinga byte means that at the same time a byte is received. In order tocontrol specific functions, each SPI transfer has a specific structure. Adata transfer starts (as with all SPI transfers) with pulling the slaveselect line to low. Then, a byte is send by the master (the RaspberryPi). The most significant bit of this byte controls whether a parameterneeds to be read (low) or written (high). The other seven bits specifythe parameter number (see also Section I.1.2). The number of bytesthat follow is dependent on the parameter’s byte size and whether aread or write is executed. For a read, a number of empty bytes is sentwhich is equal to the byte size of the parameter. For each empty bytethat is send, the next part of the parameter is send back to the master.For a write, the parameter’s new value is sent. All data is shifted mostsignificant byte first, that is, high byte to low byte!
With this information the time it takes for a SPI transfer to takeplace can be calculated with Equation 17. Where n notes the numberof data bytes, and b notes the bit rate of the device.
t =8 ·nb
(17)
i.1.2 Parameter definition
All parameters that can be controlled in the micro controller are de-fined in a header file, which is also used by the master software run-
92
Bibliography 93
ning on the Raspberry Pi. Each parameter has a type, which specifiesthe byte size: one byte for an unsigned char, two for an 16 bit inte-ger, four for an unsigned or a signed integer etcetera. If a parameteris to be treated as a floating point, it is not stored as such. A signif-icance factor is stored in the parameter’s struct, which specifies thesignificance: 1000 for 3 digits behind the point, 10000 for 4, etcetera.This factor is used to multiply the raw value in the micro controllerprior to truncating it to an integer. This is done to avoid the need tosend floating point numbers over the SPI bus, which causes a lot ofproblems since there are some differences in the implementation offloating points between platforms. The received value can be decodedback to a floating point, by dividing it by its significance factor in themaster software. Essentially, this structure emulates a fixed floatingpoint system, where there can only be a specific of digits behind thepoint.
i.2 joint interface
The joint interface is to be abstracted from the specific hardware thatconnects to the joint. Each joint is modeled as a device with an ID anda set of parameters. All these parameters are standardized in a jointinterface class. Then, for each communication system, this class has aspecific implementation, determining exactly how these parametersare sent to the actual joints. This implementation can be based on anyphysical bus and communication scheme, and it is possible to expandthis in the future.
For Modbus-RTU (and Modbus-TCP for that matter), this meansthat the joint’s parameters are put in a specific register in the Mod-bus structure. Every time a parameter updates, the correspondingModbus command is called updating the parameter of a remote de-vice (defined by a specific Modbus ID). When multiple joints are con-trolled with a single local controller, the second joint is placed in theModbus registers at a specific offset. This implies that there is a dis-tinction between joint ID and Modbus ID! The Modbus ID defines thephysical local controller module, and the joint ID defines the actualjoint. For example, when two local controllers are used, and they bothcontrol two joints, the joints with IDs one and two will be controlledby Modbus device with ID one. The joints with IDs three and fourwill be controlled by Modbus device with ID two!
JC O N T R O L L O O P T I M I N G
The control loop running on the Raspberry Pi will be controlling phys-ical systems. To ensure controller functionality (and plant stability)turn around times of the loop should be as constant as possible. Sev-eral methods are used to ensure constant turn around times. Thissection gives an overview of the steps taken to ensure constant turnaround times, as well as an example on how the maximum controlrates can be calculated based on a specific application.
In order to keep the turn around time as constant as possible, allcontrol software (data acquisition and actuator control) is executedin a single thread. This avoids the risk on contention over devices bymultiple threads, which could occur even with real-time executionenabled (for example, a control loop wants to write a servo over SPI,but another loop is already claiming the SPI bus). This also meansthat when a controller is controlling multiple joints, they have to runin the same control loop, and by extension, at the same rate! In somecases this could be avoided, for example, when all resources for theloops are split over multiple devices, but in general this rule shouldbe followed. Please note that the SPI bus connecting to the micro con-troller is not the same device as the SPI bus connecting to the UART
module, so there is no device contention possible at that point.In order to further stabilize the turn around time a synchroniza-
tion system will be implemented, which ensures updating of data(encoders and actuators) occurs at fixed moments in time. Synchro-nization is implemented in the micro controller by adding an addi-tional digital signal connecting to the Raspberry Pi. All input buffersare updated on the falling edge of this signal, and all output buffersare updated on the rising edge of this signal.
The Dynamixel servos employ a specific commands for this pur-pose. First a value is be written to a temporary register (per Dy-namixel). Then, a special command is send in broadcast mode (re-ceived by all Dynamixels, disregarding its ID) which causes all Dy-namixels to write the temporary register to the actual control register.The synchronization methods do not say anything about the actualupdate rate of the encoders and actuators, these can be much higheror lower than the control rate. Yet, syncing the buffer updates doesresult in constant turn around times for the control loop which ulti-mately results in a more predictable system.
94
Bibliography 95
The regular flow of the control loop software looks like this:
1. Read the setpoint
2. Set the synchronization signal low, which updates the encoderbuffers in the micro controller
3. Read the encoder buffers from the micro controller
4. Calculate effort out of the error
5. Write the actuators (the following will run in parallel):
• Write the actuator buffers to the micro controller
• Write the Dynamixels’ buffers
6. Send the synchronization instruction to the Dynamixels
7. Reset the synchronization signal signal, which updates the ac-tuator buffers in the micro controller
The timing of the control loop software is shown in Figure 22. Theturn around time for this control loop can be calculated for a varietyof different scenarios. The following example is based on a local con-troller controlling a single joint from the SCARA system, and gives anindication of which turn around times can be expected. In this case,the joint has a single Dynamixel actuator and an MAE3 encoder. TheDynamixel servo is set in wheel mode, so that it can be controlled asif it was a DC motor. For each action, the corresponding parameter inFigure 22 is noted.
Figure 22: Timing overview control loop
The Dynamixel servo is set to a baud rate of 115200 bps. The typi-cal instruction to set the Dynamixel’s speed is 14 bytes long (for boththe instruction and response, see also Section F.1.5.1). Which meansthe time needed to write a single Dynamixel’s velocity setpoint (T4)is equal to 1094µs (see also Equation 16). Sending the synchroniza-tion command to the Dynamixels takes six bytes, which takes 469µs(T5A). Please note that when sending the synchronization command,the loop still needs to wait on the response message (noted by T5B,
96 Bibliography
also taking six bytes and thus 469µs). The update of the actuatorbuffers however, needs to be synchronized with the expected arrivalof the synchronization command to the Dynamixels, and is thereforedelayed by T5A. The update of the actuator buffer is expected to takemuch less time than the for the Dynamixels to send their responsemessage, and therefore the remaining time for the update (T6) willbe zero in almost all cases.
The speed of the SPI bus connecting to the micro-controller is set to500000 bps. Sending (or receiving) a 32 bit integer will take five bytes(one byte for the address and read/write indication, four bytes for theactual value, see also Section I.1.1). So, reading an MAE3 encoder’svalue (T2) takes 80µs (see also Equation 17).
Because the Raspberry is running a kernel with the real-time patchenabled, the variation on the start of the execution of the real-timeloop is at its maximum equal to 50µs.
In comparison to the Dynamixel transfer time, SPI transfer time andvariation on the start of the execution of the loop, T1 (encoder bufferupdate time), T3 (effort calculation) and T6 (remainder of the actu-ator buffer update) are negligible. This means the turn around timebecomes equal to 2112µs at its minimum and 2162µs at its maximum(taking into account the maximum control loop execution delay). Thiscorresponds to a control rate limit of 462Hz, without any safety fac-tor.
It is worth noting however, that the timing is mainly influencedby the application. A DC motor (controlled by the micro controller)is written much faster than a Dynamixel servo, and can therefore becontrolled with much higher control rates. For example, when a DC
motor and an MAE3 encoder are used, the turnaround time becomes160µs minimum and 210µs maximum. Resulting in a control ratelimit of 4.76 kHz! The Dynamixel servos are capable of working athigher bit rates, yet this remains untested in combination with thelocal controllers. It is recommended to investigate this in the future,allowing the Dynamixel servos to be used with higher rate controlloops as well.
KU S E R M A N U A L L O C A L C O N T R O L L E R
k.1 introduction
This user manual gives an introduction in the tools and methods usedto interact with the modular control system. These tools and methodscan be used to modify the system, but it also introduces some topicswhich are important to understand prior to modifying the system.Since most methods used in this project are targeted on the Linuxoperating system, and many of these methods include Linux shellcommands. General knowledge of Linux is recommended. The meth-ods described in the following sections are tested on Ubuntu LTS14.04 (for the development machine) or Raspbian Jessie Lite (for theRaspberry Pi). The shell used on both systems is bash. Linux shellcommands are noted like this:
1 $ make <stuff>;
# make <stuff>;
The # means that the command should be executed as root (either byusing sudo or by logging in as root). Any text within (and including)the angle quotes is to be replaces with a specific parameter, in thiscase the parameter named stuff.
The username and password for the Raspberry Pi are kept at theirdefault values: the username is pi and the password is raspberry.
k.2 electrical interface
Please note that the Raspberry Pi uses 3.3V levels for its logic. Theadd-on board however is designed to use 5V levels to interface toother devices.
Please note that when powering the Raspberry Pi Model 3, 500mAmight not be enough! When in doubt, use either the add-on board topower the Raspberry Pi, or the Pi’s own 2A USB power supply. Whenthe power supply is unstable, this is detected by the Raspberry Pi andindicated by a red power LED.
For more information on the design of the add-on board refer toAppendix H.
k.3 the raspberry pi’s operating system
The operating system of the Raspberry Pi is stored as an image filewhich can be loaded on an Secure Digital (SD) card. Besides the oper-ating system, the SD card serves as the main data storage for the Pi. In
97
98 Bibliography
order to set up multiple Pis at once, the image file itself needs to bemodified prior to writing it to an SD card. In this project, the choice ismade to start with a standard image (Raspbian Jessie Lite dated 2016-11-25). This basic image (and others like it) can be modified in severalways to make it suitable for the project, this process is described inthe next sections.
k.3.1 Mounting the image
In order to access the files within the image from a development ma-chine, the image needs to be mounted. This is done using the loopmode of Linux’s mount command. Loop mode creates a virtual blockdevice out of an image file, which than can be accessed as if it wasa physical disk. In order to mount an image, block size and partitionoffsets need to be known. These parameters basically describe wherethe different partitions are in the image file. Block size and partitionoffset can be found using:
$ fdisk -l <path_to_image_file>
For example:
$ fdisk -l jessie-lite.img
jessie-lite.img: 1389 MB, 1389363200 bytes
4 255 heads, 63 sectors/track, 168 cylinders, total 2713600 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x5a7089a1
9
Device Boot Start End Blocks Id System
jessie-lite.img1 8192 137215 64512 c W95 FAT32 (LBA)
jessie-lite.img2 137216 2713599 1288192 83 Linux
The example shows that the image file has two partitions. The blocksize is noted as sector size. The offset can be calculated by multiply-ing the start block noted for each partition with the block size. Thisinformation can be used to mount the partitions in the image file to afolder. The command looks like this:
# mount -o loop,offset=<offset> <path_image> <path_mount_point>
The mounted partition will now be available for access in the<path_mount_point> directory, where it can be accessed in the sameway as any physical disk. The Raspbian images have two partitions,the first being the boot partition and the second being the root of thefile system. More information on this can be found on the RaspberryPi’s documentation pages. In general it is good to know that all thingsrelated to the kernel, device tree and settings required on boot time,can be found on the boot partition. All user files and software can befound on the file system’s partition.
Bibliography 99
k.3.2 Installing software on the image
When creating a system based on the Raspberry Pi, it is recommendedto use software from the repositories where possible. Since an Inter-net connection is not always available on the Raspberry Pi (for ex-ample, the Zero or the compute module) and it is useful create astandardized image for multiple devices, it is required to pre-installsoftware on the Raspberry Pi’s image prior to using it with an actualdevice. This can be done using a combination of the qemu and chrootcommands. Qemu functions as a bridge between software compiledfor ARM (present on the Pi) and the development machine (whichusually has an x86 or x64 architecture). Chroot allows a user to alter-nate between file systems, which means software can be run whilepretending to be under a different file system. For example, when aLinux machine has kernel issues, one can boot it with a live image,chroot into the file system of the broken machine and start repair-ing the damage, essentially running software of the broken machineusing the kernel of the live image.
In this case, a combination between the two systems is used tochange into the file system of the Raspberry Pi’s image (which ismounted as described in Section K.3.1). Qemu ensures that the soft-ware installed on the Pi’s image can be run by the development ma-chine.
In order to add this functionality to a mounted image, first installqemu by running:
# apt-get install qemu qemu-user-static binfmt-support
Mount the image as described in Section K.3.1. First, comment ev-erything out in the etc/ld.so.preload file in the Pi’s file system(use # for comments). Without this step, network connections willnot work, causing commands requiring Internet access (such as theapt-get package manager) to fail. Then, copy the qemu user emula-tion binary to the pi’s file system, and chroot into the Pi’s file system(that is the file system not the boot partition):
# cp /usr/bin/qemu-arm-static <path_mount_point>/usr/bin
$ cd <path_mount_point>
# chroot . bin/bash
To check that the chroot was successfull, use uname -a. If this com-mand shows armv7l at the end (rather than x86 or x64), the chrootwas successful. All commands ran from this point on will be executedas if they were executed on a Raspberry Pi loaded with this particularimage. Please note that all changes will be stored permanently in theimage file. For example, apt-get can be used to install software pack-ages or to update parts of the image. Do not forget to un-commentthe lines in /etc/ld.so.preload, and properly unmount the imageprior to loading it on an SD card. The chroot can be ended by sim-ply using the exit command. The image can be unmounted by using
100 Bibliography
umount <path_mount_point>. Please note that it will be impossible tounmount the image while it still has an open shell in one of its sub-directories! Leave the image, and close all programs which might bemodifying files on the image prior to the umount command.
k.4 writing the image file
After all the required data is put on the image file, it needs to bewritten to the SD card. This is done using the dd (disk dump) com-mand, which is described in detail on the Raspberry Pi’s documen-tation pages [5]. However, this method does not provide any indica-tion of progress. The following variation of the method does indicateprogress:
# dd if=<path_img> | pv -s 2G | dd of=<device> bs=4M
Where <path_img> is the path to the image file, 2G is an estimateof the image size and <device> is the device on which the image iswritten (usually /dev/mmcblk0, but this can vary across devices). Thisvariation of the command sends all data read by the first dd command,through the pv (pipe viewer) command (which periodically prints theprogress), to the second dd command, which writes the data to thedisk.
k.5 using the device tree
The device tree is a set of files present on the boot section of the Rasp-berry Pi’s image. These files basically describe what the physical sys-tem looks like, and load the corresponding device drivers. However,a physical system can usually be configured in multiple ways. Thistask is also done by the device tree. For example, in order to disablethe bluetooth module, a device tree blob can be loaded which sets thecorresponding settings. The device tree is described in detail in theRaspberry Pi’s documentation [3]. As a rule of thumb: anything thatneeds to be configured on a physical device at boot time is configuredin the device tree.
The default images only contain the so called device tree blobs:the compiled versions of the device tree files. When the kernel iscompiled from scratch (see Section K.6) the device tree source filesare supplied as well. Eventually, the add-on board should get its owndevice tree file. For now, a combinations of settings is supplied in thecustom image which enable (and disable where necessary) the properdevices.
Bibliography 101
k.6 compiling the kernel
Standard Rasbpian images come with a basic Linux kernel compiledfor ARM. It can be useful to compile a custom kernel, for exampleto add real-time capabilities or to add custom device tree overlays. Inorder to compile the kernel, it is best to reference the Raspberry Pi’sdocumentation pages [6] as these are updated frequently and containsome Raspberry Pi specific tasks.
There are basically two general scenarios in this project in whichcompiling the kernel is necessary: to add custom device tree blobs, orto add real-time capabilities to the kernel. Custom device tree blobsare not used at the moment (although they might be in the future, seeSection K.5).
In order to add real-time capabilities to the standard Linux kernel,the RT-PREEMPT patch must be applied prior to compiling it. Thegeneral approach can be found on the RT-PREEMPT wiki [12]. Afterdownloading the Raspbian kernel as described in the Raspberry Pi’sdocumentation, these steps can be applied to enable real-time capa-bilities.
k.7 the debug terminal
The Raspberry Pi is equipped with a debug terminal. This terminalbehaves as if it was a regular Linux terminal, only it is connectedover a serial connection rather than using a display and input devices.The terminal is implemented at low level in the kernel, and basicallyfunctions as a failsafe device. Even when display drivers and driversfor input devices fail, the debug terminal will remain functional. Thedebug terminal needs to be enabled in the device tree (this is thedefault setting in the custom image, but in the standard image itneeds to be turned on manually). An USB to UART cable is needed toconnect a host computer to this terminal.
In this project the Raspberry Pis are mostly used without periph-erals attached, so the debug terminal is vital to interact with the Pi,especially on the Zero which does not have a network interface.
A simple yet efficient application for Linux to talk to the debug ter-minal is screen. The baud rate for the Raspberry Pi’s debug terminalis set to 115200 bps. When using the serial cable screen can be startedlike this:
$ screen <device> 115200
where <device> specifies the terminal device used on the develop-ment machine. For a USB to UART cable, this is usually /dev/ttyUSB0.While inside the screen session, all characters typed are send directlyto the Raspberry Pi. To exit the screen session use CTRL+SHIFT+A toenter command mode, and type :quit to exit the session. All com-
102 Bibliography
mands left running when closing the session will continue to do soafter the session has ended!
k.8 ioctl
The UART connections used for the Modbus-RTU connection and theDXL bus are by default configured as a standard UART device, whichmeans all transmission control is turned off. In order to enable theuse of the direction signal controlling the half duplex conversion, thedevices need to be put in RS485 mode. In this mode a pin is used tocontrol the direction of the data flow (sending or receiving). This canbe done using IOCTL calls1. IOCTL calls are basically specific systemcalls in the Linux operating system which can be used to configuredevices, in this case serial (or character) devices. The IOCTL calls areran at execution time, and the configurations are non-persistent.
Please note that for the Modbus-RTU connection the RS485 controlsignal needs to be inverted in comparision to the DXL bus. This isdone using the same IOCTL call, yet with slightly different settings.
k.9 compiling the software
The local controller’s software is compiled using a set of makefiles.The makefiles are targeted at the compilation of the software for boththe Raspberry Pi and the host computer in one go (this means thatcompilation is expected to take place at the host computer). Pleaserefer to Linux documentation sources for more information on themakefiles, and how to modify them.
When possible, the software is kept at a functional state for both tar-gets, to enable software functionality to be tested on the developmentmachine as well. A useful tool for software testing is socat. This com-mand can be used to create, for example, two virtual serial devices,which are connected to each other. This is very useful for testing soft-ware were data is transfered (such as the joint bus software).
k.10 migration from model 3 to zero
The Raspberry Pi Model 3 and Raspberry Pi Zero are electricallyequal. That is, they have an identical 40 pin expansion header andwork on the same voltage levels. The processors are slightly different.The Model 3 has a quad core processor while the Zero only has a sin-gle core. Execution speed of the code (especially the maximum real-time thread execution delay) should be thoroughly checked whenmigrating to the Zero. The difference between the processors is takeninto account in the device tree. It automatically loads the correct de-
1 https://www.kernel.org/doc/Documentation/serial/serial-rs485.txt
Bibliography 103
vice tree files for the processor it is running on. The same image canbe used on a Model 3 as well as on a Zero, without any issues.
LS TAT E M E N T O F O R I G I N A L I T Y
104
Apart from this message, this page is intentionally left blank
colophon
This document was typeset using the typographical look-and-feelclassicthesis developed by André Miede. The style was inspiredby Robert Bringhurst’s seminal book on typography “The Elements ofTypographic Style”. classicthesis is available for both LATEX and LYX:
https://bitbucket.org/amiede/classicthesis/
Happy users of classicthesis usually send a real postcard to theauthor, a collection of postcards received so far is featured here:
http://postcards.miede.de/
Final Version as of January 9, 2017 (classicthesis version 2.0).