diff --git a/.codespell_words b/.codespell_words new file mode 100644 index 0000000000..efe29faac7 --- /dev/null +++ b/.codespell_words @@ -0,0 +1 @@ +SINIC diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml index 79e8cbb9f8..0785bcbac8 100644 --- a/.pre-commit-config.yaml +++ b/.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'] diff --git a/doc/examples/creating_moveit_plugins/lerp_motion_planner/src/lerp_interface.cpp b/doc/examples/creating_moveit_plugins/lerp_motion_planner/src/lerp_interface.cpp index d2b0739193..1401a4dfdb 100644 --- a/doc/examples/creating_moveit_plugins/lerp_motion_planner/src/lerp_interface.cpp +++ b/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 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 goal_constraints = req.goal_constraints; std::vector goal_joint_constraint = goal_constraints[0].joint_constraints; diff --git a/doc/examples/hybrid_planning/hybrid_planning_tutorial.rst b/doc/examples/hybrid_planning/hybrid_planning_tutorial.rst index 54ffc75aa6..a8475355d4 100644 --- a/doc/examples/hybrid_planning/hybrid_planning_tutorial.rst +++ b/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 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ diff --git a/doc/examples/moveit_grasps/moveit_grasps_tutorial.rst b/doc/examples/moveit_grasps/moveit_grasps_tutorial.rst index 64b68faef5..3ebf67975b 100644 --- a/doc/examples/moveit_grasps/moveit_grasps_tutorial.rst +++ b/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 ------------- diff --git a/doc/examples/realtime_servo/realtime_servo_tutorial.rst b/doc/examples/realtime_servo/realtime_servo_tutorial.rst index 09401bf45f..65069eb1bf 100644 --- a/doc/examples/realtime_servo/realtime_servo_tutorial.rst +++ b/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. diff --git a/doc/examples/trajopt_planner/trajopt_planner_tutorial.rst b/doc/examples/trajopt_planner/trajopt_planner_tutorial.rst index 26b90220c3..375b9fe7ee 100644 --- a/doc/examples/trajopt_planner/trajopt_planner_tutorial.rst +++ b/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 diff --git a/doc/tutorials/pick_and_place_with_moveit_task_constructor/pick_and_place_with_moveit_task_constructor.rst b/doc/tutorials/pick_and_place_with_moveit_task_constructor/pick_and_place_with_moveit_task_constructor.rst index 3c64bcca84..f3832561f2 100644 --- a/doc/tutorials/pick_and_place_with_moveit_task_constructor/pick_and_place_with_moveit_task_constructor.rst +++ b/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++ diff --git a/doc/tutorials/your_first_project/your_first_project.rst b/doc/tutorials/your_first_project/your_first_project.rst index f4d9a0c133..2c15798feb 100644 --- a/doc/tutorials/your_first_project/your_first_project.rst +++ b/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