Notify metacontroller about the Laser error

[chcorbato]

The 'rosgraph_monitor' needs to send a diagnostics message to the metacontrol reasoner to notify the laser failure.

Currently, the metacontroller does not accept messages related to single nodes, but to configurations, as we decided that the metacontrol would operate at that level of granularity. See:
https://github.com/tud-cor/mc_mros_reasoner/blob/67d4af8a6b064c2b29bab5c80956481c826ad6c0/mros1_reasoner/src/mros1_reasoner/ros_reasoner.py#L141-L147
(binding refers to a configuration that is currently deployed)

We can discuss this interface @ipa-hsd

[chcorbato]

@ipa-hsd can you send me the information that is published by the ros_graph monitor about the laser node that is missing?

@ipa-nhg can you send the information about components that is in the .rossystem file?

[hsd-dev]

can you send me the information that is published by the ros_graph monitor about the laser node that is missing?

Output would look something like this:

header: 
  seq: 21
  stamp: 
    secs: 1582702157
    nsecs: 918167114
  frame_id: ''
status: 
  - 
    level: 2
    name: "laserscanner_node"
    message: "Missing node"
    hardware_id: ''
    values: []

[ipa-nhg]

Ros system model example for a component:

	ComponentInterface { name battery_load_control 
		RosPublishers { 
		RosPublisher "/power_load" { RefPublisher "metacontrol_sim.battery_load_control_node.battery_load_control_node./power_load" } }
	RosSubscribers { 
		RosSubscriber "/odom" { RefSubscriber "metacontrol_sim.battery_load_control_node.battery_load_control_node./odom"} , 
		RosSubscriber"/cmd_vel" { RefSubscriber "metacontrol_sim.battery_load_control_node.battery_load_control_node./cmd_vel"} , 
		RosSubscriber"/imu/data" { RefSubscriber "metacontrol_sim.battery_load_control_node.battery_load_control_node./imu/data" } } 
	RosParameters {
		RosParameter min_power_load { RefParameter "metacontrol_sim.battery_load_control_node.battery_load_control_node.min_power_load"} , 
		RosParameter max_power_load { RefParameter "metacontrol_sim.battery_load_control_node.battery_load_control_node.max_power_load"} , 
		RosParameter odom_topic { RefParameter "metacontrol_sim.battery_load_control_node.battery_load_control_node.odom_topic"} , 
		RosParameter imu_topic { RefParameter "metacontrol_sim.battery_load_control_node.battery_load_control_node.imu_topic"} , 
		RosParameter power_load_topic { RefParameter "metacontrol_sim.battery_load_control_node.battery_load_control_node.power_load_topic"} , 
		RosParameter additional_consumption { RefParameter "metacontrol_sim.battery_load_control_node.battery_load_control_node.additional_consumption"} , 
		RosParameter cmd_vel_topic { RefParameter "metacontrol_sim.battery_load_control_node.battery_load_control_node.cmd_vel_topic"} , 
		RosParameter controller_frequency { RefParameter "metacontrol_sim.battery_load_control_node.battery_load_control_node.controller_frequency"} , 
		RosParameter const_acceleration { RefParameter "metacontrol_sim.battery_load_control_node.battery_load_control_node.const_acceleration"} , 
		RosParameter const_frequency { RefParameter "metacontrol_sim.battery_load_control_node.battery_load_control_node.const_frequency" } } }

Full file: https://github.com/rosin-project/rosin-experiments/blob/master/metacontrol_models_experiment/system.rossystem#L221-L238

[chcorbato]

@marioney which version of mros_reasoner shall we use for the ROSIN paper? Do you think we shouldn't first incorporate some changes from the MROS project?

[marioney]

@marioney which version of mros_reasoner shall we use for the ROSIN paper? Do you think we shouldn't first incorporate some changes from the MROS project?

I think we need to add some changes from the MROS project, specially if we plan to use the same ontology.

[chcorbato]

I see two options:

• A. We update to use the new mc_reasoner and fix all issues.
• B. we analyze what functionality we need for any additional experiments in the new submission and we only merge those changes.

I suspect B will actually be more complex, but I think you know better @marioney

[marioney]

The diagnostics msg for a missing component should be something like this.

header: 
  seq: 21
  stamp: 
    secs: 1582702157
    nsecs: 918167114
  frame_id: ''
status: 
  - 
    level: 2
    name: ""
    message: "Component status"
    hardware_id: ''
    values: ["laserscanner_node", "FALSE"]

We have to define correctly the name of the component, (i.e. laserscanner_node as it needs to be the same on the ontology file)
In the current version of the ontology we have laser_resender, but I we can change it.

@ipa-hsd can you let me know when you update the observer to get this message

[hsd-dev]

@marioney #10

[marioney]

Great I've merged the changes!!

@ipa-hsd which nodes do we need to add to test it, and or how can we trigger this failure?