Update codespell-project/codespell (#960)

.codespell_words

@@ -0,0 +1 @@
+SINIC

.pre-commit-config.yaml

@@ -49,7 +49,7 @@ repos:
         args: ['-fallback-style=none', '-i']
 
   - repo: https://github.com/codespell-project/codespell
-    rev: v2.0.0
+    rev: v2.3.0
     hooks:
       - id: codespell
-        args: ['--write-changes']
+        args: ['--write-changes', '--ignore-words=.codespell_words']

doc/examples/creating_moveit_plugins/lerp_motion_planner/src/lerp_interface.cpp

@@ -72,7 +72,7 @@ bool LERPInterface::solve(const planning_scene::PlanningSceneConstPtr& planning_
   std::vector<double> start_joint_values;
   start_state->copyJointGroupPositions(joint_model_group, start_joint_values);
 
-  // This planner only supports one goal constriant in the request
+  // This planner only supports one goal constraint in the request
   std::vector<moveit_msgs::Constraints> goal_constraints = req.goal_constraints;
   std::vector<moveit_msgs::JointConstraint> goal_joint_constraint = goal_constraints[0].joint_constraints;
 

doc/examples/hybrid_planning/hybrid_planning_tutorial.rst

@@ -90,7 +90,7 @@ To include the Hybrid Planning Architecture into you project you need to add a *
 
 Customizing the Hybrid Planning Architecture
 --------------------------------------------
-As the rest of MoveIt 2, the *Hybrid Planning Architecture* is designed to be highly customizable while also offering the possibility to easily re-use existing solutions. Each of the architecture's components is a ROS 2 node and can be completely replaced by your own custom ROS 2 node as long as it offers the API required by the other nodes. Each component's runtime behavior is defined by plugins. This section focuses on the customization of the *Hybrid Planning Architecture* by implementing your own plugins.
+As the rest of MoveIt 2, the *Hybrid Planning Architecture* is designed to be highly customizable while also offering the possibility to easily reuse existing solutions. Each of the architecture's components is a ROS 2 node and can be completely replaced by your own custom ROS 2 node as long as it offers the API required by the other nodes. Each component's runtime behavior is defined by plugins. This section focuses on the customization of the *Hybrid Planning Architecture* by implementing your own plugins.
 
 Global and Local Motion Planning
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

doc/examples/moveit_grasps/moveit_grasps_tutorial.rst

@@ -219,7 +219,7 @@ The ``setIdealGraspPoseRPY()`` and ``setIdealGraspPose()`` methods in GraspGener
 
 These methods is used to score grasp candidates favoring grasps that are closer to the desired orientation.
 
-This is useful in applications such as bin and shelf picking where you would want to pick the objects from a bin with a grasp that is vertically aligned and you would want to pick obejects from a shelf with a grasp that is horozontally aligned.
+This is useful in applications such as bin and shelf picking where you would want to pick the objects from a bin with a grasp that is vertically aligned and you would want to pick objects from a shelf with a grasp that is horizontally aligned.
 
 Tested Robots
 -------------

doc/examples/realtime_servo/realtime_servo_tutorial.rst

@@ -104,7 +104,7 @@ Because the kinematics are handled by the core parts of MoveIt, it is recommende
 
 Using the C++ API
 ------------------
-This can be beneficial when there is a performance requirement to avoid the overhead of ROS communication infrastucture, or when the output generated by Servo needs to be fed into some other controller that does not have a ROS interface.
+This can be beneficial when there is a performance requirement to avoid the overhead of ROS communication infrastructure, or when the output generated by Servo needs to be fed into some other controller that does not have a ROS interface.
 
 When using MoveIt Servo with the C++ interface the three input command types are ``JointJogCommand``, ``TwistCommand`` and ``PoseCommand``.
 The output from Servo when using the C++ interface is ``KinematicState``, a struct containing joint names, positions, velocities and accelerations.

doc/examples/trajopt_planner/trajopt_planner_tutorial.rst

@@ -75,7 +75,7 @@ Motion planning problem in TrajOpt is defined by a set of cost (COST) and constr
 
   - *GIVEN_TRAJ*: the user provides the entire trajectory for ``data`` member.
 
-- **TermInfo**: This is the base struct for all types of COST and CNT functions that are carried by ``cost_infos`` and ``cnt_infos`` members. COST functions are the objectives that are supposed to be minimized and CNT are the ones that must be satisfied. The current implementation contains ``JointPoseTermInfo``, ``JointVelTermInfo`` (hard-coded) and ``CartPoseTermInfo`` (is partially implemented). Member *term_type* dictates the type of the term we are adding; it could be ``TT_COST`` or ``TT_CNT`` which means a cost term or constraint term respectively. Also ``TT_USE_TIME`` can be selected for this member which allows time parameterization. In this case *use_time* of ``BasicInfo`` should be set to ``true`` as well.  The other parameters of these terms which need to be set are loaded from ``trajopt_planning.yaml`` file. The following list describes these parametrs:
+- **TermInfo**: This is the base struct for all types of COST and CNT functions that are carried by ``cost_infos`` and ``cnt_infos`` members. COST functions are the objectives that are supposed to be minimized and CNT are the ones that must be satisfied. The current implementation contains ``JointPoseTermInfo``, ``JointVelTermInfo`` (hard-coded) and ``CartPoseTermInfo`` (is partially implemented). Member *term_type* dictates the type of the term we are adding; it could be ``TT_COST`` or ``TT_CNT`` which means a cost term or constraint term respectively. Also ``TT_USE_TIME`` can be selected for this member which allows time parameterization. In this case *use_time* of ``BasicInfo`` should be set to ``true`` as well.  The other parameters of these terms which need to be set are loaded from ``trajopt_planning.yaml`` file. The following list describes these parameters:
 
   - *coeffs*: weight coefficients for joints
 

doc/tutorials/pick_and_place_with_moveit_task_constructor/pick_and_place_with_moveit_task_constructor.rst

@@ -426,7 +426,7 @@ As mentioned above, this function creates a MoveIt Task Constructor object and s
       task.setProperty("eef", hand_group_name);
       task.setProperty("ik_frame", hand_frame);
 
-Now, we add an example stage to the node. The first line sets ``current_state_ptr`` to ``nullptr``; this creates a pointer to a stage such that we can re-use stage information in specific scenarios. This line is not used at this moment, but will be used later when more stages are added to the task. Next, we make a ``current_state`` stage (a generator stage) and add it to our task - this starts the robot off in its current state. Now that we've created the ``CurrentState`` stage, we save a pointer to it in the ``current_state_ptr`` for later use.
+Now, we add an example stage to the node. The first line sets ``current_state_ptr`` to ``nullptr``; this creates a pointer to a stage such that we can reuse stage information in specific scenarios. This line is not used at this moment, but will be used later when more stages are added to the task. Next, we make a ``current_state`` stage (a generator stage) and add it to our task - this starts the robot off in its current state. Now that we've created the ``CurrentState`` stage, we save a pointer to it in the ``current_state_ptr`` for later use.
 
 .. code-block:: c++
 

doc/tutorials/your_first_project/your_first_project.rst

@@ -177,7 +177,7 @@ In the workspace directory, ``ws_moveit``, run this command:
 
   colcon build --mixin debug
 
-After this succeeds, we need to re-use the demo launch file from the previous tutorial to start RViz and the MoveGroup node.
+After this succeeds, we need to reuse the demo launch file from the previous tutorial to start RViz and the MoveGroup node.
 In a separate terminal, source the workspace and then execute this:
 
 .. code-block:: bash