raw3-1 emergency state topic in wrong ns about cob_robots HOT 26 CLOSED

This PR #395 solves the problem

from cob_robots.

Even if #395 solves the namespace problem in simulation....why is this node run in simulation mode on real hardware anyways? There seems to be something wrong about this...

from cob_robots.

I guess because the r@w does not have a relayboard. How is it handled on cob4?

from cob_robots.

If raw3-1 does not have a relayboard, we should not have the robot to require a topic coming from this node in order to be able to operate it...
Which node requires a message on /emergency_stop_state on the raw3-1? @ipa-srd @ipa-nhg could you check this with rostopic info?

from cob_robots.

Even if #395 solves the namespace problem in simulation....why is this node run in simulation mode on real hardware anyways? There seems to be something wrong about this...

This is something I found out a year a go or so, but I was never really sure and had time to change it for all robots. For raw3-5 should be changed in #400

I guess because the r@w does not have a relayboard.

raw3-5 has? Or at least can publish this topics through phidgetboard. Probably I have to look at it again more closely.... Anyway I solved it for raw3-5...

from cob_robots.

Yes, the emergency_stop_state topic can be published from a phidget board.

from cob_robots.

But than on all r@ws (if all have phidged board) this:

<include file="$(find cob_bringup)/drivers/relayboard.launch" >
        <arg name="sim" value="true" />
</include>

should be changed for this:

<include file="$(find cob_bringup)/drivers/phidgets.launch" >
        <arg name="robot" value="$(arg robot)" />
</include>

as I did in #400

And of course we should take care that phidget board configuration is correct.

from cob_robots.

True, but not all have a phidget board (actually, I'm not sure if there not only two that actually have one). And there are different versions. We have to check with our r@w's, at least the two that are still at IPA. For the rest, we need to keep it as is.

from cob_robots.

Ok check it, at KIT we have phidgetboard, so for raw3-5 it can be also changed.

from cob_robots.

from my point of view just two things need to be done.

1. merge PR #395 because we still need the simulated relayboard for robots without relayboard and phidgetboard.
2. replace relayboard launch with phidgetboard launch for raw3-1 and raw3-5. raw3-3 was already changed and the other raw's do not have a phidget board.

from cob_robots.

because we still need the simulated relayboard for robots without relayboard and phidgetboard.

Why? Which node requires the topic to be available?
Is it only me who thinks it is strange that a (software) node (I don't know which one it is) requires a hardware to be present (i.e. the relayboard with its driver to publish a topic) in order to work...?
I thought we use "simulated" nodes in order to have the same set of topics and messages in Gazebo simulation than we do on the respective hardware setup. NOT for making all hardware setups equal in case one does not have a particular hardware (e.g. the relayboard)...

from cob_robots.

Alright. The /emergency_stop_state topic is required by the cob_undercarriage_control node (subscriber callback / setter function in controller / block calculation of control step if in EM stop).

I guess this is a left over from the cob3-era, where all cob3's had a relayboard.
I'm not sure if this is used anywhere else (diagonstics? @ipa-fmw, cob_omni_drive_controller? @ipa-mdl) or how the controllers behave, if we where to remove this.

If the emergency_stop_state is set to true, the output commands will be 0.0 and some internal controller state variables will be reset. If this, however, is required, and how the control behaviour will change then, I cannot say. Maybe worth a test.

from cob_robots.

as @ipa-mig wrote, cob_undercarriage_control needs the emergency_stop_state topic to be published. If it's not published the base will not move. This behavior is implemented because of safety reasons. (No EM Stop State means that there is probably something wrong and we should not move the base).

from cob_robots.

Yes, the base should not be moved in case of EM-Stop, but this is enforced due to the EM-Stop cutting of the power from the drives - on the hardware-side!
It should not need to be handled by software...even more, the hardware will not start to move after the EM-Stop has been released again without recovering it anyways...

from cob_robots.

Yes to both. It would be nice to have this topic and handle the different controllers respectively.
Especially, as it allows for differntiating between button stop and scanner stop.

However, if the sim node is used, the emergency stop flags are always false, i.e. not in EM stop. Thus, I guess it could be removed.

from cob_robots.

IMHO:

1. use global namespace
2. use phidget board if available
3. remove all of it after the new base chain is available ;)

It should not need to be handled by software...even more, the hardware will not start to move after the EM-Stop has been released again without recovering it anyways...

The software controller should reset its internals in order to not jump after recover.
Within the migration of the platform controllers to ROS (for cob3) the emergency_stop_state was introduced and the EM stop was handled in (too) many places.

How is it handled on cob4?

The topic is published by cob_safety_controller, but it is used only on cob4-2 with the old drives.

cob_omni_drive_controller?

The new base chain does not need this topic anymore, since ros_canopen resets the controller internally.
I have tested the new chain with cob4-2 and https://github.com/ipa320/cob_driver/pull/258 successfully.

from cob_robots.

The new base chain does not need this topic anymore, since ros_canopen resets the controller internally.

and

The software controller should reset its internals in order to not jump after recover.

How is this handled therein, i.e. how does the controller know when to reset?

from cob_robots.

How is this handled therein, i.e. how does the controller know when to reset?

The controller does not know this, but ros_canopen/ros_control resets the controller.
Not only in case of EM stops, but as well for mode switches etc.

from cob_robots.

Yes, but what triggers the reset? The EM stop as well? Then, this needs to be known by ros_canopen/ros_control. How so?

Or am I being stupid and missing something? ;-)

from cob_robots.

Then, this needs to be known by ros_canopen/ros_control. How so?

This is a different question ;)
The Elmo controller reports the failure via a CANopen emergency message.
For old Elmos and Schunk you get a motor undervoltage error and for the new Elmos you get a Safety stop error :)
cob_canopen_motor disabled these error messages for some reason.

from cob_robots.

Alright, so the new modules don't rely on the emergency_stop_state topic anymore. Understood ;-)

from cob_robots.

Trying to catch up on this:
I guess the approach to follow is what @ipa-bnm wrote in #403 (comment):

• none of the raw's have real relayboard
• raw3-1 (started on branch #407 ), raw3-3 (already done) and raw3-5 (done in #400) have phidgetboard that is able to publish the required emergency_stop_state topic. thus, for them relayboard sim should be removed and phidgetboard added
• raw3-2, raw3-4 and raw3-6 will use relayboard sim (already done)
• #395 needs to be merged
• modification of cob_undercarriage_control is not worth the effort as it is going to be deprecated/removed soon anyway...

@ipa-mig, @ipa-bnm @destogl please confirm or correct me if I'm wrong.....

from cob_robots.

as far as I see, you are correct.

I'm unsure if the phidget boards are all the same, are wired correctly/the same or if there are any discrepancies between raw3-1, 3-3 and 3-5.

from cob_robots.

You are correct.

from cob_robots.

Seems legit.
I suggest to migrate just the robots that have their EM wiring confirmed.

from cob_robots.

configuration of phidget board in #400 is correct for raw3-5

from cob_robots.