-
Notifications
You must be signed in to change notification settings - Fork 1
YAML Parameters
When mounting a soft manipulator to the test setup, it is important that you load a YAML file which is at least somewhat related to your arm.
Whatever code you run should load your YAML into the SoftTrunkParameters and finalize them. Any changes you make to the YAML are then loaded upon program start.
YAML files must be placed in the config/ directory to be loaded.
SoftTrunkParameters st_params;
st_params.load_yaml("example_yaml.yaml");
st_params.finalize(); //if the parameters are not finalized, they will be rejectedAutogenerated YAML files do not have comments. Therefore, all parameters are explained here in case someone overwrites the example YAML.
All vectors relating to physical robot parameters follow the general scheme of top-down. That means the first element of the vector is the parameter of the topmost segment, and the last element is relating to the final segment or a gripper if applicable. The segment naming scheme is also related to this. The topmost segment is referred to as segment 0 both in code and YAML. [segment 0, segment 1, ..., segment n, gripper]
Name of the robot. This influences what the autogenerated URDF will be called and acts as an identifier.
This is a boolean indicating if there is a prismatic joint mounted at the base of the arm.
Number of physical continuum segments the manipulator has. Each seperately actuatable segment must be considered. Default SoPrA as of 18.03.2022 has 2 segments.
Amount of PCC segments used to model each physical continuum segment. Using more than 1 was proven to have diminishing returns in Toshimitsu et al. 2021 SoPrA, so just use 1 unless you REALLY know what you're doing.
Masses which will be used to derive gravity, inertia etc. Masses start from the topmost segment (segment 0) and move towards the bottom. Both segment mass and connector piece mass are considered. If your arm does not have connector pieces, simply enter 0 whereever the connectors are found. The final element of the vector is the mass of an (optional) gripper at the tip. If not using a gripper, set it to 0.
[segment 0 mass, connector(0-1) mass, segment 1 mass, ..., segment n mass, gripper mass]
Lengths of segments and connectors. Same naming convention as with masses.
[segment 0 length, connector(0-1) length, segment 1 length, ..., segment n length, gripper length]
This relates to segment diameters and tapering. The first element is the topmost segment's top diameter, and the second element is the topmost segment's bottom diameter. This is due to SoPrA being tapered. The diameters are used to calculate actuation parameters. The design of SoPrA means that a segment's top diameter will always be equal to the previous segment's bottom diameter, therefore the list has (2*num_segments - 1) elements instead of 2*num_segments.
[segment 0 top diameter, segment 0 bottom diameter, segment 1 bottom diameter, segment 2 bottom diameter, ..., segment n bottom diameter]
Shear moduli of each segment. Shear modulus affects how stiff the segment is modeled to be, i.e. how much it wants to return to a straight configuration. These values can be automatically obtained with characterization scripts, as shear moduli different from material parameters have been observed.
[segment 0 shear modulus, segment 1 shear modulus, ...]
Drag coefficient modelling air resistance, internal damping. Same naming convention as shear modulus. At the moment, heuristic values are used.
[segment 0 drag coefficient, segment 1 drag coefficient, ...]
This vector maps between ValveController outputs and manipulator chambers to ensure the manipulator is sending pressures to the correct places.
The order for a segment is [x chamber, -x,-y chamber, -x,y chamber] where the x chamber is placed on the x-coordinate side of the robot (and therefor actuates the robot in -x direction). The map is then this repeated for each chamber. If a prismatic joint is mounted, the first 2 values are additionally [piston, mckibbens].
If this is confusing to you, just use the Characterize::valvemap() command, it automizes the process.
Influences how frequently the sensors fetch new state data. The unit is Hz. If this value is too high for a sensor, it will use its maximum refresh rate.
Influences how frequently the model updates its dynamic parameters (gravity, intertia etc.). Unit Hz. Beware from setting this too high, as your computer might not be able to follow.
Serial address of the BendLabs sensors. Only required if using a BendLabs sensor for state estimation.
This is dedicated to the "real" A matrix, as the perfect assumption of
does not hold. This vector is dedicated to the "real" values, and should only be obtained with the characterization script (Characterize::actuation(segment))
All sensors which are to be used. Possible choices at the moment are qualisys, bendlabs, and simulator.
If multiple sensors are used, the "main" state is obtained by filtering.
Basis from which dynamic parameters are derived. Possible choices at the moment are augmented and lagrange.
augmented is the AugmentedRigidBody formulation which uses rigid links to approximate the soft manipulator.
lagrange uses Lagrangian Energy methods to directly derive the parameters, but is however restricted to 2 segment robots only.