H2Arm - BSP vs PID experiments

H2Arm - BSP vs PID experiments

Citation Author(s):
Enrica
Zereik
CNR-INM
Fabio
Bonsignorio
Angelo
Odetti
Submitted by:
Enrica Zereik
Last updated:
Fri, 02/28/2020 - 15:54
DOI:
10.21227/4692-2z85
Data Format:
License:
Dataset Views:
74
Rating:
0
0 ratings - Please login to submit your rating.
Share / Embed Cite

Many different methods have been proposed in the control and robotics literature for the control of robotics arms. Our main aim is to provide a complete software and hardware platform which allow the statistical replication of our results and the experimentation of other more or less sophisticated control strategies and algorithms.

In our work, in order to validate our reproducible research  platform and provide a template methodology for its usage,  we have thoroughly compared in a reproducible way the performance of simple BSP and PID controls when applied to a light-weight, low accuracy and compliant  open source robot arm (H2Arm). BSP significantly outperforms PID on this platform, but not w.r.t. to all metrics.The findings are interesting by themselves. They also show how easily statistically weak results can lead to qualitatively wrong conclusions, if you cherry-pick results.

The present dataset contains: i) CAD design to 3D-print the H2Arm; ii) experimental data of comparison BSP vs PID; iii) all the code used to perform the experiments (both BSP and PID).

Instructions: 

v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}

Normal
0

false
false
false

EN-US
X-NONE
X-NONE

/* Style Definitions */
table.MsoNormalTable
{mso-style-name:"Tabella normale";
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-priority:99;
mso-style-parent:"";
mso-padding-alt:0in 5.4pt 0in 5.4pt;
mso-para-margin-top:0in;
mso-para-margin-right:0in;
mso-para-margin-bottom:8.0pt;
mso-para-margin-left:0in;
line-height:107%;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:minor-latin;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:minor-latin;
mso-bidi-font-family:"Times New Roman";
mso-bidi-theme-font:minor-bidi;}

Experiment Reproducibility User Guide

This section details the hardware, software and procedure needed to reproduce the experiments described in the paper.

Hardware

H2Arm is a 4-dof manipulator, each of its link has been 3D-printed. The interested reader can found the CAD design of each robot link element on IEEE DataPort, in such a way to be able to print his/her own H2Arm. The red wheel, used as blob to be tracked and centered by H2Arm during tests has been 3D-printed as well (and again, its CAD design can be found on IEEE DataPort).

The arm is equipped with a commercial Mediacom USB2.0 camera (from Chatpack 300) mounted on the robot wrist. The webcam has been calibrated through the ArUco library [1] version 1.2.5, allowing to retrieve its intrinsic parameters (focal length, distorsion coefficients, …). Please note that any camera is suitable to be used with the H2Arm, provided that it can be accessed by the OpenCV library and that its calibration parameters are known or can be retrieved (in this case the value of the camera focal length - in pixel - has to be reported in the FOCAL_LENGTH_WRIST_CAMERA variable of the C++ vision algorithm - refer to Subsection “Software”).

