robotic-decision-making-lab / alpha

ROS 2 interface for the Reach Alpha 5 manipulator.

Reach Alpha 5 ROS 2 Driver 🦾

The Alpha 5 driver is a collection of ROS 2 packages designed to support ROS 2 integration with the Reach Alpha 5 manipulator.

⚠️ Disclaimer ⚠️

This is an independent project, and is not affiliated with or maintained by Reach Robotics. Please refer to the Reach Robotics SDK for all official software.

Main features

The main features of the Alpha 5 driver are:

• Integration of the Reach System Serial Protocol for hardware communication
• ros2_control integration for manipulator position, velocity, and joint trajectory control
• Simulation support using Gazebo Garden
• Visualization support using RViz2
• Integration with MoveIt2 for motion planning

Installation

The Alpha 5 driver is currently supported on Linux, and is available for the ROS distributions Humble and Rolling. To install the Alpha 5 driver, first clone this project to the src directory of your ROS workspace, replacing $ROS_DISTRO with the desired ROS distribution or main for Rolling:

git clone -b $ROS_DISTRO [email protected]:evan-palmer/alpha.git

After cloning the project, install the ROS dependencies using rosdep, again, replacing $ROS_DISTRO with the desired ROS distribution:

rosdep update && \
rosdep install -y --from-paths src --ignore-src --rosdistro $ROS_DISTRO

Quick start

A ROS 2 launch file has been provided to start the Alpha 5 driver. To launch the driver using default arguments, run

ros2 launch alpha_bringup alpha.launch.py

A full description of the launch arguments and their respective default values can be obtained by running the following command:

ros2 launch alpha_bringup alpha.launch.py --show-args

Getting help

If you have questions regarding usage of the Alpha 5 driver or regarding contributing to this project, please ask a question on our Discussions board!

License

Any proprietary documents or software owned by Reach Robotics and used within this project are made available with official permission from Reach Robotics and have been documented accordingly. All other software is is released under the MIT license.

alpha's Issues

party

[FEATURE]: Implement forward kinematics for end-effector pose calculation

Is your feature request related to a problem? Please describe

The Reach Robotics forward kinematics interface is proprietary and not suitable for open-source software. Because of this there is no way to capture the end-effector pose without performing forward kinematics.

Describe the solution you'd like

Implement forward kinematics to calculate the end-effector pose from the joint angles

Describe alternatives you've considered

N/A

Implementation Ideas

Implement a new subscriber that subscribes to the joint angle topic. The subscriber should bind a callback to the topic which calculates the end-effector position using forward kinematics. The resulting end-effector pose should be republished as a PoseStamped message.

Additional context

N/A

[FEATURE]: Add support to load the driver as a BlueOS extension

Feature Type

Adding new functionality to the Alpha driver

Problem Description

A common application for the Reach Alpha 5 manipulator is onboard the BlueROV2. Blue Robotics, the company that builds the BlueROV2, has recently started to integrate support for custom extensions which are an entrypoint for custom software. This entrypoint would be an excellent location to integrate support for the Alpha driver.

Feature Description

Update the Dockerfile to include an "extension" stage which includes all required labels described in the Blue Robotics Extensions documentation. To support launching the interface, it may also be useful to incorporate a web-based user interface to support launching the driver with custom configurations.

Alternative Solutions

Another alternative could be to modify the stage to include a hard-coded entrypoint which launches the driver. This may be fine for initial testing of the driver; however, for a full public release, a user interface should be defined.

Additional Context

Here is an example extension which can be used as a reference.

[FEATURE]: Remove devcontainer from project

Is your feature request related to a problem? Please describe

The current development process has only included one developer, which has made this conducive to using a devcontainer for development. Once this project becomes open sourced, however, it will be necessary to remove that as this is an undocumented feature and is not accessible to all users.

Describe the solution you'd like

Remove the devcontainer/ from the project

Describe alternatives you've considered

