Describe the bug
If you launch the AWS small house and the environment variable GAZEBO_MODEL_PATH is not defined you will not be able to open the AWS Small House environment.

To Reproduce
Steps to reproduce the behavior:

1. Go to the terminal and run: unset GAZEBO_MODEL_PATH
2. launch the AWS small house: ros2 launch irobot_create_gazebo aws_small.launch.py

Expected behavior

Task exception was never retrieved
future: <Task finished name='Task-2' coro=<LaunchService._process_one_event() done, defined at /opt/ros/foxy/lib/python3.8/site-packages/launch/launch_service.py:226> exception=SubstitutionFailure("environment variable 'GAZEBO_MODEL_PATH' does not exist")>

Currently there is no plugin to report robot docking status. Docking status information is obtained listening to /ir_opcodes.

• Report whether robot is visible or not using simple distance calculation
• Report whether robot is docked or not by checking facing angle and distance range

this plugin should publish the docking status to /dock

the topic /ir_opcodes should publish some predetermined codes to describe what the robot's forward facing IR receiver and Omni receiver see from the dock's IR emitters.

The table below describe what these codes should be according to the robot's pose relative to the dock

:

My non-Create robot worries a lot about his battery voltage and charging state both on and off his ancient iRobot dock.

The Create3 sim /battery_state topic is reporting 0v, 0 current, and 0 capacity.

header:
  stamp:
    sec: 5
    nanosec: 514000000
  frame_id: base_link
voltage: 0.0
temperature: 0.0
current: 0.0
charge: 0.0
capacity: 0.0
design_capacity: 0.0
percentage: 1.0
power_supply_status: 0
power_supply_health: 0
power_supply_technology: 0
present: false
cell_voltage: []
cell_temperature: []
location: ''
serial_number: ''
---

Any chance the sim could start with a full battery and run it down at the Create3 moving load draw?

Carl's life stats at the moment:

Total Life:  22154.2 hrs since Aug 22,2018
Life this year:  1570.2 hrs (BOY Aug 22)
Days Booted This Year:  4
Average Time Between Reboot:  392 hrs
Total Dockings:  2480
Dockings this year:  137
New Batteries At Cycle: 2160
Battery Set At Cycle:  320
Docking Failures this year:  3  or  2.1 % of Dockings
Safety Shutdowns this year:  1  or  .7 % of Dockings
Ave Cycle this year (w/o failures):  11.7 hours
Ave Cycle this year:  11.5 hours
Ave Playtime this year:  7.6
Ave of Last 10 Playtimes 7.5
Last Docking:  2021-10-26 14:34|[juicer.py.dock]---- Docking 2480 completed at 8.1 v after 7.4 h playtime
Last Recharge:  2021-10-26 18:35|[juicer.py.undock]---- Dismount 2480 at 10.9 v after 4.0 h recharge

Describe the bug
After building the repository I run colcon test.
I would expect the same linter that are applied in PRs to be run, but that does not happen.

This makes it hard to reproduce failures locally.

Is your feature request related to a problem? Please describe.
Create3 currently supports triggering reflexes when a hazard is detected. Enabling/disabling these reflexes are triggered through ROS 2 Parameters as follows:

  reflexes.REFLEX_BUMP
  reflexes.REFLEX_CLIFF
  reflexes.REFLEX_DOCK_AVOID
  reflexes.REFLEX_GYRO_CAL
  reflexes.REFLEX_PANIC
  reflexes.REFLEX_PROXIMITY_SLOWDOWN
  reflexes.REFLEX_STUCK
  reflexes.REFLEX_VIRTUAL_WALL
  reflexes.REFLEX_WHEEL_DROP
  reflexes_enabled

If reflexes_enabled is false, the robot won't react when a hazard is triggered. The robot defaults to reflexes_enabled true with all individual reflexes true except dock_avoid which defaults to false. The simulator should support these parameters and trigger simple actions to alleviate the hazard when the reflex is enabled. For example, if reflexes.REFLEX_BUMP is enabled and the hazard detects a bump hit, the robot should drive away from the bump hit until the hazard no longer detects bump.

