docs: update link style and fix typos

common/autoware_auto_common/design/comparisons.md

@@ -1,4 +1,4 @@
-# Comparisons {#helper-comparisons}
+# Comparisons
 
 The `float_comparisons.hpp` library is a simple set of functions for performing approximate numerical comparisons.
 There are separate functions for performing comparisons using absolute bounds and relative bounds. Absolute comparison checks are prefixed with `abs_` and relative checks are prefixed with `rel_`.

common/autoware_auto_geometry/design/interval.md

@@ -1,4 +1,4 @@
-# Interval {#geometry-interval}
+# Interval
 
 The interval is a standard 1D real-valued interval.
 The class implements a representation and operations on the interval type and guarantees interval validity on construction.

common/autoware_auto_geometry/design/polygon_intersection_2d-design.md

@@ -1,4 +1,4 @@
-# 2D Convex Polygon Intersection {#convex-polygon-intersection-2d}
+# 2D Convex Polygon Intersection
 
 Two convex polygon's intersection can be visualized on the image below as the blue area:
 

common/autoware_auto_geometry/design/spatial-hash-design.md

@@ -1,4 +1,4 @@
-# Spatial Hash {#geometry-spatial-hash}
+# Spatial Hash
 
 The spatial hash is a data structure designed for efficient fixed-radius near-neighbor queries in
 low dimensions.
@@ -35,9 +35,11 @@ The spatial hash works as follows:
 Under the hood, an `std::unordered_multimap` is used, where the key is a bin/voxel index.
 The bin size was computed to be the same as the lookup distance.
 
+<!-- cspell:ignore CRTP -->
+
 In addition, this data structure can support 2D or 3D queries. This is determined during
 configuration, and baked into the data structure via the configuration class. The purpose of
-this was to avoid if statements in tight loops. The configuration class specializations themself
+this was to avoid if statements in tight loops. The configuration class specializations themselves
 use CRTP (Curiously Recurring Template Patterns) to do "static polymorphism", and avoid
 a dispatching call.
 

common/autoware_auto_tf2/design/autoware-auto-tf2-design.md

@@ -1,4 +1,4 @@
-# autoware_auto_tf2 {#autoware-auto-tf2-design}
+# autoware_auto_tf2
 
 This is the design document for the `autoware_auto_tf2` package.
 
