Authors:
(1) Jorge Francisco Garcia-Samartın, Centro de Automatica y Robotica (UPM-CSIC), Universidad Politecnica de Madrid — Consejo Superior de Investigaciones Cientıficas, Jose Gutierrez Abascal 2, 28006 Madrid, Spain (jorge.gsamartin@upm.es);
(2) Adrian Rieker, Centro de Automatica y Robotica (UPM-CSIC), Universidad Politecnica de Madrid — Consejo Superior de Investigaciones Cientıficas, Jose Gutierrez Abascal 2, 28006 Madrid, Spain;
(3) Antonio Barrientos, Centro de Automatica y Robotica (UPM-CSIC), Universidad Politecnica de Madrid — Consejo Superior de Investigaciones Cientıficas, Jose Gutierrez Abascal 2, 28006 Madrid, Spain. Table of Links Abstract and 1 Introduction 2 Related Works 2.1 Pneumatic Actuation 2.2 Pneumatic Arms 2.3 Control of Soft Robots 3 PAUL: Design and Manufacturing 3.1 Robot Design 3.2 Material Selection 3.3 Manufacturing 3.4 Actuation Bank 4 Data Acquisition and Open-Loop Control 4.1 Hardware Setup 4.2 Vision Capture System 4.3 Dataset Generation: Table-Based Models 4.4 Open-Loop Control 5 Results 5.1 Final PAUL version 5.2 Workspace Analysis 5.3 Performance of the Table-Based Models 5.4 Bending Experiments 5.5 Weight Carrying Experiments 6 Conclusions Funding Information A. Conducted Experiments and References 4.3 Dataset Generation: Table-Based Models Due to the complexity of the robot, model-based methodologies, such as PCC or the ones based on Cosserat Rod Theory were discarded. Although the usage of FEM is an avenue that will not be closed in future work, the large number of parameters to be set experimentally for each segment (Young’s modulus, moment of inertia. . . ), given that the manufacturing process is so variable meant that, in this first phase, we opted to use some type of PAUL modelling based on data collection. The output of the system is taken as the position and orientation reached by the final end –thus, at this stage, all the positions of the intermediate segments are ignored– and as input, the inflation times of each of the bladders. As there were not enough pressure sensors available at the time of the construction of the robot, it was decided to take inflation time as an input variable. As the working pressure is limited by the pressure limiting valve and the flow rate into each bladder can be assumed to be constant, the time is equivalent to the volume of air introduced into each cavity. All the control options considered have in common the need for a large amount of empirical data, which leads to the need to develop an experimental design to systematise the collection of this data. Since the capture of this information is done in different phases and the datasets have to represent the behaviour of the robot in an objective way, the re-applicability of the experiment takes on special importance. The data stored in the datasets was the position of the robot tip and the set of inflation times that achieve this configuration. The aforementioned limitation that only two of the three bladders in the segment are inflated reduces redundancies. As previously stated, more than two segments lead to redundancies, which implies that the inverse kinematic model of the robot can have multiple solutions. The data collection process involves several sequential steps. Initially, a set number of samples is determined. For each sample, Matlab commands dispatch a random combination of nine inflation times, corresponding to each valve of PAUL, to the actuation bench. Times are generated below a maximum time limit Tmax, and ensuring that only two cavities per segment are inflated. Following this, the robot’s bladders are inflated based on the sent times. Subsequently, the vision system’s two cameras capture images to determine the position and orientation of the robot’s end. This entire procedure is repeated for the specified number of iterations, and upon completion, the collected data is stored in the dataset The information on swelling times is stored as a percentage, with a value of 0 corresponding to a zero swelling of that segment and 100 corresponding to Tmax, the swelling for the maximum number of milliseconds defined for this data collection session. This value Tmax is stored, together with the values, in the dataset, in order to be able to compare different datasets. The reason for this coding comes from the lack of information, a priori, on what is the maximum pressure that a PAUL bladder admits. Although it is true that it was experimentally determined that inflation times of more than 1500 ms in a row led to punctures, the application of lower times during a repeated number of cycles also generated leaks. On this basis, it was decided never to inflate any valve, either in one or several steps, more than 1000 ms. Along with the inflation times of each bladder, the position and orientation reached by the end tip is stored, based on the camera readings. In particular, the position of the green marker and the orientation of the trihedron are stored. The latter is expressed in Euler angles, as it is a much efficient form of storage than a rotation matrix. In addition, the dataset also contains metadata from the collection process that are believed to influence the results, such as the pneumatic line pressure or the ambient temperature. Some aspects in the pneumatic system merit attention. Initially, bladder inflation and deflation are not symmetrical processes. Geometric constraints in the pneumatic components result in a lower deflation rate compared to inflation. Consequently, when the PAUL receives a deflation time, it multiplies it by an empirically derived factor, approximately 1.45 for a 1.2 bar working pressure. This multiplier compensates for the discrepancy between inflation and deflation times of a singular group of bladders, ensuring that the deflation time aligns with the time required to reach the same inflation point. Similarly, although it is physically possible to inflate several valves at the same time, it has been shown that this parallel flow distribution means that the effective fillings of each valve are not the same as if they were inflated individually. To prevent this phenomenon, it was decided to inflate each bladder individually both during the data acquisition process and utterly, when PAUL was asked to reach certain positions. Finally, there are hysteresis phenomena in the silicone that cause the position reached by inflating for a time t to be different from the position reached by inflating first for a time t1 and then for a time t2 = t − t1. The strategy employed to tackle this problem was to capture the dataset bringing PAUL back to its zero position between each sample. Nevertheless, when controlling the robot in open-loop this is not possible, or, at least, not desirable, as one may wish to follow trajectories or travel through a sequence of points. Therefore, transitioning from position x1 to x2 requires an additional factor of 1.2, also derived experimentally, to account for hysteresis effects. 4.4 Open-Loop Control Once the dataset is generated, it can be used to model the behaviour of PAUL for open-loop control. It is foreseen, as a future line, to train a neural network for the direct kinematics and another one for the inverse kinematics. However, given the large amount of data that may be required (in [62] 24389 samples are used for a three-segment robot like this one), a table look-up method has been used for this work. The method for direct kinematics –which allows obtaining the position and orientation of the final end of the robot from the inflation times of the nine bladders– consists of searching, in the generated dataset in the previous step, the three inflation time values located at a shorter distance from the inflation time given as a reference. Obviously, if the set of inflation times sought were in the table, the value associated with these times would be returned as a result of the direct kinematic model. Otherwise, the average of the position and orientation values associated with the three closest inflation times, weighted by the distance (Euclidean norm) existing between each of them and the values of reference inflation times, is returned as the position and orientation value of the robot. with them, it is possible to calculate the position returned by the direct kinematic model using the expression: This paper is available on arxiv under CC BY-NC-SA 4.0 DEED license. Authors: (1) Jorge Francisco Garcia-Samartın, Centro de Automatica y Robotica (UPM-CSIC), Universidad Politecnica de Madrid — Consejo Superior de Investigaciones Cientıficas, Jose Gutierrez Abascal 2, 28006 Madrid, Spain (jorge.gsamartin@upm.es); (2) Adrian Rieker, Centro de Automatica y Robotica (UPM-CSIC), Universidad Politecnica de Madrid — Consejo Superior de Investigaciones Cientıficas, Jose Gutierrez Abascal 2, 28006 Madrid, Spain; (3) Antonio Barrientos, Centro de Automatica y Robotica (UPM-CSIC), Universidad Politecnica de Madrid — Consejo Superior de Investigaciones Cientıficas, Jose Gutierrez Abascal 2, 28006 Madrid, Spain. Authors: Authors: (1) Jorge Francisco Garcia-Samartın, Centro de Automatica y Robotica (UPM-CSIC), Universidad Politecnica de Madrid — Consejo Superior de Investigaciones Cientıficas, Jose Gutierrez Abascal 2, 28006 Madrid, Spain (jorge.gsamartin@upm.es); (2) Adrian Rieker, Centro de Automatica y Robotica (UPM-CSIC), Universidad Politecnica de Madrid — Consejo Superior de Investigaciones Cientıficas, Jose Gutierrez Abascal 2, 28006 Madrid, Spain; (3) Antonio Barrientos, Centro de Automatica y Robotica (UPM-CSIC), Universidad Politecnica de Madrid — Consejo Superior de Investigaciones Cientıficas, Jose Gutierrez Abascal 2, 28006 Madrid, Spain. Table of Links Abstract and 1 Introduction Abstract and 1 Introduction 2 Related Works 2.1 Pneumatic Actuation 2.1 Pneumatic Actuation 2.2 Pneumatic Arms 2.2 Pneumatic Arms 2.3 Control of Soft Robots 2.3 Control of Soft Robots 3 PAUL: Design and Manufacturing 3.1 Robot Design 3.1 Robot Design 3.2 Material Selection 3.2 Material Selection 3.3 Manufacturing 3.3 Manufacturing 3.4 Actuation Bank 3.4 Actuation Bank 4 Data Acquisition and Open-Loop Control 4.1 Hardware Setup 4.1 Hardware Setup 4.2 Vision Capture System 4.2 Vision Capture System 4.3 Dataset Generation: Table-Based Models 4.3 Dataset Generation: Table-Based Models 4.4 Open-Loop Control 4.4 Open-Loop Control 5 Results 5.1 Final PAUL version 5.1 Final PAUL version 5.2 Workspace Analysis 5.2 Workspace Analysis 5.3 Performance of the Table-Based Models 5.3 Performance of the Table-Based Models 5.4 Bending Experiments 5.4 Bending Experiments 5.5 Weight Carrying Experiments 5.5 Weight Carrying Experiments 6 Conclusions 6 Conclusions Funding Information Funding Information A. Conducted Experiments and References A. Conducted Experiments and References 4.3 Dataset Generation: Table-Based Models Due to the complexity of the robot, model-based methodologies, such as PCC or the ones based on Cosserat Rod Theory were discarded. Although the usage of FEM is an avenue that will not be closed in future work, the large number of parameters to be set experimentally for each segment (Young’s modulus, moment of inertia. . . ), given that the manufacturing process is so variable meant that, in this first phase, we opted to use some type of PAUL modelling based on data collection. The output of the system is taken as the position and orientation reached by the final end –thus, at this stage, all the positions of the intermediate segments are ignored– and as input, the inflation times of each of the bladders. As there were not enough pressure sensors available at the time of the construction of the robot, it was decided to take inflation time as an input variable. As the working pressure is limited by the pressure limiting valve and the flow rate into each bladder can be assumed to be constant, the time is equivalent to the volume of air introduced into each cavity. All the control options considered have in common the need for a large amount of empirical data, which leads to the need to develop an experimental design to systematise the collection of this data. Since the capture of this information is done in different phases and the datasets have to represent the behaviour of the robot in an objective way, the re-applicability of the experiment takes on special importance. The data stored in the datasets was the position of the robot tip and the set of inflation times that achieve this configuration. The aforementioned limitation that only two of the three bladders in the segment are inflated reduces redundancies. As previously stated, more than two segments lead to redundancies, which implies that the inverse kinematic model of the robot can have multiple solutions. The data collection process involves several sequential steps. Initially, a set number of samples is determined. For each sample, Matlab commands dispatch a random combination of nine inflation times, corresponding to each valve of PAUL, to the actuation bench. Times are generated below a maximum time limit Tmax, and ensuring that only two cavities per segment are inflated. Following this, the robot’s bladders are inflated based on the sent times. Subsequently, the vision system’s two cameras capture images to determine the position and orientation of the robot’s end. This entire procedure is repeated for the specified number of iterations, and upon completion, the collected data is stored in the dataset The information on swelling times is stored as a percentage, with a value of 0 corresponding to a zero swelling of that segment and 100 corresponding to Tmax, the swelling for the maximum number of milliseconds defined for this data collection session. This value Tmax is stored, together with the values, in the dataset, in order to be able to compare different datasets. The reason for this coding comes from the lack of information, a priori, on what is the maximum pressure that a PAUL bladder admits. Although it is true that it was experimentally determined that inflation times of more than 1500 ms in a row led to punctures, the application of lower times during a repeated number of cycles also generated leaks. On this basis, it was decided never to inflate any valve, either in one or several steps, more than 1000 ms. Along with the inflation times of each bladder, the position and orientation reached by the end tip is stored, based on the camera readings. In particular, the position of the green marker and the orientation of the trihedron are stored. The latter is expressed in Euler angles, as it is a much efficient form of storage than a rotation matrix. In addition, the dataset also contains metadata from the collection process that are believed to influence the results, such as the pneumatic line pressure or the ambient temperature. Some aspects in the pneumatic system merit attention. Initially, bladder inflation and deflation are not symmetrical processes. Geometric constraints in the pneumatic components result in a lower deflation rate compared to inflation. Consequently, when the PAUL receives a deflation time, it multiplies it by an empirically derived factor, approximately 1.45 for a 1.2 bar working pressure. This multiplier compensates for the discrepancy between inflation and deflation times of a singular group of bladders, ensuring that the deflation time aligns with the time required to reach the same inflation point. Similarly, although it is physically possible to inflate several valves at the same time, it has been shown that this parallel flow distribution means that the effective fillings of each valve are not the same as if they were inflated individually. To prevent this phenomenon, it was decided to inflate each bladder individually both during the data acquisition process and utterly, when PAUL was asked to reach certain positions. Finally, there are hysteresis phenomena in the silicone that cause the position reached by inflating for a time t to be different from the position reached by inflating first for a time t1 and then for a time t2 = t − t1. The strategy employed to tackle this problem was to capture the dataset bringing PAUL back to its zero position between each sample. Nevertheless, when controlling the robot in open-loop this is not possible, or, at least, not desirable, as one may wish to follow trajectories or travel through a sequence of points. Therefore, transitioning from position x1 to x2 requires an additional factor of 1.2, also derived experimentally, to account for hysteresis effects. 4.4 Open-Loop Control Once the dataset is generated, it can be used to model the behaviour of PAUL for open-loop control. It is foreseen, as a future line, to train a neural network for the direct kinematics and another one for the inverse kinematics. However, given the large amount of data that may be required (in [62] 24389 samples are used for a three-segment robot like this one), a table look-up method has been used for this work. The method for direct kinematics –which allows obtaining the position and orientation of the final end of the robot from the inflation times of the nine bladders– consists of searching, in the generated dataset in the previous step, the three inflation time values located at a shorter distance from the inflation time given as a reference. Obviously, if the set of inflation times sought were in the table, the value associated with these times would be returned as a result of the direct kinematic model. Otherwise, the average of the position and orientation values associated with the three closest inflation times, weighted by the distance (Euclidean norm) existing between each of them and the values of reference inflation times, is returned as the position and orientation value of the robot. with them, it is possible to calculate the position returned by the direct kinematic model using the expression: This paper is available on arxiv under CC BY-NC-SA 4.0 DEED license. This paper is available on arxiv under CC BY-NC-SA 4.0 DEED license. available on arxiv

Part of HackerNoon's growing list of open-source research papers, promoting free access to academic material.

Why PAUL Needs a Massive Dataset to Improve Its Movements

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

5 Ways to Measure Privacy Risks in Text Data

Meet PAUL: A Soft Robot That Moves with Air Pressure

Soft, Squeezable, and Smarter Than Ever: The Rise of Pneumatic Robots

How Scientists Are Teaching Soft Robots to Move Accurately

Designing PAUL: A Soft Robot with Pneumatic Precision

How PAUL, a Soft Robot, is Designed and Built

5 Ways to Measure Privacy Risks in Text Data

Meet PAUL: A Soft Robot That Moves with Air Pressure

Soft, Squeezable, and Smarter Than Ever: The Rise of Pneumatic Robots

How Scientists Are Teaching Soft Robots to Move Accurately

Designing PAUL: A Soft Robot with Pneumatic Precision

How PAUL, a Soft Robot, is Designed and Built

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps