Change safety.py to use lizard PR 139

[Johannes-Thiel]

Motivation

At the moment we have some very basic safety checks in lizard.

when estop_1.level == 0 then stop(); end
when estop_2.level == 0 then stop(); end
when bumper_front_top.level == 1 then stop(); end
when bumper_front_bottom.level == 1 then stop(); end
when bumper_back.level == 1 then stop(); end
when core.last_message_age > 1000 then wheels.speed(0, 0); end
when core.last_message_age > 20000 then stop(); end

When done like this, the modules can still send commands to the fieldfriend. This can leed to unsafe behavior. To combat this issue we introduced zauberzeug/lizard#139 . This will be a implementation of this new bahviour.

Implementation
The new generated lizard code will look like this:

bool disabled = false
let disable do disabled=true;wheels.disable(); yaxis.disable(); zaxis.disable();end
let enable do disabled=false;wheels.enable(); yaxis.enable(); zaxis.enable();end
bool estop_active = false
when estop_1.active == false and estop_2.active == false then estop_active = false; end
when estop_1.active == true or estop_2.active == true then estop_active = true; end
bool bumper_active = false
when bumper_front_top.active == false and bumper_front_bottom.active == false and bumper_back.active == false then bumper_active = false; end
when bumper_front_top.active == true or bumper_front_bottom.active == true or bumper_back.active == true then bumper_active = true; end
when estop_active == false and bumper_active == false and disabled == true then enable(); end
when estop_active or bumper_active then disable(); end
when core.last_message_age > 1000 then wheels.speed(0, 0); end
when core.last_message_age > 20000 then disable(); end

Progress

• U6
• F20

[Johannes-Thiel]

This is blocked until

• Allow inverting e-stops and bumpers rosys#281
• add enable and disable to actuators lizard#139
  are merged.

[pascalzauberzeug]

We have to keep in mind that this will break robots running on older lizard versions

[pascalzauberzeug]

I think this PR is complex enough that you should use the new RoSys PR template and rename the title

[Johannes-Thiel]

I did some testing on u6. The rosys code works as expecetd and the enable and disable are also working for the axis. When monitoring the lizard output i noticed, that the CanOpenMotor will still send can messages when disbaled. Since the CanOpenMotor is wired to be de-energized when the estop is pressed it cant respond to the can messages and we get following error:

CAN bus reset successful, state: RUNNING
CAN send failed, attempting bus reset...
CAN bus state before reset: RUNNING
Starting TWAI driver...
CAN bus reset successful, state: RUNNING
CAN send failed, attempting bus reset...
CAN bus state before reset: RUNNING
Starting TWAI driver...
CAN bus reset successful, state: RUNNING

[Johannes-Thiel]

I did some testing on u6. The rosys code works as expecetd and the enable and disable are also working for the axis. When monitoring the lizard output i noticed, that the CanOpenMotor will still send can messages when disbaled. Since the CanOpenMotor is wired to be de-energized when the estop is pressed it cant respond to the can messages and we get following error:

CAN bus reset successful, state: RUNNING
CAN send failed, attempting bus reset...
CAN bus state before reset: RUNNING
Starting TWAI driver...
CAN bus reset successful, state: RUNNING
CAN send failed, attempting bus reset...
CAN bus state before reset: RUNNING
Starting TWAI driver...
CAN bus reset successful, state: RUNNING

The module, that spams can messages is the CanOpenMaster. We should not disable this function, due to it taking care of the timing of the CanOpen Network. So we will have to live with this message.

[pascalzauberzeug]

Looks good, but we have to be careful with other hardware.