Update README.md

Author: haider8645

README.md

@@ -366,28 +366,11 @@ The `searchGrid` is a `TraversabilityMap` but the traversability information is
 The `TraversabilityMap` was chosen because it enables O(n) (n <= maximum number of layers in the map) lookup of nodes based on their xyz position. The choice was made due to time constraints (the map was there and it worked and there was no time). Semantically the usage of a `TraversabilityMap` to store the `XYZNodes`is wrong and it should be changed (e.g. to a hashmap), but it works and thus was never changed.
 
 #### The `TraversabilityMap`
-In addion to the `searchGrid` the environment has access to a `TraversabilityMap3D` (accessed through the `travGen` attribute).
-
-A `TraversabilityMap3D` is generated from an MLS and separates the MLS into traversable, non-traversabel and unknown terrain. Addtionally it contains some meta data (e.g. slope of the patch, supporting plane, etc.).
-The map is generated by the `TraversabilityMapGenerator` based on a set of rules.
+In addion to the `searchGrid` the environment has access to a `TraversabilityMap3D` (accessed through the `travGen` attribute). A `TraversabilityMap3D` is generated from a MLS using [traversability_generator3d](https://github.com/dfki-ric/traversability_generator3d) library and it separates the MLS into traversable, non-traversabel and unknown terrain. Addtionally it contains meta data (e.g. slope of the patch, supporting plane, etc.).
 
 The `TraversabilityMap3D` has to be fully expanded (i.e. generated from the MLS) before planning. In theory it could be expanded on the fly during planning and the code is prepared to do that, however this was never tested and there is a good chance that on-the-fly expansion will trigger bugs (especially if parallelism is enabled).
 
-The planner uses the `TraversabilityMap3D` to find valid successor states during planning. I.e. states that the robot can traverse to from a given state using the given motion primitives. Metadata stored in the map (e.g. slope) is also used during planning to calculate costs.
-
-#### Color Codes
-
-The visualizer of the `TraversabilityMap3D` uses color coding to indicate the different patch types:
-- 🟩 **Traversable**: The robot can stand (with its center) on this patch in at least one orientation without hitting an obstacle.
-- 🟥 **Obstacle**: There is no way that the robot can stand (with its center) on this patch.
-- 🟦 **Frontier**: Borders to the end of the map. Should be traversable (I am not 100% sure about this. check the code!)
-- 🟪 **Unknown**: This is a virtual patch that serves as boundary for algorithms. This patch does not exist in reality. Patches also become unknown if there is not enough support in the MLS to be sure that a patch exists in this location.
-- ⬛ **Hole**: This is part of the map specification but is not used by ugv_nav4d. It might be used elsewhere but the planner cannot handle it.
-- 🟨 **Unset**: This is the starting state of a new patch. It should not be visible in a fully explored map. If you see a yellow patch after map expansion is done, you have found a bug in the `TraversabilityMapGenerator` and should investigate.
-- 🟧 **Inflated Obstacle**: An obstacle patch expanded to include a safety buffer around the actual obstacle. These are not traversable.
-- <img width="28" height="28" alt="image" src="https://github.com/user-attachments/assets/775162ac-be4c-4a32-a24b-8ab41f5cea99" style="border: none;" />**Inflated Frontier**: A frontier patch that has been inflated for planning safety margins. Indicates proximity to exploration boundaries.
-
-<img width="1028" height="763" alt="image" src="https://github.com/user-attachments/assets/82e77547-74d2-40ff-9c15-a0d37f7187a1" />
+The planner uses the `TraversabilityMap3D` to find valid successor states during planning which are tates that the robot can traverse to from a given start state using the motion primitives. Metadata stored in the map is used during planning to calculate costs.
 
 #### Obstacle Checking
 To ensure that the robot can traverse a certain area, obstacle checks have to be done.