Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cartesian Overlay Support #243

Open
RLi43 opened this issue Dec 18, 2024 · 6 comments
Open

Cartesian Overlay Support #243

RLi43 opened this issue Dec 18, 2024 · 6 comments
Labels
enhancement New feature or request

Comments

@RLi43
Copy link

RLi43 commented Dec 18, 2024

Hello, do you have any plan to implement FRI Cartesian Overlay?

I can see that at least we need to

  • define a hardware component "Cartesian" GPIO
  • implement a switch between Joint Overlay and Cartesian Overlay, as they can't coexist
  • implement an additional communication channel with the server changing the overlay type if we would like to switch it on the fly
@mhubii
Copy link
Member

mhubii commented Jan 4, 2025

hi @RLi43, apologize the late response. What you suggest is correct. I don't have access to FRI 2.x so cannot test this on the hardware. However, I am happy to collaborate and walk you through the steps if you are willing to create pull requests.

As a quick workaround, one way to command twists is to run

ros2 launch lbr_bringup hardware.launch.py ctrl:=twist_controller

If you wish to switch controllers through ros2_control, you can do so using e.g. (https://control.ros.org/rolling/doc/ros2_control/controller_manager/doc/userdoc.html#rqt-controller-manager)

ros2 run rqt_controller_manager rqt_controller_manager

This can also be done programmatically through service calls.

@RLi43
Copy link
Author

RLi43 commented Jan 4, 2025

@mhubii Thanks for your reply and happy new year : )

I did some work and implemented cartesian overlay but it's very rudimental. I'd better clean my code further before creating pull requests.
On the other hand, I started to doubt whether it makes sense to use Cartesian Overlay. My initial motivation is to have all the kinematic calculations done on the robot itself as it's faster and more precise. But they are inevitable once you start to consider the valid joint angle ranges, obstacle avoidance using the null space, shortest path from the current configuration, ...

@mhubii mhubii added the enhancement New feature or request label Jan 5, 2025
@RLi43
Copy link
Author

RLi43 commented Jan 10, 2025

I will update my changes on my forks:
https://github.com/RLi43/lbr_fri_ros2_stack/tree/lbr-stack
https://github.com/RLi43/lbr_fri_idl/tree/fri-2

Currently, it works but has not been tested whether it's compatible with JointOverlay.

@RLi43 RLi43 closed this as completed Jan 10, 2025
@mhubii
Copy link
Member

mhubii commented Jan 11, 2025

thanks for this @RLi43, lets keep this issue open for now. Would you mind creating a pull request?

@mhubii mhubii reopened this Jan 11, 2025
@RLi43
Copy link
Author

RLi43 commented Jan 11, 2025

Sure, I'd like to, once I test the compatibility with joint overlay.
Also I modified the command interface logic trying to avoid triggering the speed limit stop.

@mhubii
Copy link
Member

mhubii commented Jan 13, 2025

thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants