Update Panther documentation (#274)

* Refactor Panther documentation: update section titles and remove outdated images

Signed-off-by: Max Waterhout <max.waterhout@hotmail.nl>

* typo

Signed-off-by: Max Waterhout <max.waterhout@hotmail.nl>

---------

Signed-off-by: Max Waterhout <max.waterhout@hotmail.nl>

Author: MaxWaterhout

docs/content/panther.md

@@ -154,25 +154,35 @@ A map should be visualized in Rviz and be updated when driving around.
 ros2 launch rcdt_panther panther.launch.py collision_monitor:=True
 ```
 
-Rviz should visualize "slow-down" regions around the Panther and the Panther should slow down when objects are in these regions.
+Rviz should visualize "slow-down" regions around the Panther.
 
 **Navigation:**
 
 ```bash
 ros2 launch rcdt_panther panther.launch.py nav2:=True
 ```
 
-Now you should be able to place a *2D Goal Pose* in Rviz, somewhere on the map. The robot should plan, visualize and drive a route to this goal pose.
+Now you should be able to place a *2D Goal Pose* in Rviz, somewhere on the map. The robot should plan, visualize and drive a route to this goal pose. If you have a prebuilt map and run without SLAM, **AMCL (Adaptive Monte Carlo Localization)** is used to localize the robot on the known map.
 
 :::{note}
 Don't forget to reset the E-STOP when the Panther should drive:
 
 ```bash
 ros2 service call /panther/hardware/e_stop_reset std_srvs/srv/Trigger {}
 ```
-
 :::
 
+## Nav2 Choices and Configuration
+
+The Panther uses the [Nav2](https://navigation.ros.org/) stack for navigation. Most parameters remain at their defaults, but a few key choices were made based on experiments with the real robot:
+
+* **Controller:** `vector_pursuit` – provided the most reliable path following in practice.
+* **Planner:** `SmacPlannerHybrid` – produced the most robust global plans during testing.
+* **Recovery:** uses Nav2’s default behaviors (*clear costmaps, spin, wait, backup*), with an extended **progress timeout of 40 s** so the robot won’t abort immediately when blocked by dynamic obstacles (e.g. vehicles).
+* **Costmaps:** both `publish_frequency` and `update_frequency` are set to **30 Hz** for smoother obstacle updates on the real robot in the global costmap.
+* **Waypoint follower:** a custom `waypoint_follower_controller` node was developed to follow waypoints provided by, for example, a UI.
+* **Collision Monitor:** filters velocity commands based on the robot’s current motion. It slows down when obstacles enter a rectangular slow-down zone and uses velocity-dependent stop polygons (forward, backward, rotation, idle) to enforce a full stop if an obstacle blocks its path.
+
 ## Using an User Interfaces
 
 ### Default Panther UI
@@ -211,25 +221,4 @@ ros2 launch rcdt_panther rcdt_panther.launch.py ui:=True
 
 The interface should look something like this:
 
-![ui](../img/panther/custom_ui.png)
-
-
-## Proposed changes to reduce network traffic
-
-During experimentation it became clear that at least ethernet-speed connections are required in order to deal with pointcloud data without dropping messages. The current high-level architecture when using a LiDAR is as follows:  
-
-![velodyne-settings](../img/panther/current.jpeg)
-
-A major advantage to this architecture is that it allows for fast and easy development, and straightforward inspection of any ROS topics using Rviz and/or ROSBoard. However, this makes it impossible to use wifi to operate the robot, making a cable mandatory. This provides obvious limitations for use-cases where further autonomy is required.  
-
-One proposed alternate setup wold be to move the RCDT docker container to the onboard ThinkStation. This would eliminate the need to broadcast pointcloud data over the network, instead keeping it all within the robot itself.  
-
-![velodyne-settings](../img/panther/proposed.jpeg)
-
-A downside to this approach, however, would be that live inspection of data generated by the robot becomes more complex. Lower-bandwith data such as a generated map or camera data would be no problem to consume using a simpler "monitor" docker container that only needs to run Rviz and/or ROSBoard.  
-
-Additionally, the RCDT docker could be extended to run foxglove. One of the promising features of foxglove is that it supports 3D data visualizations in-browser, and [supports compression of topics](https://docs.foxglove.dev/docs/connecting-to-data/ros-foxglove-bridge). It appears this compression would be lossless, but this has not been explored in detail, yet. [A simple intro to foxglove with some basic examples is provided in this blogpost](https://foxglove.dev/blog/installing-ros2-on-macos-with-docker). It is also worth noting that foxglove requires certain ports to be exposed in the docker container, [similar to how is dicussed here](https://www.reddit.com/r/docker/comments/1aq8v9b/ports_in_docker_and_docker_compose/). Finally, foxglove also provides a level of [integration with ROSBoard](https://discourse.ros.org/t/introducing-foxglove-integration-with-rosboard-for-real-time-visualizations/38376) allowing for some reuse of the ROSBoard features we have already set up.  
-
-Another approach could be to [create a (lossy) compressed topic](https://discourse.ros.org/t/compressed-pointcloud2/10616) for pointcloud data that would only serve inspection purposes; not SLAM/nav2 purposes. This would require further investigation into the current state of availability of these kinds of topics, though, since the thread linked here is a few years old.  
-
-It also bears mentioning that [Husarion provides a web UI](https://husarion.com/manuals/panther/software/ros2/robot-management/#webui), but this appears to be poorly-maintained. Additionally, it requires snap packages, which are tricky to install in a dockerized environment.  
+![ui](../img/panther/custom_ui.png)