H2Arm is actuated through 6 commercial Parallax Continuous Rotation Servos (2 for each joint  plus 1 ES08MAII Motor DC for joint , combined with a tendon-based architecture. The low level control of the motors is performed through a Pololu Mini Maestro 12-Channel USB servo controller. The first two motors (moving joint ) are connected to channels 0 and 1 of the Pololu Maestro controller, motors of joint  to channels 4 and 5, motors of joint   to channels 6 and 7; finally the motor in charge of moving the prismatic joint   is attached to channel 9. The H2Arm is powered at 5VDC.

In order to build up his/her own H2Arm, the interested reader can find all the necessary CAD designs on IEEE DataPort (see next Subsection \ref{subsubsec:dataport}) for the 3D-printed elements, as well as all the necessary components to be purchased; moreover, an overall 3D-pdf file is provided in order to understand how to assemble all parts.

We hope that many researchers and experts in the field will 3D-print their own H2Arm and try to replicate our results or compare their own control strategies with ours. We are open to collaborations and discussion.

Software

The overall system software is made up of three different components:

·         the proper control strategy (BSP or PID), implemented in Matlab R2016b and exploiting the Corke Robotics Toolbox [2];

·         the vision-based blob recognition algorithm, written in C++ exploiting OpenCV 2.4.9 library and compiled with Visual Studio 2012;

·         the H2Arm low-level control implemented in Python 2.7.14 (output of print(sys) command is 2.7.14 |Anaconda, Inc.| (default, Nov  8 2017, 13:40:45) [MSC v.1500 64 bit (AMD64)]), with Anaconda version 1.6.9 and conda version 4.8.1. For the Pololu Maestro controller, the drivers (for both Windows and Linux) can be found on [3], [4]. As described above, three different models are provided for the arm LLC (model A, B and C); for models A and C, just the code exploiting one parameter set is provided (the interested reader can easily change the joint gains in the code). Note that on CodeOcean the Python low level control has been ported on Python 3.7.3, miniconda 4.7.10 since this was the available Python environment (basically, only the calls to the print function have been changed accordingly).

All three software components communicate through standard TCP/IP sockets. The described experiments were executed on a laptop mounting an Intel core i7-6700HQ@2.60GHz and equipped with Microsoft Windows 10 Education N version 10.0.17134 Build 17134. We provide all the exploited software, compiled both for Windows (the one used in the presented experiments) and for Linux (the only coding difference is the implementation of TCP/IP communication among processes and the use of the relative standard socket libraries provided by the two operating systems).

The software can be found on:

·         CodeOcean: for each software component, a capsule has been created on CodeOcean, namely H2ArmFindRedObj3D [5], H2ArmMotorsActuation [6], H2ArmBSPoptimization [7] and H2ArmPIDcontroller [8]. However, this has some problems since the Matlab installation on that platform is missing the Instrument Control Toolbox, needed to use TCP/IP sockets (and thus the BSP/PID control strategy cannot be run on CodeOcean). Moreover, since code online is executed on a remote machine that is not connected to the H2Arm, the low-level component cannot communicate with the Pololu Maestro board, while the C++ vision algorithm is not able to address the camera. To overcome these problems, the reader interested in reproducing our experiments should obtain the hardware, download the code, as well as set up the needed architecture and operating system (Linux or Windows, OpenCV, Pololu driver, …) and run all the components in his/her own local machine.

·         IEEE DataPort [9]: the same software components, as well as the experimental results in terms of data logged by H2Arm, have been uploaded on IEEE DataPort. To reproduce our experiments, the same procedure as before is needed: download the code, obtain the H2Arm and related hardware, and set up the needed architecture.

 

Material organization on CodeOcean and IEEE DataPort

CodeOcean

The H2Arm repository on CodeOcean contains only the software components of the system. It is organized in four different capsules [5], [6], [7], [8] each of which basically is developed within a specific environment (operating system, available libraries, …) and contains a file  run.sh that specifies how to compile and run the code.

The capsules are:

·         H2ArmFindRedObj3D} - Linux version (OpenCV 3.3.0, gcc 5.4.0, Ubuntu 16.04): this capsule includes a file main.cpp that contains the vision-based algorithm to measure the blob 3D position and send it to the controller. On Linux it can be compiled with the command g++ -std=c++11 -Wall -o FindRedObj3D main.cpp -lopencv_core -lopencv_highgui -lopencv_videoio -lopencv_imgproc and run with ./FindRedObj3D. Note that this is not the actual version employed in the experiments, all the test results have been obtained on Windows. This Linux-based version differs from the exploited one just in the communication part of the code - socket - and the related standard library, as well as in the OpenCV version (3.3.0 in Linux, 2.4.9 in Windows).

·         H2ArmMotorsActuation - Linux version (Python 2.7.15, miniconda 4.7.10, Jupyter 1.0.0, Ubuntu 18.04): it implements the low level control for the H2Arm. There are three different versions, corresponding to the three different tested LLC models (DriveArmMotors_modelA, DriveArmMotors_modelB, DriveArmMotors_modelC. Note that the LLC (whichever model) is based on the Maestro functionalities [4], namely the file maestro.py, which in turn requires the pyserial Python module, that can be installed using pip (python -m pip install pyserial). The file servo.py implements some specific motion functions for the H2Arm joints; if the H2Arm motors are connected to different channels of the Pololu Maestro controller, the numbers of these new channels are to be replaced in this file. The chosen LLC version can be executed by launching it within a web-based editor such as Jupyter.

·         H2ArmBSPoptimization (Matlab 2016b, Ubuntu 16.04): it includes the files: i) BSP3Dreplanning_robot4dofReal.m implementing the BSP-based control strategy; ii) waveGen.m and waveSpectCompute.m, generating the noise distributed accordingly to the Pierson-Moskowitz spectrum [10], [11]; iii) createplan.m, Jplan.m and myconstraints.m in charge of planning the desired trajectory through the optimization of a cost functional with some constraints; iv) Ccomp.m and Wcomp.m providing computation of necessary matrices  and , respectively. It can be run by launching the command BSP3Dreplanning_robot4dofReal on Matlab console.

·         H2ArmPIDcontroller (Matlab 2016b, Ubuntu 16.04): it includes the file PIDcontroller.m implementing the PID controller and it can be run by launching the command PIDcontroller on Matlab console. The same waveGen.m and waveSpectCompute.m files (as in the BSP case) are in charge of the Pierson-Moskowitz noise generation.

Obviously, just one between the PID and the BSP controller has to be launched to perform the corresponding experiments.

 

IEEE DataPort

On IEEE DataPort [9], the user can found: i) code; ii) logged data of performed experiments; iii) CAD designs to 3D-print H2Arm and red wheel, as well as material list.

The code hosted here is organized in four different modules (as in the CodeOcean repository) and is the one that actually run during the described experiments. In the following, the main differences with the previously software components are highligthed:

·         H2ArmFindRedObj3D - Windows version (OpenCV 2.4.9, Microsoft Visual Studio 2012, Microsoft Windows 10): as before, the algorithm is implemented in the main.cpp file, and it exploits the Winsock standard library. To compile this module on Visual Studio, the user should create a standard solution, add the main.cpp as source file and add the necessary OpenCV linker dependencies (and file folders) as well (opencv_core249.lib, opencv_imgproc249.lib, opencv_highgui249.lib); to run the code it is necessary to build the solution and then launch the execution.

·         H2ArmMotorsActuation - Windows version (Python 2.7.14, conda 4.8.1, Jupyter 4.4.0, Microsoft Windows 10): the code is identical to the Linux version (except for the serial communication management), and it can be run through web-based editors like Jupyter. Again, the dependency from pyserial Python module should be resolved.

·         H2ArmBSPoptimization (Matlab 2016b, Microsoft Windows 10): the same as before, but during experiments it run over Windows 10.

·         H2ArmPIDcontroller (Matlab 2016b, Microsoft Windows 10): the same as before, but during experiments it run over Windows 10.