This could be left in and documentation could be added. However, dev containers are generally not fully accessible to developers and should be left for personal development. As such, it may be necessary to introduce some additional steps into the CI pipelines that handle formatting of Dockerfiles, xml, json, yaml, etc.

Implementation Ideas

N/A

Additional context

N/A

[FEATURE]: Create logger instance in classes

Feature Type

Changing existing functionality in the Alpha driver

Problem Description

The existing implementation uses a redundant approach to logging. Specifically, the current implementation makes a call to the rclcpp interface to get a logger with a given name and then to generate a log with that logger. This is redundant and difficult to maintain.

Feature Description

Create a logger class member to use. This will make it easier to manage the logging interface.

Alternative Solutions

There are projects that use the same approach to logging as that already done, so this could be left as-is.

Additional Context

No response

[BUG]: MoveIt2-Gazebo integration doesn't work out-of-the-box

Issue Description

The existing Gazebo integration spawns the arm inside the ground place. While this would be fine if the initial positions were applied, the model is currently stuck in the ground and doesn't respond to commands because of this.

Steps to Reproduce

Launch the Gazebo environment using the following command:

ros2 launch alpha_bringup alpha.launch.py use_sim:=true

Any controller can be used with this.

Expected Behavior

The arm should be sitting in the desired initial position and responding to commands.

Error Message

No response

Runtime Environment

This is observed in the NVIDIA devcontainer.

Additional Context

The issue that I raised regarding the initial positions is here. Once I finish my experiments in the next couple of week, I may start looking into a fix over there.

[FEATURE]: Implement manipulator limit ROS interface

Feature Type

Adding new functionality to the Alpha driver

Problem Description

Implement configurations that modify the configured Alpha limits on startup. The current interface handles this using only MoveIt; however, if the other control interfaces are used, then there is no way (currently) to modify the manipulator's limits.

Feature Description

Implement a driver endpoint that configures the Reach Alpha limits. This endpoint should be used by the alpha_hardware on_init() method to configure the endpoints using parameters from either the launch configuration or a configuration file.

Alternative Solutions

No response

Additional Context

No response

[BUG]: Docker build fails when trying to find MoveIt2 rolling packages

Issue Description

The current Docker build pipelines fail when attempting to install certain MoveIt2 rolling packages. The first package that fails is ros-rolling-moveit-ros-move-group. Upon further inspection, it appears as though ros-rolling-moveit also fails.

Steps to Reproduce

1. Navigate to the base directory of the alpha project.
2. Build the Docker image using "rolling" as the target ROS 2 distribution:

docker build -f .docker/Dockerfile .

3. The resulting error occurs when installing MoveIt2 during the Docker build.

Expected Behavior

The build process should be able to successfully identify and install all ROS 2 dependencies.

Error Message

#10 20.28 Reading state information...
#10 20.29 E: Unable to locate package ros-rolling-moveit-ros-move-group
#10 20.29 ERROR: the following rosdeps failed to install
#10 20.29   apt: command [apt-get install -y ros-rolling-moveit-ros-move-group] failed
#10 20.29 executing command [apt-get install -y ros-rolling-moveit-ros-move-group]

Runtime Environment

This error occurs both locally (Desktop computer with Ubuntu 22.04 installed natively) and in the CI pipelines.

Additional Context

No response

[FEATURE]: Integrate multi-architecture build workflow stage

Is your feature request related to a problem? Please describe

When mounted to another vehicle (e.g., an ROV), the Alpha driver is likely to be run on an embedded device such as a raspberry Pi. The existing Docker build pipelines do not support multi-architecture builds which means that the existing images would not work on a Raspberry Pi.

Describe the solution you'd like

Update the Docker build pipelines to publish an additional image for an Arm architecture.

Describe alternatives you've considered

This could be ignored and users could be required to install natively to use the project on an Arm architecture

Implementation Ideas

