robotic-decision-making-lab / alpha Goto Github PK
View Code? Open in Web Editor NEWROS 2 interface for the Reach Alpha 5 manipulator.
License: MIT License
ROS 2 interface for the Reach Alpha 5 manipulator.
License: MIT License
There is no enforcement of development standards for the project.
Implement a CI pipeline using Github Actions to validate adherence of implemented features to coding standards
N/A
ROS Industrial provides a CI pipeline that could be used for this system. Checks that should be performed include:
The Alpha driver project does not integrate a CODE_OF_CONDUCT
document.
Integrate a CODE_OF_CONDUCT.md
to the project to make the project more inclusive.
N/A
This can be based off of the Django Project conduct guidelines.
N/A
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.
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.
Alternatively, the project could be kept private and not distributed.
I anticipate that the license will need to be updated in two locations:
alpha_description
(currently licensed under MIT)alpha_driver
(currently licensed under MIT)These two packages use Reach assets and are likely copyrighted.
N/A
The packet ID values assigned to the kmBoxObstacle0x
constants are incorrect according to the protocol specification.
The invalid packet specification is defined in packet_id.hpp
. When accessing these values, the incorrect value is provided.
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
No response
All of the environments!
No response
There is no documentation discussing the project contribution guidelines. This makes it difficult for new developers to approach the project and contribute new features.
Write a new contribution guidelines document that describes the steps to contribute to the project.
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.
Add a CONTRIBUTING.md
document that defines the steps to contribute and the types of contributions that are accepted.
There are no publicly available SDKs or drivers available for the Alpha manipulator.
Implement a driver for interfacing with the Alpha manipulator from a Linux system.
Contact Reach Robotics to re-request an SDK license (previously failed)
The driver should implement the following features:
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.
Implement forward kinematics to calculate the end-effector pose from the joint angles
N/A
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.
N/A
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.
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.
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.
Create the respective Doxygen configuration files needed to build the site.
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;
Remove the unused code.
N/A
N/A
This was originally requested in another PR, but I forgot to push that change.
The alpha
system does not provide an interface for servoing using the master arm or some other controller.
Implement the ability to manually override the autonomous control to perform manual servoing using either the master arm or an XBox controller.
N/A
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.
Changing existing functionality in the Alpha driver
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.
Switch instances of std::bind
to lambda functions.
No response
Here is a relevant StackOverflow article discussing this implementation.
Adding new functionality to the Alpha driver
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.
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.
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.
Here is an example extension which can be used as a reference.
Adding new functionality to the Alpha driver
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.
Implement support for Gazebo Garden. This will require integrating a simplified physics model and reworking the existing URDFs.
evan need sleep
No response
The existing simulation interface doesn't properly simulate the gripper. They currently flop around.
Run the simulation environment:
ros2 launch alpha_bringup alpha.launch.py use_sim:=true
The jaws should represent the mimic behavior defined in the URDF.
No response
NVIDIA development container.
No response
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.
Integrate Github Actions to build images and push them to a registry for personal use.
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.
A pipeline should be added to build the following images:
N/A
Changing existing functionality in the Alpha driver
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).
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).
No response
No response
Changing existing functionality in the Alpha driver
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.
Require the full path to the configuration file to be provided at launch rather than a configuration file in the alpha_bringup/configs
directory.
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.
No response
Changing existing functionality in the Alpha driver
The existing namespace convention is difficult to maintain and manage. It would be better to split the namespaces at the module level.
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
The existing namespace definitions could be kept, however, this would make it difficult to extend the project to include new namespaces.
No response
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.
Remove the devcontainer/
from the project
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.
N/A
N/A
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]
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
The command interface should successfully send the commands.
No response
Docker container running on a Raspberry Pi 4
No response
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.
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
The Alpha arm should not vibrate or shake.
N/A
v0.0.1
Desktop running Ubuntu 22.04 natively. The issues are observed when running Gazebo in the development container.
N/A
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.
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.
The arm should be sitting in the desired initial position and responding to commands.
No response
This is observed in the NVIDIA devcontainer.
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.
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.
alpha
project.docker build -f .docker/Dockerfile .
The build process should be able to successfully identify and install all ROS 2 dependencies.
#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]
This error occurs both locally (Desktop computer with Ubuntu 22.04 installed natively) and in the CI pipelines.
No response
Adding new functionality to the Alpha driver
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.
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.
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.
No response
Changing existing functionality in the Alpha driver
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.
Replace the "platform" with a table or workbench model. This will make things a bit more visually appealing, especially for new users.
I would ultimately prefer to not have a platform at all, but I think a table is a nice solution too.
No response
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.
Update the Docker build pipelines to publish an additional image for an Arm architecture.
This could be ignored and users could be required to install natively to use the project on an Arm architecture
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.
N/A
Can this project be used for this robotic arm to achieve imitation learning through Gaussian process regression
With the integration of ros2_control
, the alpha
project will include an involved launch system which could make it difficult for users to manage.
Implement a ROS2 package responsible for managing the launch of the alpha
system.
N/A
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).
N/A
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.
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.
Alternatively, this data could be manually logged and recorded, but this could make it more difficult to integrate external diagnostics tools.
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.
An example has been implemented for ROS2 Humble and can be accessed here
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.
Extend the Docker CD pipelines to publish to Docker Hub
Exclude support for Docker Hub
Extend the docker.yaml
to publish to Docker Hub.
N/A
Changing existing functionality in the Alpha driver
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.
Create a logger class member to use. This will make it easier to manage the logging interface.
There are projects that use the same approach to logging as that already done, so this could be left as-is.
No response
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.
Explore a safe way to implement a thread pool which should be used to execute packet callbacks.
Alternatively, this could be left as-is and require users to ensure that their methods do not take significant amounts of time to complete.
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.
Adding new functionality to the Alpha driver
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.
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.
No response
No response
The existing README does not include discussion regarding how to install the project using Docker.
Update the README to document installation using Docker.
Don't add documentation ๐
Document the steps to fetch the production and development docker images..
N/A
There is no control interface for the manipulator within the driver or built into the manipulator itself.
Integrate a joint position controller and a joint velocity controller that directly supports the alpha_driver
and enables controlling all joints of the arm.
N/A
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
ros2_control
joints and interfacesThere is currently no user documentation introducing the project or how to use it.
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.
The user documentation could be embedded directly into the README. However, this would make the README difficult to approach and would reduce project exposure.
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.
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.
This error exists regardless of steps taken.
The joint limits should be set as follows:
No response
This error exists regardless of the runtime environment
The related documentation can be found here. The specific document is the Reach Alpha Integration Manual.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.