Publish mock messages for topics that won't be implemented in sim about create3_sim HOT 6 CLOSED

@LolaSegura Can you grab this one?

from create3_sim.

I'd split this task into several PRs. Here it is why:

1. /stop_status would require reading information from the robot pose. It's not a straightforward task.
2. /battery_state can be implemented with a Gazebo plugin. It's weird to me that it has to be published on change and not at 62 Hz.
3. /interface_buttons and /cmd_lightning: how are we going to expose this data?
4. /kidnap_status should be implemented reading the robot pose too and multiple sensors (wheel drops and cliffs).
5. /slip_status: we can consider that this never happens.

from create3_sim.

I'd split this task into several PRs. Here it is why:

1. /stop_status would require reading information from the robot pose. It's not a straightforward task.
2. /battery_state can be implemented with a Gazebo plugin. It's weird to me that it has to be published on change and not at 62 Hz.
3. /interface_buttons and /cmd_lightning: how are we going to expose this data?
4. /kidnap_status should be implemented reading the robot pose too and multiple sensors (wheel drops and cliffs).
5. /slip_status: we can consider that this never happens.

The intent is to NOT publish accurate data for these topics... The intent is to simply implement them publishing a default value.

from create3_sim.

@justinIRBT Do you agree with this list of topics?

from create3_sim.

The intent is to NOT publish accurate data for these topics... The intent is to simply implement them publishing a default value.

I wouldn't do that for stop_status and kidnap_status.

from create3_sim.

/cmd_lightring is a subscription. I would implement a subscription for it, but it doesn't have to do anything (it would be cool if you could draw color around the LED corresponding with the subscribed value, but very very low priority)

/interface_button a default value is fine, this is what the message looks like when no button has been pressed

$ ros2 topic echo /interface_buttons
header:
  stamp:
    sec: 1627706418
    nanosec: 919649659
  frame_id: base_link
dock_button:
  header:
    stamp:
      sec: 1627706418
      nanosec: 919649659
    frame_id: button_1
  is_pressed: false
  last_start_pressed_time:
    sec: 0
    nanosec: 0
  last_pressed_duration:
    sec: 0
    nanosec: 0
power_button:
  header:
    stamp:
      sec: 1627706418
      nanosec: 919649659
    frame_id: button_power
  is_pressed: false
  last_start_pressed_time:
    sec: 0
    nanosec: 0
  last_pressed_duration:
    sec: 0
    nanosec: 0
spot_button:
  header:
    stamp:
      sec: 1627706418
      nanosec: 919649659
    frame_id: button_2
  is_pressed: false
  last_start_pressed_time:
    sec: 0
    nanosec: 0
  last_pressed_duration:
    sec: 0
    nanosec: 0

/slip_status you can always report false

/kidnap_status, if possible to lift the robot in the simulator, would be nice to have it report a real value. You can make the detection simple like both wheel drops off the floor or all cliffs triggering

/stop_status would be nice to have a real value, again, you can keep it as simple as possible like odometry change over 0.1 seconds is close to 0

/battery_state, plugin would be nice, otherwise can always report 100%. It publishes at a background rate of 0.1 Hz (once every 10 seconds, or on change). If you have it always report 100, you can just publish every 10 seconds

from create3_sim.