Add additional steps to the docker.yaml workflow that load an emulator such as Qemu and use buildx to build the image for the specified architecture.

Additional context

N/A

[FEATURE]: Implement a Github Actions pipeline for project CI

Is your feature request related to a problem? Please describe

There is no enforcement of development standards for the project.

Describe the solution you'd like

Implement a CI pipeline using Github Actions to validate adherence of implemented features to coding standards

Describe alternatives you've considered

N/A

Implementation Ideas

ROS Industrial provides a CI pipeline that could be used for this system. Checks that should be performed include:

• Clang Tidy checks
• Clang Format checks
• Unit tests
• License checks

Additional context

ROS Industrial CI Github

[FEATURE]: Add Code of Conduct for project

Is your feature request related to a problem? Please describe

The Alpha driver project does not integrate a CODE_OF_CONDUCT document.

Describe the solution you'd like

Integrate a CODE_OF_CONDUCT.md to the project to make the project more inclusive.

Describe alternatives you've considered

N/A

Implementation Ideas

This can be based off of the Django Project conduct guidelines.

Additional context

N/A

[FEATURE]: Integrate ROS diagnostics for hardware diagnostics

Is your feature request related to a problem? Please describe

The Reach Alpha manipulator publishes diagnostic information regrading any hardware errors. It would be useful to utilize these error messages in conjunction with the ROS diagnostics framework to better support evaluation of hardware issues and to enable usage of well-supported diagnostics tools.

Describe the solution you'd like

Construct a callback function to receive diagnostics packets from the Reach Alpha manipulator and republish those using a message from diagnostics_msgs to the /diagnostics topic.

Describe alternatives you've considered

Alternatively, this data could be manually logged and recorded, but this could make it more difficult to integrate external diagnostics tools.

Implementation Ideas

The Reach Alpha manipulator publishes diagnostics information at a rate of 1 Hz using the 0x66 packet ID. A callback method should be implemented to subscribe to messages using the diagnostics packet ID and publish a DiagnosticStatus ROS message from diagnostics_msgs. Furthermore diagnostics aggregators should integrated to collect diagnostics data.

Additional context

An example has been implemented for ROS2 Humble and can be accessed here

[FEATURE]: Remove unused clamp method declarations

Is your feature request related to a problem? Please describe

I accidentally forgot to remove the following lines from hardware.hpp (see the permalink):

bool clampPositionToLimits(double position, alpha_driver::DeviceId) const;
bool clampVelocityToLimits(double velocity, alpha_driver::DeviceId) const;

Describe the solution you'd like

Remove the unused code.

Describe alternatives you've considered

N/A

Implementation Ideas

N/A

Additional context

This was originally requested in another PR, but I forgot to push that change.

[FEATURE]: Host user documentation using Github Pages

Is your feature request related to a problem? Please describe

There is currently no user documentation introducing the project or how to use it.

Describe the solution you'd like

Create a user documentation website that describes how to use the project. If possible, it may be worth embedding the developer documentation into the site as well. However, if the theme of choice is not compatible with Doxygen, then the two should be kept separate.

Describe alternatives you've considered

The user documentation could be embedded directly into the README. However, this would make the README difficult to approach and would reduce project exposure.

Implementation Ideas

The easiest approach to developing the documentation site would be to use Sphinx with Github Pages. Alternatively, Gitbooks provides a nice interface for documentation and has free support for open source projects.

Additional context

Gitbook

[FEATURE]: Implement a driver for Linux integration

Is your feature request related to a problem? Please describe

There are no publicly available SDKs or drivers available for the Alpha manipulator.

Describe the solution you'd like

Implement a driver for interfacing with the Alpha manipulator from a Linux system.

Describe alternatives you've considered

Contact Reach Robotics to re-request an SDK license (previously failed)

Implementation Ideas

The driver should implement the following features:

