Systems Realization Laboratory Compact Rescue Crawler ME /26/07 Jonathan Jobe Andrew Marshall Chris Weir

Systems Realization Laboratory Intro to Application Domain  Fluid Power – Pneumatics, part of the NSF funded Fluid Power ERC  Robotics – Serial Robot Vehicle, 6 legs: Hexapod  Kinematic design for a robot vehicle Modeled design was to be optimized for this course Model must be interfacable for later use in control design & optimization

Systems Realization Laboratory Interesting Aspects:  FP test bed vehicle – Model must interface with other design groups Future models to interface: valves, lines, pneumatic source, controls  Desire to simulate walking on flat ground terrain Separates a grounded simulation from a “free body structure”  Included Tutorial (Visio diagram) STL procedure for Geometric Visualization Mass and Inertial properties procedure for Dynamic Physical Effects  Problems we encountered Wrapper Difficulties Maintaining Physical Experiment Requirements  Overall Utility Method  Suggestions / Requests for Software Improvement  Future Work

Systems Realization Laboratory Physical Design  Design Variables  Parameters for Dynamic Model Inertia tensors, Center of Mass.stl files to represent geometry Mass computations from multidensity assemblies Uncertain params – damping, fluid pressure, ground reaction forces

Systems Realization Laboratory Designing in Dymola

Systems Realization Laboratory STLsProE Properties Orig. created for Stereolithography (rapid prototyping surface data)

Systems Realization Laboratory Solving Wrapping Difficulties  Problem: In Dymola Components, if a parameter is used to define a relationship for another parameter within the same code, it will be an unchangeable input quantity in the variable browser of the simulation window.  Hence, it is unchangeable in the wrapper, even though it shows up in the input file.  Solution: Remove the variable dependency. Sometimes this requires creating a custom version of the component.

Systems Realization Laboratory Preserving Experimental Requirements  Problem: Ensuring the experiment is followed every time, regardless of uncertain variable values or design variable values Experiment was a step ‘gait’ for a single leg  Proposed Solutions: Require leg end effector path as experimental definition  Problem: Different sized legs cannot always follow the same gait if it doesn’t fit Require leg angles as a function of time  Problem: Stroke and other params of the actuators are required to change in order to preserve range of motion  Problem: With a position-based control system, similar actuators could perform different experiments. Our control required actuator full range of movement. Incorporate an experimental failure flag in Dymola, so legitimate runs are used for data in Model Center  Our Solution: leg angles = f(t,…) & custom actuator strokes

Systems Realization Laboratory Design Variable Dependencies Adding Length

Systems Realization Laboratory Utility Function Work  Used Excel sheet to update utility surface visual aid as preferences were elicited Prevented conflicts & preserved preferential independence

Systems Realization Laboratory Suggestions for Improvement: Model Center  Unavailability of information during active simulations  LHS variable name pass-thrus are a problem when linking or viewing results  Multi-nested model execution Uninformed of what is being executed (other than visual block highlighted) No progress monitoring – only works sometimes with the ‘bar’ Optimizer needs to provide feedback  Information within its log file or a separate trade study file of runs used to pick next step direction and line length  Some solution ideas:  Notifier – for failed runs, completed simulations, etc.  Detailed progress monitoring  Better handling of complicated executables like Dymosim.exe (see slide notes)

Systems Realization Laboratory Future Work  Ground model  Model validation Validating input force vectors at leg end effector for single-leg simulations  Data from ground model, or full walking vehicle simulation Using Physical Test on CRC Test Bed and list of experiments Running model with Phantom input vectors, and validating against physical sensor output vectors  Test tracking module So that model does not fail (preserve experimental requirements)  Integration of pneumatic control to drive the robot leg Simulink Controls Module Dymola Model in Simulink interfaced with Controls module