¶ Hardware setup
To use the locomat for trajectory following, the hardware needs to be correctly set-up. Normally the setup should already be correct and little needs to be changed, check whether the following matches the current system.
¶ !!Add images!!
- Ethernet cables must be correctly connected before turning on the system components. For safety, do not hotwire / hotswitch these cables (Do not pull them out or put them in when the system is powered).
- Blue ethernet cable from working computer (on the table besides the Locomat, has the Matlab, Simulink and other software) to the external pc (2nd port from below, above the one labelled Ethercad)
- Blue cable in port labelled Ethercad to the Linmot controller (Back of pc, top right between the motor drivers labelled axis 3-6, left port labelled xpc)
- Yellow cable from right port (labelled E1250) to pelvis driver below (top right)
- Blue cable from pelvis driver (top left) to behind the back support (left port)
__
- Computers connected to power source and turned on
- Two white power strips (stekkerdozen) need to be powered. One for the internal/original Locomat hardware, one for the external XPc.
- These power strips can be manually turned on or off. This is a good use to shut off power without needing to remove anything from the sockets.
- The external XPc power strip has a connected manual override switch (big red button on the floor). Check whether these is extended, otherwise the power to the linear actuators of the legs is shut off.
- If you are working with the Locobase, check if the power is on, green lights on the metal box, on the floor beside the pole.
__
¶ Software replay trajectory
Steps to take on the pc to start running a saved trajectory. A standard trajectory is loaded when using the init function, the method to change this trajectory is not yet determined.
- Open Matlab on the pc
- If a GUI opens, ignore and close it
- Go to the model to be loaded into the xpc
- Standard model: Locomat Control Software/LokoNew2021.06.10/FullModel/LokoFreeNew.slx
- Type: ‘init’ into the console, load parameters / run the
init.mscript - Compile the model, ensures possible changes and validity
- If you compile while in the wrong folder, a lot of new files are created in that folder. Delete those manually to keep the structure clean. Then go to the right folder and recompile.
- Type:
xpcexplrinto the console to open connection with xpc - Connect with the Locofree
- Load the model (Browse to the slx file)
- Check the screen if the model is loaded
- Run the model
- Check the screen if it runs succesfully, scopes should update
- To start the motors following a trajectory, type:
setparam(tgfree,getparamid(tgfree,'supervision/startWalk','Value'),1)in the console. This should start the motors. To stop the motors, use the same command but change the last 1 to a 0.
Currently, the LI linear actuator (Axis 6) does not function correctly. In the standard model both left actuators are turned off to prevent damage, the right leg and the pelvis still move. To change which linear actuators are used, go to the model, enter ‘supervision’. Near the bottom there is a set of constants labelled ‘enableXXX’. a 1 means the motor is used, a zero turns it off.
¶ Software save new trajectory
To Be Added
¶ Simulink model
This is repetition so that all information is on a single page for ease of use.
- Notes:
- Motor position should be set in meters (as per init script comments)
Steps:
- Run the
init.mscript - Compile/build the model (make sure your working directory is the correct one, use subfolders!!)
xpcexplr- Connect, load the just created model
- If no errors, start the model
To load a different model
xpcexplr- stop the current model if it is still running
- unload the model
- load the new one
- start
¶ Different models
Different partial models were created in building steps, building towards the full model as found in Lokofree.mdl. Note that the models are saved as slx files, which is the new file format and mdl is the legacy file format (see here)
- Whereas .mdl files are single text files, .slx files are compressed packages (source)
SettingsOnly.slx
- An empty model only in which the settings are (manually) matched to that of the
LokoFree.mdlmodel- For more information about these settings: [[LokoFree.mdl]]
Sensors.slx
- Only the Sensors subsystem and the EtherCAT configuration blocks are present in this model
- This is perfect for if you just want to see if all the sensors are connected correctly and their values make sense (by placing scopes and reading out values). You don’t need to load any parameters for this other than the
Tsvalue, which should be0.002and can be set from the matlab console by typingTs=0.002
Supervision.slx
- This model has the Supervision subsystem added to the Sensors model.
- This doesn’t add any additional functionality directly, as nothing in the subsystem is actually sent out to the EtherCAT slaves yet.
- However, a lot of parameters are used now (e.g. the motor limits, and Qualsys serial camera settings…). To make sure all these parameters are defined in the workspace, run the
init.mscript by typinginitin the console (assuming the working directory is the root directoryLokoNew2021....) - Supervision contains the state machines which control a lot of the rest of the model. The way in which this happens, is explained in the following models.
Control.slx
Supervision.slx+ the Control subsystem.- Control/Trajectory_Generator
- There’s a matlab Fcn blok converting between the Orthosis motor positions (LA, LI, RA, RI) to knee positions with some simple math (to account for the bar link system). (Not exactly sure which way the conversion happens here…)
- The
trajenablervariable originating from one of the state machines in Supervision toggles the reading out of the trajectory data from thetrajectories_dario.mat
- Control/Pelvis - Outputs
MotorRefForcePelvis, depending on value ofpelvis_enable(1=on,0=off)PelvisControlModevariable is used to switch between1: PositionControlmodeOrthused to switch between Orthesis control modes (see Hardware_Out/OutputOrtheses)1:ref_smooth- output of tanh transition - ref=0- Multiplies the error
ebetweenref_posandact_posby some smoothing value (tanh something)?.. - For this block, the
ref_pos=0always. So we’re always moving towards zero? --> Stabilizing mode maybe?
- Multiplies the error
2: =13:ref_smooth- output of tanh transition- Same as for
1, except the reference positionref_posis equal to thepelvis_reffromPelvis/Trajectory_generator
- Same as for
4: the rawpelvis_reffrom thePelvis/Trajectory_generator5: =16: =1
- VirtualWallPelvis - is a sort of forbidden region, setting a boundary (default at
0.1m) on each side from where a virtual spring will pull the pelvis back into the middle
2: ZeroForce - Probably used to make the system feel as light as possible, following the human movements
- Control/Orthoses - Control of the Knee’s, outputs
motforce_knee_landmotforce_knee_r. combined intomotor_commands_orthoses- PD_PositionKL and PD_PositionKR are almost identical to that of Control/Pelvis/PositionControl, where the reference input is
kneeL_refandkneeR_ref
- PD_PositionKL and PD_PositionKR are almost identical to that of Control/Pelvis/PositionControl, where the reference input is
- Control/BWS outputs
MotorRefForceBWS- PD_PositionBWS is almost identical to that of Control/Pelvis/PositionControl, where the reference input is
bws_ref - VirtualWallBWS is almost identical to VirtualWallPelvis, with default boundary at
0.06mfor the position limit.
- PD_PositionBWS is almost identical to that of Control/Pelvis/PositionControl, where the reference input is
HardwareOut.slx
Control.slx+ the Hardware_Out subsystem.- Hardware_Out/OuputBWS
- sends force control data to
AD622 Humusoft Analog Outputcontrolforce_knee_lcontrolforce_knee_rMotorRefForceBWSas long asenableMaxons=1(comes from Supervision)
- Sends
enableMaxonstoAD622 Humusoft Digital Output(probably to toggle the above three force commands).
- sends force control data to
- Hardware_Out/OutputPelvis
motor_command(from supervision) is sent to the Control Word of the motorMotorRefForcePelvisis converted to a requiredcurrentdemandin LinMotConversionenablePelvisif0, sets the motor commands to0
enablesignal comes from State machine in Supervisor can be0: Pelvis motors disabled, motorheader=par=01: Pelvis motor homing.header=144,par=homeposition*10^7wherehomepositionis actuallyPelvisPotifrom Sensors2: Pelvis current commanding,header=14592(header for current demand),par=currentdemand
- Repeating Sequence block flips between setting the first and the second bit of the commandheader…??
- Hardware_Out/OutputOrtheses has 1 subsystem for each of the LinMot motors. Each of these is structured in the same way:
motor_command(from supervision) is sent to the Control Word of the motor- LinMotModeSwitcher uses
modeOrthto switch the mode of the orthoses:1: Homing (par=homeposition*10^7, wherehomeposition=Linmot_abspos_LAfor LA motor coming from Sensors)2: Go to intial position3: Go to start position for trajectory4: Walk5: skipped?..6: Ad-abductionother: all commands set to0
¶ Software notes
Working with the models, certain guidlines exist. As the Lokomat models consist of many different files and layers, it is important to keep structured.
Scope
To read data to the included hardware screens, scopes can be used. Scope blocks set to target the xPC will be visible on screen. For validation or other purposes it might be desired to read the values of a variable many layers deep in the code, do not put a scope there! Instead, add a data store element in the top layer and write to that. Then, the data store can be read in the logger, where the scopes are placed. Keeping all the scopes in the same places improves visibility.
1: Place a data store memory block in the top layer, name it clearly (e.g. “Scope_Camera”)
- Ensure consistent naming
- Check if size of the data store memory matches what variables you want to write to it
2: Write to this data where needed
3: Read this data in the logger, attach it to a scope
NOTE: The scopes seem to be read/placed in order of the ‘data store read’ numerical values, not per scope index. Change these values as needed to move the scope around and take care to make the naming clear even when mispositioned.
¶ Errors that might occur
could not set master state to PREOP
Most likely one of the following has gone wrong:
- One or more of the EtherCAT slave devices is not powered and/or connected properly
- The ENI file used is not representative of the current network setup
Sometimes fixing this is as simple as pushing in the Ethernet cables a little bit (if the little clips are broken especially, they might come loose a bit when moving the cables around).
Check if any of the red RT Bus Error LEDs are burning on the LinMot drivers. If they do, one of the following might have caused it:
- Ethernet cables aren’t connected properly
- Some software error
- Check all connections
- Unpower all motors and the xPC
- Re-power all motors and the xPC
- Check if red LEDs have turned off
Note that if this crash happens, there is no way to recover, and the xPC should be rebooted…
CPU overload
This happens when you leave the model running for too long (at ~5 min of runtime).
You’ll need to reboot the xPC to be able to load another model
Prevent this by stopping the model in time.
ERROR: Model reload required
Unfortunately, you need to reload model after every run…
If after starting the model you get the error:
Error in emExecJob
ERROR: invalid parameter
(or some other error or no error at all), and the whole system hangs. The xPC needs to reboot fully to be usable again (you can’t even ping the system).
To prevent this, always just unload the model after stopping it (never try to start it twice). Not sure why this is required.
Character Encoding error: When open the model (in simulink) you get the following error:
To fix: simply run the command slCharacterEncoding(‘windows-1252’) and re-open the model.
¶ RT Bus Error LEDs
- When you stop running the model, the red LED starts blinking, the model will still load and run again
- And then the red LED will turn off again