• Ability to asynchronously send commands and requests to the manipulator; this includes encoding and decoding packets using the BPL specification
• Ability to asynchronously receive messages from the manipulator
• Ability to attach callbacks for messages received from the manipulator
• Ability to monitor connectivity to the manipulator and the respective serial port

Additional context

Reach Alpha BPL Protocol Specification

[FEATURE]: Migrate to Gazebo Garden for simulation

Feature Type

Changing existing functionality in the Alpha driver

Problem Description

The current implementation uses the old version of Gazebo. While this is fine and works well for the system, it becomes challenging to integrate the existing implementation into a system which depends on at least Gazebo Garden (namely ardupilot_gazebo).

Feature Description

Migrate from the current version of Gazebo to Gazebo Garden. This will require manual installation of roz_gz; however, previous work has done this without any issues (see here).

Alternative Solutions

No response

Additional Context

No response

[FEATURE]: Implement support for Gazebo Garden

Feature Type

Adding new functionality to the Alpha driver

Problem Description

I previously removed support for Gazebo in #46 due to lack of support. After going through the process of integrating Gazebo support with the Alpha in the Angler project, this should be a relatively straightforward integration. Furthermore, this will reduce some of the redundancies in the project. This can be completed in conjunction with #12 and will also actually close #45.

Feature Description

Implement support for Gazebo Garden. This will require integrating a simplified physics model and reworking the existing URDFs.

Alternative Solutions

evan need sleep

Additional Context

No response

[FEATURE]: Integrate Github Actions build pipeline for images

Is your feature request related to a problem? Please describe

The alpha project is intended to be usable and deployable in multiple environments (e.g., Raspberry Pi, laptop, desktop, etc.). To facilitate these capabilities Docker has been integrated. However, without proper CD pipelines, users are required to manually build images when changes occur which can force usability issues onto users.

Describe the solution you'd like

Integrate Github Actions to build images and push them to a registry for personal use.

Describe alternatives you've considered

Alternative build pipelines could be integrated; however, given that this project is being built for research purposes, maintainability becomes an issue as additional developers work to support the project.

Implementation Ideas

A pipeline should be added to build the following images:

• Production image: this image will include only the packages necessary for deployment with binaries available for use; multiple versions should be created to support different CPU architectures (e.g., ARM vs x86)
• CI image: this image should contain all packages necessary for CI pipelines
• Development image: this image should include all packages needed for individual development with the objective of enabling integration testing and tuning of the system during field experiments

Additional context

N/A

[FEATURE]: Prefer lambda over std::bind

Feature Type

Changing existing functionality in the Alpha driver

Problem Description

The existing implementation utilizes std::bind to connect callbacks for execution. While this is functional, the use of lambdas is generally preferred over std::bind because of its improved readability.

Feature Description

Switch instances of std::bind to lambda functions.

Alternative Solutions

No response

Additional Context

Here is a relevant StackOverflow article discussing this implementation.

[FEATURE]: Cleanup namespace naming

Feature Type

Changing existing functionality in the Alpha driver

Problem Description

The existing namespace convention is difficult to maintain and manage. It would be better to split the namespaces at the module level.

Feature Description

Convert the existing namespaces from names like alpha_hardware to alpha::hardware:

namespace alpha::hardware
{
  <insert the new latest and greatest LLM here>
} // namespace alpha::hardware

Alternative Solutions

The existing namespace definitions could be kept, however, this would make it difficult to extend the project to include new namespaces.

Additional Context

No response

[FEATURE]: Integrate servoing using a manual controller

Is your feature request related to a problem? Please describe

The alpha system does not provide an interface for servoing using the master arm or some other controller.

Describe the solution you'd like

Implement the ability to manually override the autonomous control to perform manual servoing using either the master arm or an XBox controller.

Describe alternatives you've considered

N/A

Implementation Ideas

To implement support for the master arm, endpoints could be added to the driver that enable serial pass-through. To integrate support from an XBox controller, the joystick teleop interface should be added. It may be necessary to integrate the MoveIt2 servoing nodes as well.

