No Ground Truth data from Gazebo Fortress

Description

The odometry source in gazebo classic can be switched between world (ground truth) and encoders. Such feature is not available in the diff drive plugin in gazebo fortress. The odometry (including the odom -> base_link transform) is dependent on encoders

Desired outcome

There must be a launch argument for gz.launch.py to switch between ground truth and encoder odometry (both odom->base_link transform and /odom topic)

We have used simplified collisions but they extend beyond robot body. They should align with the visual mesh, I think disabling self collision should do alongside updated wheel link positions

It's good for me to debug my project.

This should be fixed by changing the Line 25 parameter name to "traction_track _width" as this number represents the track width or the wheel separation but not wheel base. A diagram for reference:

Similarly, the parameter

Description

The root frame of the current tf tree for the bot is base_link.

The following guideline is provided on the nav2 documentation on Setting Up The URDF

The base_footprint link is a virtual (non-physical) link which has no dimensions or collision areas. Its primary purpose is to 
enable various packages determine the center of a robot projected to the ground. For example, Navigation2 uses this link to 
determine the center of a circular footprint used in its obstacle avoidance algorithms. Again, we set this link with no 
dimensions and to which position the robot’s center is in when it is projected to the ground plane.

Maps pass through the bot with nav2 stack

Benifits

Although not a neccesecity, the addition of base_footprint enables the bot to work with nav2 stack out of the box as base_footprint is a default parameter in most cases.

A good example of this would be turtlebot3

https://github.com/ncnynl/commands/blob/master/commands_extra/ros2_gazebo/shell/install_bcr_bot.sh

add a rapid script to install bcr bot for ros2

curl -k https://www.ncnynl.com/rcm.sh | bash -
rcm -s install_bcr_bot

run:

1. ros2 launch bcr_bot ign.launch.py
2. ros2 launch bcr_bot rviz.launch.py

Issue with Namespace Argument in ROS2 + Ignition

Description

Currently, the launch file in gz.launch.py does not include a namespace argument. Additionally, in the model spawn, the namespace is not utilized as part of the naming convention for the spawned robot, unlike the ros2 classic and ros1 . Furthermore, the joint states and other topics are hardcoded to "bcr_bot,"

Steps to Reproduce

1. Execute the current version of gz.launch.py without the namespace argument.
2. Observe the robot spawn behavior and the naming convention used.
3. Monitor the topics and verify that they are hardcoded to "bcr_bot".

Expected Behavior

After implementing the proposed changes:

1. The gz.launch.py launch file should include a namespace argument.
2. The robot spawned using the model spawn should incorporate the namespace argument in its name.
3. Joint states and other topics should be properly mapped to the provided namespace.