@@ -110,7 +110,7 @@ inline void doTransform(
   const geometry_msgs::msg::TransformStamped & transform)
 ```
 
-- `Quarternion32` (`autoware_auto_msgs`)
+- `Quaternion32` (`autoware_auto_msgs`)
 
 ```cpp
 inline void doTransform(
@@ -169,15 +169,15 @@ inline std::string getFrameId(const BoundingBoxArray & t)
 
 ## Challenges
 
-- `tf2_geometry_msgs` does not implement `doTransform` for any non-stamped datatypes, but it is
+- `tf2_geometry_msgs` does not implement `doTransform` for any non-stamped data types, but it is
   possible with the same function template. It is needed when transforming sub-data, with main data
   that does have a stamp and can call doTransform on the sub-data with the same transform. Is this a useful upstream contribution?
 - `tf2_geometry_msgs` does not have `Point`, `Point32`, does not seem it needs one, also the
   implementation of non-standard `toMsg` would not help the convert.
 - `BoundingBox` uses 32-bit float like `Quaternion32` and `Point32` to save space, as they are used
   repeatedly in `BoundingBoxArray`. While transforming is it better to convert to 64-bit `Quaternion`,
   `Point`, or `PoseStamped`, to re-use existing implementation of `doTransform`, or does it need to be
-  implemented? Templatization may not be simple.
+  implemented? It may not be simple to template.
 
 <!-- # Related issues -->
 <!-- Required -->

common/autoware_testing/design/autoware_testing-design.md

@@ -1,4 +1,4 @@
-# autoware_testing {#autoware_testing-package-design}
+# autoware_testing
 
 This is the design document for the `autoware_testing` package.
 

common/fake_test_node/design/fake_test_node-design.md

@@ -1,4 +1,4 @@
-# Fake Test Node {#fake-test-node-design}
+# Fake Test Node
 
 ## What this package provides
 

common/osqp_interface/design/osqp_interface-design.md

@@ -1,4 +1,4 @@
-# Interface for the OSQP library {#osqp_interface-package-design}
+# Interface for the OSQP library
 
 This is the design document for the `osqp_interface` package.
 

common/vehicle_constants_manager/design/vehicle_constants_manager-design.md

@@ -1,4 +1,4 @@
-# vehicle_constants_manager {#vehicle-constants-manager-package-design}
+# vehicle_constants_manager
 
 This is the design document for the `vehicle_constants_manager` package.
 
@@ -83,7 +83,7 @@ vehicle:
   inertia_yaw_kg_m_2:
 ```
 
-## Inputs / Outputs / API {#vehicle-constants-manager-package-design-inputs}
+## Inputs / Outputs / API
 
 <!-- Required -->
 <!-- Things to consider:

control/trajectory_follower/design/trajectory_follower-design.md

@@ -1,4 +1,4 @@
-# Trajectory Follower {#trajectory_follower-package-design}
+# Trajectory Follower
 
 This is the design document for the `trajectory_follower` package.
 
@@ -12,9 +12,9 @@ This package provides the library code used by the nodes of the `trajectory_foll
 Mainly, it implements two algorithms:
 
 - Model-Predictive Control (MPC) for the computation of lateral steering commands.
-  - @subpage trajectory_follower-mpc-design
+  - [trajectory_follower-mpc-design](trajectory_follower-mpc-design.md)
 - PID control for the computation of velocity and acceleration commands.
-  - @subpage trajectory_follower-pid-design
+  - [trajectory_follower-pid-design](trajectory_follower-pid-design.md)
 
 ## Related issues
 

control/trajectory_follower/design/trajectory_follower-mpc-design.md

@@ -1,4 +1,4 @@
-# MPC (Trajectory Follower) {#trajectory_follower-mpc-design}
+# MPC (Trajectory Follower)
 
 This is the design document for the MPC implemented in the `trajectory_follower` package.
 
@@ -34,7 +34,7 @@ Different vehicle models are implemented:
 
 The `kinematics` model is being used by default. Please see the reference [1] for more details.
 
-For the optimization, a Quadratric Programming (QP) solver is used
+For the optimization, a Quadratic Programming (QP) solver is used
 with two options are currently implemented:
 
 - `unconstraint` : use least square method to solve unconstraint QP with eigen.

control/trajectory_follower/design/trajectory_follower-pid-design.md

@@ -1,4 +1,4 @@
-# PID (Trajectory Follower) {#trajectory_follower-pid-design}
+# PID (Trajectory Follower)
 
 This is the design document for the PID implemented in the `trajectory_follower` package.
 

control/trajectory_follower_nodes/design/lateral_controller-design.md

@@ -1,4 +1,4 @@
-# Lateral Controller {#lateral-controller-design}
+# Lateral Controller
 
 This is the design document for the lateral controller node
 in the `trajectory_follower_nodes` package.
@@ -23,7 +23,7 @@ The MPC uses a model of the vehicle to simulate the trajectory resulting from th
 The optimization of the control command is formulated as a Quadratic Program (QP).
 
 These functionalities are implemented in the `trajectory_follower` package
-(see @subpage trajectory_follower-mpc-design)
+(see [trajectory_follower-mpc-design](../../trajectory_follower/design/trajectory_follower-mpc-design.md#mpc-trajectory-follower))
 
 ### Assumptions / Known limits
 

control/trajectory_follower_nodes/design/latlon_muxer-design.md

@@ -1,4 +1,4 @@
-# Lateral/Longitudinal Control Muxer {#latlon-muxer-design}
+# Lateral/Longitudinal Control Muxer
 
 ## Purpose
 

control/trajectory_follower_nodes/design/longitudinal_controller-design.md

@@ -1,4 +1,4 @@
-# Longitudinal Controller {#longitudinal-controller-design}
+# Longitudinal Controller
 
 ## Purpose / Use cases
 

control/trajectory_follower_nodes/design/trajectory_follower-design.md

@@ -1,4 +1,4 @@
-# Trajectory Follower Nodes {#trajectory_follower_nodes-package-design}
+# Trajectory Follower Nodes
 
 ## Purpose
 
@@ -8,12 +8,12 @@ Generate control commands to follow a given Trajectory.
 
 This functionality is decomposed into three nodes.
 
-- @subpage lateral-controller-design : generates lateral control messages.
-- @subpage longitudinal-controller-design : generates longitudinal control messages.
-- @subpage latlon-muxer-design : combines the lateral and longitudinal control commands
+- [lateral-controller-design](lateral_controller-design.md) : generates lateral control messages.
+- [longitudinal-controller-design](longitudinal_controller-design.md) : generates longitudinal control messages.
+- [latlon-muxer-design](latlon_muxer-design.md) : combines the lateral and longitudinal control commands
   into a single control command.
 
-Core functionalities are implemented in the @subpage trajectory_follower-package-design package.
+Core functionalities are implemented in the [trajectory_follower](../../trajectory_follower/design/trajectory_follower-design.md#trajectory-follower) package.
 
 @image html images/trajectory_follower-diagram.png "Overview of the Trajectory Follower package"
 

perception/tensorrt_yolo/README.md

@@ -8,6 +8,8 @@ This package detects 2D bounding boxes for target objects e.g., cars, trucks, bi
 
 ### Cite
 
+<!-- cspell:ignore Redmon, Farhadi, Bochkovskiy, Jocher, ultralytics, Roboflow, Zenodo -->
+
 yolov3
 
 Redmon, J., & Farhadi, A. (2018). Yolov3: An incremental improvement. arXiv preprint arXiv:1804.02767.

planning/behavior_velocity_planner/occlusion-spot-design.md

@@ -100,7 +100,7 @@ obstacle that can run out from occlusion should have free space until intersecti
 
 ##### Possible Collision
 
-obstacle that can run out from occlusion is interruped by moving vehicle.
+obstacle that can run out from occlusion is interrupted by moving vehicle.
 ![brief](./docs/occlusion_spot/raycast_shadow.drawio.svg)
 
 #### Module Parameters

simulator/simple_planning_simulator/design/simple_planning_simulator-design.md

@@ -1,4 +1,4 @@
-# simple_planning_simulator {#simple_planning_simulator-package-design}
+# simple_planning_simulator
 
 ## Purpose / Use cases