Additional context

• KUKA IIWA Servoing
• MoveIt2 Servoing

[FEATURE]: Integrate ros2_control for position & velocity control

Is your feature request related to a problem? Please describe

There is no control interface for the manipulator within the driver or built into the manipulator itself.

Describe the solution you'd like

Integrate a joint position controller and a joint velocity controller that directly supports the alpha_driver and enables controlling all joints of the arm.

Describe alternatives you've considered

N/A

Implementation Ideas

ros2_control provides interface for developing controllers agnostic to the hardware being controlled. Furthermore, because of the strong community that ros2_control possesses, there exists an opportunity to improve maintainability of this system and its control interfaces.

Items that should be implemented within the scope of this issue include:

• ros2_control hardware interface using the SystemInterface
• URDF description specifying the ros2_control joints and interfaces
• Launch interface responsible for launching state broadcasters, the control manager, resource manager, and the required controllers

Additional context

ros2_control doxygen

[FEATURE]: Add support for Docker Hub

Is your feature request related to a problem? Please describe

The project currently hosts all of its packages on the GitHub container registry. While this is a fine solution, it would be more accessible to outside users of the system if the images were available on Docker Hub.

Describe the solution you'd like

Extend the Docker CD pipelines to publish to Docker Hub

Describe alternatives you've considered

Exclude support for Docker Hub

Implementation Ideas

Extend the docker.yaml to publish to Docker Hub.

Additional context

N/A

[FEATURE]: Require full path to configuration file at launch

Feature Type

Changing existing functionality in the Alpha driver

Problem Description

When other projects include the launch file from the alpha project to launch the system, they are required to add a configuration file to the alpha_bringup package instead of the bringup package of the project launching the alpha system. This is cumbersome and makes it difficult to modify the alpha configurations.

Feature Description

Require the full path to the configuration file to be provided at launch rather than a configuration file in the alpha_bringup/configs directory.

Alternative Solutions

Another option could be to break the arguments up to specify the full path to the configuration file directory, then the configuration file name; however, this could be difficult to use and may cause confusion.

Additional Context

No response

[FEATURE]: Add support to generate developer documentation from Doxygen comments

Is your feature request related to a problem? Please describe

The implementation has been documented using Doxygen. To make it easier for new users and developers to get started with contributing to the project, it would be helpful to provide support for generating a site from the comments.

Describe the solution you'd like

Add the necessary files to generate a site from the doxygen comments. It will also be necessary to document the steps to generate this documentation.

Describe alternatives you've considered