For each experiment, a data file, logged from the controller (BSP or PID), is saved in the controller folder with `txt' extension. The name of this family of files contains as prefix the caption ``err_BSP_'' or ``err_PID_'' depending on which controller was employed in the considered experiment. After this prefix, the file name contains information about the conditions in which the experiment was conducted: fixed or moving blob (`fb' or `mb' respectively), which type of noise (`nn' = no noise, `2ax005' = noise on 2 axes with w=0.05, `3ax0025' = noise on 3 axes with w=0.025, and so on), which test campaign (`ftc' = first test campaign, `stc' = second test campaign, `ttc' = third test campaign), experiment result (`succ' = successful, `fail' = failed) and finally the experiment number. Thus, the file named ``err_BSP_mb_3ax0035_ttc_succ_3.txt'' contains data logged by BSP controller during the third successful experiment of the third test campaign with noise on 3 axes with w=0.035.

The logged data are different according to the different bunches of experiments and employed control strategy. In particular, for both BSP and PID there are two different formats that basically differ for the dimension of the additional noise vector (2 or 3 components depending on the case). For the BSP controller the first format (2D noise vector) is made up of the following variables: writeCnt (1), m (3), z_0 (3), z (5), xdot (3), xcurr (6), qdot (4), qcurr (4), errTmp (3), rplCnt (1), i (1), cmdTime (1), wave_noise_x (1), wave_noise_y (1), where the numbers in parentheses indicate the dimension of the corresponding variable and the variable names can be found in the code. The second BSP format is: writeCnt (1), m (3), z_0 (3), z (5), xdot (3), xcurr (6), qdot (4), qcurr (4), errTmp (3), rplCnt (1), i (1), cmdTime (1), wave_noise (3).

For the PID controller, the variables recorded in the first format of logged data are: z_0 (3), z (5), xdot (3), xcurr (3), qdot (4), qcurr (4), error (3), w_error (3), w_dError (3), w_hError(3), passedTime(i) (1), wave_noise_x (1), wave_noise_y (1), qcurrSim (4), qdot2 (4). The second PID format again differs for the dimension of the noise vector and is composed by: z_0 (3), z (5), xdot (3), xcurr (3), qdot (4), qcurr (4), error (3), w_error (3), w_dError (3), w_hError(3), passedTime(i) (1), wave_noise (3), qcurrSim (4), qdot2 (4).

On DataPort, besides the CAD (.STL file) for each link, we provide a .xlsx file with the material list, including both 3D-printed elements (for each of them the same name as its corresponding CAD file is used) and commercial components to be purchased. For each item there is the indication about the needed quantity (e.g. $6$ Parallax Continuous Rotation Servos) and an approximate cost. Furthermore, the number and type of needed small metal parts are reported in the material list. Both a 3D-pdf file (Arm_Ensemble_Pdf3d.pdf) with all the needed 3D-printed elements and an overall H2Arm CAD (All Print.STL) are supplied, in such a way to show all the needed parts and how to assemble them. For the camera support, a .IGS file is provided, allowing to modify it to comply with the chosen camera mounted on the H2Arm.

 

Changing experiment parameters

In the different software modules, there are some parameters on which the user can act in order to change type of experiments. As a first example, in our tests, we run all the needed software components on the same machine, using `localhost' (i.e. 127.0.0.1) as the IP address to which the sockets connect. In case the modules run on different machines, the user should change the IP address(es): on the BSP or PID control strategy (i.e. on the corresponding Matlab .m file) the variable connCplusplus should be constructed with the IP address of the machine that is executing the H2ArmFindRedObj3D code (line 89 of the PID controller, line 109 of the BSP planning), while the variable connPy should be constructed with the IP address of the machine that is executing the H2ArmMotorsActuation code (line 8 of the PID controller, line 27 of the BSP planning).

The LLC is attached to the H2Arm hardware through a serial connection: the parameter that must be passed to the Maestro controller constructor is like `/dev/ttyS0' on Linux or `COM6' on Windows (the number of the communication channel depends on the machine running the code and must be checked by the user). As already suggested, different models were tested for the LLC, as well as different parameter sets. While for the first issue the desired LLC can be launched by executing the correct .ipynb file, for the parameter set it is mandatory to change the joint gains on the corresponding LLC code (,  for joints , respectively).

The magnitude of the additional Pierson-Moscowitz noise injected in the system (in particular, affecting the measurements of 3D blob position) can be varied through the parameter wave_scale in the BSP or PID control algorithm. Moreover, the noise could impact not on all axes (e.g. some of our experiments were performed with a noise acting only on x and y wrt frame <c>, by multiplying by zero the z component of the vector wave_noise in the BSP/PID control strategy).

Another parameter that can be modified pertains to the final Cartesian error norm: the experiment is considered successfully concluded as soon as such norm is below the threshold indicated by variable thr2 in the BSP/PID control algorithm; in our executed tests such threshold was set to the value of 0.03 m.

 

 

Launching the experiment

 

In order to perform a BSP or PID control experiment with the H2Arm, execute the following procedure:

1.       power it and connect all the needed hardware (i.e. the camera and the Pololu Maestro controller to the computer running the code);

2.       suitably compile all software components according to the hosting operating system;

3.       launch the C++ vision component FindRedObj3D. It stops waiting for the socket connection with the Matlab controller to which the vision algorithm sends the measured blob position;

4.       execute the Python Low-level control DriveArmMotors (choosing the preferred model A, B or C). This can be done by opening the Anaconda prompt and from that launching a web-based interactive development environment such as Jupyter. It stops on the socket waiting for the connection with the Matlab controller in charge of sending the arm joint velocity reference (then the Python low level control computes the appropriate motion commands to the motors);

5.       launch the BSP or PID control strategy by typing the command BSP3Dreplanning_robot4dofReal or PIDcontroller on Matlab console. It connects via sockets to the other two software components and the overall system begins to drive the H2Arm to track and center the red wheel.

It is important that the BSP/PID controller is launched as the last one, since it connects to the sockets on which the other two software components are in listening mode.

The experiment data are logged in the format described above, to be available for post-processing and analysis of results. Note that, given the extreme simplicity of the vision-based measurement algorithm (since this was not our research focus), the assumption that the red wheel is the only red blob in the scene should be made; in case another bigger red blob is in view, the H2Arm will track the latest. Moreover, a (mildly) controlled illumination condition should be guaranteed (i.e. not too dark and not too bright), in order to allow the algorithm to correctly segment the red blob in the image.

 

The BSPvsPID comparison can be found in the reproducible article [12], whose major details are provided in [13].

References

[1] Detection of arUco markers. [Online]. Available: https://docs.opencv.org/trunk/d5/dae/tutorial_aruco_detection.html [2] P. Corke,Robotics, Vision & Control. Springer, 2017. [3] Pololu drivers. Accessed on February 28, 2020. [Online]. Available: https://www.pololu.com/docs/0J40/ [4] PololuMaestro. Pololu maestro servo driver.[Online]. Available: https://github.com/FRC4564/Maestro/ [5] H2ArmFindRedObj3D capsule. [Online].Available: https://codeocean.com/capsule/4484239/tree [6] H2ArmMotorsActuation capsule. [Online]. Available: https://codeocean.com/capsule/1176426/tree [7] H2ArmBSPoptimization capsule. [Online]. Available: https://codeocean.com/capsule/9382975/tree [8] H2ArmPIDcontroller capsule. AccessedFebruary28,2020.[Online]. Available: https://codeocean.com/capsule/0724635/tree [9] IEEE-DataPort. H2Arm repository. [Online]. Available: https://ieee-dataport.org/open-access/h2arm-bsp-vs-pid-experiments [10] W.  J.  Pierson  and  L.  Moskowitz,  “A  proposed  spectral  form  for fully  developed  wind  seas  based  on  the  similarity  theory  of  SA Kitaigorodskii,”Journal of geophysical research, vol. 69, no. 24, pp.5181–5190, 1964 [11] Smart-coding.Irregularoceanwavegenerationcodesformatlab/simulink. [Online]. Available: http://www.smart-coding.net/irwave/ [12] F. Bonsignorio and E. Zereik, “An experimental comparison of BSP and PID controllers for a simple visual–servoing task on a low accuracy low cost arm”, IEEE Robotics and Automation Magazine, submitted [13] F. Bonsignorio and E. Zereik, “An experimental comparison of BSPand PID controllers for a simple visual–servoing task on a low accuracy low cost arm, supplemental information”, IEEE Robotics and Automation Magazine, submitted.

Dataset Files

You must login with an IEEE Account to access these files. IEEE Accounts are FREE.

Sign Up now or login.

Embed this dataset on another website

Copy and paste the HTML code below to embed your dataset:

Share via email or social media

Click the buttons below:

facebooktwittermailshare
[1] Enrica Zereik, Fabio Bonsignorio, Angelo Odetti, "H2Arm - BSP vs PID experiments", IEEE Dataport, 2020. [Online]. Available: http://dx.doi.org/10.21227/4692-2z85. Accessed: Feb. 28, 2020.
@data{4692-2z85-20,
doi = {10.21227/4692-2z85},
url = {http://dx.doi.org/10.21227/4692-2z85},
author = {Enrica Zereik; Fabio Bonsignorio; Angelo Odetti },
publisher = {IEEE Dataport},
title = {H2Arm - BSP vs PID experiments},
year = {2020} }
TY - DATA
T1 - H2Arm - BSP vs PID experiments
AU - Enrica Zereik; Fabio Bonsignorio; Angelo Odetti
PY - 2020
PB - IEEE Dataport
UR - 10.21227/4692-2z85
ER -
Enrica Zereik, Fabio Bonsignorio, Angelo Odetti. (2020). H2Arm - BSP vs PID experiments. IEEE Dataport. http://dx.doi.org/10.21227/4692-2z85
Enrica Zereik, Fabio Bonsignorio, Angelo Odetti, 2020. H2Arm - BSP vs PID experiments. Available at: http://dx.doi.org/10.21227/4692-2z85.
Enrica Zereik, Fabio Bonsignorio, Angelo Odetti. (2020). "H2Arm - BSP vs PID experiments." Web.
1. Enrica Zereik, Fabio Bonsignorio, Angelo Odetti. H2Arm - BSP vs PID experiments [Internet]. IEEE Dataport; 2020. Available from : http://dx.doi.org/10.21227/4692-2z85
Enrica Zereik, Fabio Bonsignorio, Angelo Odetti. "H2Arm - BSP vs PID experiments." doi: 10.21227/4692-2z85