Describe the solution you'd like
We won't implement the full complexity of the robot state machine, we will just keep it simple, mostly trying to back away from the hazard till it clears

  reflexes.REFLEX_BUMP - back away from bump till clear
  reflexes.REFLEX_CLIFF - back away from cliff till clear
  reflexes.REFLEX_DOCK_AVOID - back away from dock till clear
  reflexes.REFLEX_GYRO_CAL - ignore
  reflexes.REFLEX_PANIC - back away till clear
  reflexes.REFLEX_PROXIMITY_SLOWDOWN - slow down robot velocity till clear
  reflexes.REFLEX_STUCK - back away till clear
  reflexes.REFLEX_VIRTUAL_WALL - back away till clear
  reflexes.REFLEX_WHEEL_DROP - back away till clear
  reflexes_enabled

All reflexes should have a timeout, where if you have been driving for lets say 6 seconds and it hasn't cleared, then stop driving.

In a recent PR a breaking change was introduced that caused the bumper and cliff events to not be published anymore

In the create3 robot, a node currently exposes the following ROS 2 parameters:

• wheels_radius
• wheel_base
• wheels_encoder_resolution

Is there a way to access them from the simulated model? Or do we have to hard-code them in the node?
Note that the node name must match the one used in the create3 robot (currently it's static_transform but I think it should be changed).

The mock publishers PR needs a few suggestions to be addressed. Please revisit #96 and apply unresolved comments.

1. mock params yaml update
2. compostable nodes
3. cliffs for kidnap, move to their own files
4. lambda

/battery_state - on change (< 1 Hz)
/cmd_lightring - (control pub)
/cmd_vel - (control pub)
/dock - (1 Hz or on change)
/hazard_detection - (62 Hz)
/imu - (62 Hz)
/interface_buttons - (1 Hz or on change)
/ir_intensity - (62 Hz)
/ir_opcode - (62 Hz)
/kidnap_status - (1 Hz or on change)
/mouse - (62 Hz)
/odom - (20 Hz)
/parameter_events
/rosout
/slip_status - (62 Hz)
/stop_status - (62 Hz)
/tf - (20 Hz)
/tf_static
/wheel_ticks - (62 Hz)
/wheel_vels - (62 Hz)

Describe the bug
After base_footprint was removed, base_link was moved to compensate.

All links that have base_link as a parent need to be readjusted

I have seen suggestions the ROS2 community is moving away from Gazebo to using Ignition for ROS2 Galactic.

Is Ignition support in the plan for create3sim?

Describe the bug
When running the AWS house the dock does not appear in RVIz, although it's in the simulated environment.
On the other hand, when running empty world, we do see the dock in RViz (even if bugged, see #75)

To Reproduce
Steps to reproduce the behavior:
Run ros2 launch irobot_create_gazebo aws_small.launch.py

The Create 3 dock does not produce op code 173 when the robot is within all three zones (2 buoys + forcefield) as older docks used to do. Instead, it cycles between buoy and forcefield codes. A code should be generated every ~80 ms or so. (This means that if the robot is in only a buoy zone or only a forcefield zone, the code will update only once every ~160 ms.)

See discussion in #66

CPP code in the irobot_create_toolbox does not use namespaces. For good practice and for consistency all code should go inside the irobot_create_toolbox namespace.

The irobot_create_gazebo_plugins package can be used as an example.

Describe the bug
Apparantly when a minimal ros2 is installed, Rviz2 is not included and thus launching fails.

Let's approach fixing this by including Rviz2 as a dependency and also updating our documentations explaining that the optimal ros2 installation is the ros2-desktop version that includes Rviz2

Create3 Sim reports invalid frame ids, gzserver died:
FirstSimLaunch.pdf

and undock action does not complete:

$ ros2 action send_goal /undock irobot_create_msgs/action/Undock "{}"
1635181726.064372 [0]       ros2: using network interface wlan0 (udp/10.0.0.29) selected arbitrarily from: wlan0, wlan1
Waiting for an action server to become available...
Sending goal:
     {}

Goal accepted with ID: 9962c0cc712f461996ac0fdf4c428b5d

sim reports:
[motion_control-13] [INFO] [1635181726.560048052] [motion_control]: Received new undock goal

but does not undock and does not return failure status.

Is your feature request related to a problem? Please describe.
Currently "ros2 topic list" is showing a number of topics not shown by the real robot, such as:

/ir_intensity_front_center_left [irobot_create_msgs/msg/IrIntensity]
/ir_intensity_front_center_right [irobot_create_msgs/msg/IrIntensity]
/ir_intensity_front_left [irobot_create_msgs/msg/IrIntensity]
/ir_intensity_front_right [irobot_create_msgs/msg/IrIntensity]
/ir_intensity_left [irobot_create_msgs/msg/IrIntensity]
/ir_intensity_right [irobot_create_msgs/msg/IrIntensity]
/ir_intensity_side_left [irobot_create_msgs/msg/IrIntensity]

We would like to hide those topics from the user so that "ros2 topic list" will match what the user would see when working with the robot

Describe the solution you'd like
If you prepend "_" in front of a topic string, it won't show up with "ros2 topic list" unless you include hidden, so for example, for all our internal topics on the robot we prepend "_internal/", so you could for example have
_internal/ir_intensity_front_center_left

Is your feature request related to a problem? Please describe.
The behavior of the ir opcodes is more of the robot's beacon being a receiver of the dock emissions as opposed to the intersection of 2 projections.

Describe the solution you'd like
We think this can be accomplished by making the robot's omni circle be very small, then when it intersects the dock's projection, we can look at the angle between where the dock is facing and the receiver is facing to see if its a valid observation.

Normally the omni sensor would see 360, but because of the create faceplate, we could want to cap the angle to +/- 110. For the directional sensor, it would be +/- 45. So in summary, if you make the circle off the robot's beacon much smaller (like 1cm), then if it intersects with the dock forcefield, check the angle between the two lines (line projected in direction robot is facing and the line from robot receiver to dock emitter) and see if its absolute value < 110. Similarly, if the smaller robot circle intersects with the dock directional emitter, check the angle between the same 2 lines and see if its absolute value < 45. Hopefully its a small change from the code you have, reusing the circle intersection logic, just with a smaller robot circle. Sorry we didn't catch this during the review before testing.

Also can we use 0.61 m for halo radius and 1.22 m for buoys max range

Make the first release 0.0.1

Currently the integrated displacement is published from the mouse sensor. If the end user needs an increment they would have to calculate the difference between two integrated mouse displacement messages.

With a new MouseTicks.msg a new publisher node can be implemented to get the mouse increments

When trying the sim the first time, I used the empty world with the create3_dance nicely.
Next I tried the coverage server explore example with the empty world and wished for a basic room with the dock near a wall and a basic obstacle.

The AWS house is way overkill for me.

Any chance of a very basic one room create3 playground?

Problem
When I tried to run a dance script on the robot vs. the sim the robot ends up at noticeably different angles with the same motion for the same time. This is likely because the command transitions are happening with a different ramp profile on robot vs. sim

Describe the solution you'd like
Sim should use ramp limits as robot and command transitions should obey that ramp profile. This needs to factor in both axis (x/theta) and wheel (left/right) limits

Describe the bug
Commanding the robot to move against the dock shows the robot correctly blocked in gazebo, but in rviz the robot moves through the dock.

To Reproduce
Start empty world (robot will start on the dock)

ros2 launch irobot_create_gazebo create3.launch.py

Command forward velocity

ros2 topic pub -r 20 /cmd_vel geometry_msgs/msg/Twist "{linear: {x: 0.2, y: 0.0, z: 0.0}, angular: {x: 0.0, y: 0.0, z: 0.0}}"

Expected behavior
The robot should "push" against the dock, without making progress forward.

Actual behavior
The expected behavior happens in gazebo, but on the other hand, in rviz, the robot moves through the dock as if it was immaterial.

Describe the bug
Running the app in a ROS 2 Foxy docker container.
The robot model flickers a lot, it looks like there's a problem in the wheels TF publisher

To Reproduce
I'm using branch master

ros2 launch irobot_create_gazebo create3.launch.py

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots

Make a demo video of the robot teleoperating inside the AWS house.

Try to trigger and show all sensors.

Describe the bug
After starting a simulation, the wheel_ticks topic shows non-zero encoder ticks values

To Reproduce

ros2 launch irobot_create_gazebo create3.launch.py
ros2 topic echo wheel_ticks

Following the steps in the README allows successful creation of a Create3 Gazebo simulation with RViz monitoring.

Suggest two additional items for README:

1. In order to try either of the documented create3_examples, it seems the bot needs to be undocked (and perhaps moved away some distance from the doc) - dance does nothing and create server reports:

[INFO] [1635180515.540014049] [create3_coverage]: Accepting goal request
[INFO] [1635180515.542679168] [create3_coverage]: Executing goal
[INFO] [1635180515.596585652] [create3_coverage]: Reflexes are disabled on the robot!

Please add a working example test beyond launching in an empty world such as sending an action goal to undock.
This seems like it was accepted by the create3 sim but did not move the bot off the dock:

$ ros2 action send_goal /undock irobot_create_msgs/action/Undock "{}"
1635181726.064372 [0]       ros2: using network interface wlan0 (udp/10.0.0.29) selected arbitrarily from: wlan0, wlan1
Waiting for an action server to become available...
Sending goal:
     {}

Goal accepted with ID: 9962c0cc712f461996ac0fdf4c428b5d

2. The README guides the user to create a workspace and clone the create3_sim repo into the workspace, but the next moment I see the create3_sim getting commits. Please include a section in the README:

• Updating create3_sim to your workspace

Right now docking rays are not visualized by default. All other rays are also hidden.

Add launch arguments to enable/disable visualization of these rays.

By default all rays should be hidden.

Is your feature request related to a problem? Please describe.
There are some topics that the simulator will not fully implement. These topics are:

1. /stop_status
2. /battery_state
3. /interface_buttons
4. /cmd_lightring
5. /kidnap_status
6. /slip_status

Describe the solution you'd like
I think a new ros node can be created and all these topics can be published at their correct rate with a default message value

The docking/undocking algorithm requires a go-to-goal controller in order to work.
The controller should Ideally be a ros action that receives a coordinate in space and from that input calculates and sends velocity commands to move the robot to the desired Pose.

Take a look at: https://github.com/clebercoutof/turtlesim_cleaner/blob/master/src/gotogoal.py for an example of how to write this code.

Is your feature request related to a problem? Please describe.
The robot supports the following actions:
ros2 action list -t
/dock [irobot_create_msgs/action/DockServo]
/undock [irobot_create_msgs/action/Undock]
/wall_follow [irobot_create_msgs/action/WallFollow]

The simulator should offer the same actions. At a minimum, /dock can just put the robot on the dock and /undock can remove it from the dock and face it 180 away from the dock (if simulating the servo'ing underneath is hard).

Implement dock and undock actions.

dock:

• use "go to goal" controller to navigate to a point in front of dock
• align with dock and go forward until docked

undock:

• check docking status. If undocked, fail. If docked, proceed
• go backwards a fixed distance
• turn 180 degrees

Blocked by issue #36 and by issue #62

The package irobot_create_msgs will be moved to another repo. It needs to be removed from this repo and instead imported via VCS just like the AWS small house repo is imported.

There is currently no documentation in the README on how to use the aws small house

Is your feature request related to a problem? Please describe.
The robot seems to rock more in the simulator than in real life when accelerating with the acceleration limits enabled in galactic

Describe the solution you'd like
Perhaps adjusting the center of mass of the robot will help. The center of mass of the actual robot is 22.8mm in front of center on the X axis and 0.8mm left of center on the Y axis (its probably fine to ignore that offset).

Right now these messages are being published with an empty string assigned to frame_id.

In the header of the messages there is a frame_id variable that should be filled in with the robot's root frame name.

The robot currently has a fixed speed limit.

The robot should be able to dynamically change speed limit profiles:
"none" - standard safety profile, robot cannot backup more than an inch because of lack of cliff protection in
"backup_only" - allow backup without cliff safety, but keep cliff safety forward and max speed at 0.306m/s
"full" - no cliff safety, robot will ignore cliffs and set max speed to 0.46m/s
safety_override: "backup_only"

These messages are being published without filling the header parameters frame_id and stamp.

After correcting issues with the robot's frames being wrong after the removal of base_footprint. The result is that the robot shows below the ground in Rviz.

irobot_create_toolbox not installing /launch directory in CMakeLists.txt

Prerelease testing on ROS2

The robot currently offers the following parameters:

$ ros2 param list
/motion_control:
max_speed (read only, set when saftey_override is set)
reflexes.REFLEX_BUMP
reflexes.REFLEX_CLIFF
reflexes.REFLEX_DOCK_AVOID
reflexes.REFLEX_GYRO_CAL
reflexes.REFLEX_PANIC
reflexes.REFLEX_PROXIMITY_SLOWDOWN
reflexes.REFLEX_STUCK
reflexes.REFLEX_VIRTUAL_WALL
reflexes.REFLEX_WHEEL_DROP
reflexes_enabled
safety_override
/static_transform:
wheel_base
wheels_encoder_resolution
wheels_radius

For example:

wheel_base

$ ros2 param get /static_transform wheel_base
Double value is: 0.2329999953508377

safety_override

$ ros2 param get /motion_control safety_override
String value is: none

Describe the bug
The simulated robot should report the same tf frames as the real robot (pasted from rviz screenshots below)
Rviz TF should look the same when talking to the simulated robot. If there are frames needed by sim not on the robot, we should potentially add them to the robot for parity. For the example of the bumper, where there is a bumper_link in sim right now, we should try to use the existing bump_front_center frame instead (additionally adding the rest of the bumper frames)

To Reproduce
Go to the TF panel on rviz and expand

Expected behavior
TF display from simulated robot matches real robot screenshots attached

Screenshots

EmitterCartesianPointToReceiverPolarPoint() and ReceiverCartesianPointToEmitterPolarPoint() can be moved to helpers class.

This was proposed in PR#66 but was postponed for a future PR

Retrieve docks with:

const std::string robot_name = model->GetName();
const std::vector<std::string> docks_names = RetrieveDocksNames(world_);

Where RetrieveDocksNames should be hosted in gazebo_ros_helpers:

std::vector<std::string> RetrieveDocksNames(const gazebo::WorldPtr & world) { std::vector<std::string> docks_names; for(const gazebo::ModelPtr& model : world->Models()) { const std::string model_name = model->GetName(); // If model_name ends with "_dock" docks_names.push_back(model_name); } return docks_names; }

Describe the bug
Even while the plugin seem to be running, as it reports a roslog-info in stdout everytime a wheeldrop gets triggered

[gzserver-6] [INFO] [1633698241.319102859] [wheel_drop.wheel_drop_left_plugin]: Wheel drop wheel_drop_left_joint ON: 0.029
[gzserver-6] [INFO] [1633698241.384054627] [wheel_drop.wheel_drop_right_plugin]: Wheel drop wheel_drop_right_joint ON: 0.029
[gzserver-6] [INFO] [1633698241.593676790] [wheel_drop.wheel_drop_left_plugin]: Wheel drop wheel_drop_left_joint OFF: 0.022
[gzserver-6] [INFO] [1633698241.868891002] [wheel_drop.wheel_drop_left_plugin]: Wheel drop wheel_drop_left_joint ON: 0.029

the wheeldrop topics and hence, the hazard detection topic, are not reflecting any of these events.

To Reproduce
Lift the robot in the air and throw it to the floor from there, no messages will be registered in /_internal/wheel_drop/<left/right>_wheel/event and no wheeldrop component will show in the hazard detection topic.

Expected behavior
Wheeldrops should generate publication in these topics

Screenshots
N/A

Additional context
Add any other context about the problem here.

Currently only one bumper contact sensor is triggered at a time.

When the midpoint of two contact sensors are pushed both sensors should trigger.