If possible, it would be much more useful to generate this documentation as part of the user documentation (see Issue #14). However, if this is not possible, then a separate site may be used.

Implementation Ideas

Create the respective Doxygen configuration files needed to build the site.

Additional context

• Doxygen Manual

[FEATURE]: Update README installation instructions

Is your feature request related to a problem? Please describe

The existing README does not include discussion regarding how to install the project using Docker.

Describe the solution you'd like

Update the README to document installation using Docker.

Describe alternatives you've considered

Don't add documentation 😄

Implementation Ideas

Document the steps to fetch the production and development docker images..

Additional context

N/A

[BUG]: Fix jaws joint mimic in Gazebo

Issue Description

The existing simulation interface doesn't properly simulate the gripper. They currently flop around.

Steps to Reproduce

Run the simulation environment:

ros2 launch alpha_bringup alpha.launch.py use_sim:=true

Expected Behavior

The jaws should represent the mimic behavior defined in the URDF.

Error Message

No response

Runtime Environment

NVIDIA development container.

Additional Context

No response

[FEATURE]: Update the License according to Reach Robotics requests

Is your feature request related to a problem? Please describe

The existing license is unlikely to be compatible with the Reach Robotics licensing. Specifically, given that the project uses the Reach Robotics meshes and their communication protocol, the MIT license will likely violate their licensing agreements.

Describe the solution you'd like

Consult with Reach Robotics to determine the appropriate licensing needed for the project. It may also be useful to consider project ownership transfer to encourage better support the project long-term.

Describe alternatives you've considered

Alternatively, the project could be kept private and not distributed.

Implementation Ideas

I anticipate that the license will need to be updated in two locations:

1. alpha_description (currently licensed under MIT)
2. alpha_driver (currently licensed under MIT)

These two packages use Reach assets and are likely copyrighted.

Additional context

N/A

Alpha 5 achieve imitation learning

Can this project be used for this robotic arm to achieve imitation learning through Gaussian process regression

[FEATURE]: Replace "platform" with workbench or table

Feature Type

Changing existing functionality in the Alpha driver

Problem Description

The platform is a fine way to integrate initial support for gazebo. Though, other projects typically use an object like a table or workbench instead of a simple cube geometry.

Feature Description

Replace the "platform" with a table or workbench model. This will make things a bit more visually appealing, especially for new users.

Alternative Solutions

I would ultimately prefer to not have a platform at all, but I think a table is a nice solution too.

Additional Context

No response

[BUG]: Resolve physical property issues in the Alpha URDF

Describe the bug

The existing URDF uses the defined dynamic properties from the associated Reach Alpha integration manual. However, these properties are unstable in Gazebo, resulting in shaking of the manipulator in simulation. As a patch, physics was disabled in the Gazebo world to provide solely a kinematic simulation environment. This issue seeks to address the shaking issue when physics is enabled in a Gazebo world.

To Reproduce

Enable physics in the empty.world Gazebo file by commenting out or deleting the following lines:

<physics type="ode">
  <max_step_size>0.001</max_step_size>
  <real_time_factor>1</real_time_factor>
  <real_time_update_rate>1000</real_time_update_rate>
  <ode>
    <solver>
      <type>quick</type>
      <iters>0</iters> <!-- 0 iterations to stop physics -->
      <sor>1.4</sor>
    </solver>
    <constraints>
      <cfm>0</cfm>
      <erp>1</erp>
      <contact_max_correcting_vel>0</contact_max_correcting_vel>
      <contact_surface_layer>0</contact_surface_layer>
    </constraints>
  </ode>
</physics>

Save and build the changes. Then, launch the Alpha manipulator using fake hardware and Gazebo:

ros2 launch alpha_bringup alpha.launch.py use_sim:=true

Expected behavior

The Alpha arm should not vibrate or shake.

Stack Traceback

N/A

Project Version

v0.0.1

Desktop

Desktop running Ubuntu 22.04 natively. The issues are observed when running Gazebo in the development container.

Additional context

N/A

[FEATURE]: Add transform broadcasters for base and end effector coordinate frames

Feature Type

Adding new functionality to the Alpha driver

Problem Description

Currently, there is no way to get the coordinate transformation from the base to the end effector and vise-versa. This can be useful when identifying the position of an object relative to the base amongst other planning tasks.

Feature Description

Implement transform broadcasters that publish the transformation from the base frame to the end effector frame and the end effector frame to the base frame.

Alternative Solutions

Not all manipulator libraries provide transform broadcasters and instead rely upon the users to implement those features themselves. While this may be fine because it reduces the overhead associated with maintaining that implementation, it is useful functionality that can improve the usability of the software.

Additional Context

No response

[BUG]: Incorrect joint limits set

Issue Description

The joint limits set in the MoveIt2 joint_limits.yaml and alpha.urdf.xacro are incorrectly set. They should be set according to the Reach Alpha datasheet.

Steps to Reproduce

This error exists regardless of steps taken.

Expected Behavior

The joint limits should be set as follows:

• Joint A: 3 mm/s
• Joint B: 50 degrees/s
• Joint C: 30 degrees/s
• Joint D: 30 degrees/s
• Joint E: 30 degrees/s

Error Message

No response

Runtime Environment

This error exists regardless of the runtime environment

Additional Context

The related documentation can be found here. The specific document is the Reach Alpha Integration Manual.

[BUG]: AlphaHardware incorrectly configures velocity command interface

Issue Description

The velocity command interface does not work on hardware. This is because the export_command_interfaces sets the velocity command interface to the state interface instead of the velocity interface. That is instead of being set to this

info_.joints[i].name, hardware_interface::HW_IF_VELOCITY, &hw_commands_velocities_[i]

The line is set to this

info_.joints[i].name, hardware_interface::HW_IF_VELOCITY, &hw_states_velocities_[i]

Steps to Reproduce

Launch the system using

ros2 launch alpha_bringup alpha.launch.py use_fake_hardware:=false serial_port:=/dev/ttyUSB0 robot_controller:=forward_velocity_controller

Send a command to the velocity interface

Expected Behavior

The command interface should successfully send the commands.

Error Message

No response

Runtime Environment

Docker container running on a Raspberry Pi 4

Additional Context

No response

[FEATURE]: Implement a ROS2 package responsible for launching the alpha system

Is your feature request related to a problem? Please describe

With the integration of ros2_control, the alpha project will include an involved launch system which could make it difficult for users to manage.

Describe the solution you'd like

Implement a ROS2 package responsible for managing the launch of the alpha system.

Describe alternatives you've considered

N/A

Implementation Ideas

Create a new ROS2 package called alpha_bringup. This package should include launch files from each package in the alpha system. Furthermore, parameters should be integrated which enable users to specify how the system will be deployed (e.g., in simulation or on hardware).

Additional context

N/A

[FEATURE]: Add contribution guidelines documentation

Is your feature request related to a problem? Please describe

There is no documentation discussing the project contribution guidelines. This makes it difficult for new developers to approach the project and contribute new features.

Describe the solution you'd like

Write a new contribution guidelines document that describes the steps to contribute to the project.

Describe alternatives you've considered

This could alternatively be included only in the developer documentation; however, given the goal of hosting only user documentation and generating doxygen documentation manually, it would likely be better to have an independent document.

Implementation Ideas

Add a CONTRIBUTING.md document that defines the steps to contribute and the types of contributions that are accepted.

Additional context

• pymavswarm example

[BUG]: Incorrect box obstacle packet ID specification

Issue Description

The packet ID values assigned to the kmBoxObstacle0x constants are incorrect according to the protocol specification.

Steps to Reproduce

The invalid packet specification is defined in packet_id.hpp. When accessing these values, the incorrect value is provided.

Expected Behavior

The correct values are given as follows:

KM_BOX_OBSTACLE_03 = 0xA6
KM_BOX_OBSTACLE_04 = 0xA7
KM_BOX_OBSTACLE_05 = 0xA8
KM_CYLINDER_OBSTACLE_02 = 0xAB

Error Message

No response

Runtime Environment

All of the environments!

Additional Context

No response

[FEATURE]: Explore integrating thread pool for callback execution

Is your feature request related to a problem? Please describe

The SerialClient class implements support for callbacks after successfully reading data from the serial port; however, these callbacks are executed in the main thread loop and may take a long time to perform which can result in delays in the serial port IO. If it can be done safely, it may be helpful to implement a thread pool to call on to execute the callback functions.

Describe the solution you'd like

Explore a safe way to implement a thread pool which should be used to execute packet callbacks.

Describe alternatives you've considered

Alternatively, this could be left as-is and require users to ensure that their methods do not take significant amounts of time to complete.

Implementation Ideas

Two approaches might be possible. First, it could be valuable to simply integrate the existing Boost thread pool implementation; however, this will integrate an additional dependency and the usage of Boost is generally discouraged. Alternatively, there may be an easy path forward to implement this by hand. Decisions will need to be made regarding how to design the thread pool if that is the case.

Additional context

• Boost thread pool