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

offline build option? #104

Closed
CarlDegio opened this issue Aug 8, 2023 · 11 comments
Closed

offline build option? #104

CarlDegio opened this issue Aug 8, 2023 · 11 comments
Assignees
Labels
bug Something isn't working

Comments

@CarlDegio
Copy link

I found new version of SDK has introduced fri_vendor to auto download fri package when build. However, this leads to the PC must link to internet when build. But it's hard when PC link to the kuka.

So is there a method to check fri_vendor already download fri so cancel network connection.

@mhubii
Copy link
Member

mhubii commented Aug 8, 2023

oh thank you for raising this issue. We did introduce this to have a single source for the FRI for python bindings https://github.com/lbr-stack/pyFRI, see #85 (comment)

we will try to add this ASAP, sorry for the inconvenience.

Maybe in the meantime build via colcon build --packages-select name_of_the_package_you_want_to_re_compile, so only your package gets compiled.

May I ask:

  • what branch you are on @CarlDegio ?
  • are you using this stack through MoveIt, ros2_control, or topics?

@mhubii mhubii added the bug Something isn't working label Aug 8, 2023
@mhubii mhubii self-assigned this Aug 8, 2023
@CarlDegio
Copy link
Author

I use humble branch, version 1.2.3. Now use topics mainly.

@mhubii
Copy link
Member

mhubii commented Aug 8, 2023

do you run through python or cpp? Because there are still some issues with noise, when the controlling thread is slower than the commanding thread, but this will be finally fixed

@CarlDegio
Copy link
Author

Yes, I use both of python and cpp. About this I have some thinking.

The FRI interface use the fixed frequency. If the interval is comed but ROS driver doesn't receive the further instructions, the FRI will make robot stop to prevent uncommanded movement just like emergency stop.
However, if the controller thread slower than commanding thread, the commanding thread will receive command with interval. Just like emergency stop and motion switch regularly. At the high frequency, this lead to noise. The most notable example is ROS driver(lbr_bringup) run with 100Hz and command topic publish topic with 50Hz. The motion state will change every 10ms (move->stop->move->stop...).
At the same time, the frequency fluctuation also lead to a tick noise. Because they are not synchronized precisely. Maybe some small motion buffer would be useful.

Besides, I'm looking for end-effort control method using this package. Do you have some good demo? I tried using kinpy but it's a bit slow to solve (about 10Hz).

@CarlDegio
Copy link
Author

oh thank you for raising this issue. We did introduce this to have a single source for the FRI for python bindings https://github.com/lbr-stack/pyFRI, see #85 (comment)

we will try to add this ASAP, sorry for the inconvenience.

Maybe in the meantime build via colcon build --packages-select name_of_the_package_you_want_to_re_compile, so only your package gets compiled.

May I ask:

  • what branch you are on @CarlDegio ?
  • are you using this stack through MoveIt, ros2_control, or topics?

Actually I also used moveit2 (servo) and want to accomplish an end-effort realtime control. But I found the slowly solution and some bug on foxy moveit2 servo so I give up it. It also has some frequency problem.

But the trajectory planning motion on moveit2 works well. Only hard to move in real time.

@mhubii
Copy link
Member

mhubii commented Aug 8, 2023

The motion state will change every 10ms (move->stop->move->stop...).

This will be fixed tomorrow (later today)

@mhubii
Copy link
Member

mhubii commented Aug 9, 2023

okay if you pull the latest changes you will notice smooth robot behavior even for an asynchronous control loop.

The joint names are now A1,... A7, there used to be a robot name prefix

There are some other changes which shouldn't affect you. I'll try to fix the build issue but might take some time.

@CarlDegio
Copy link
Author

okay if you pull the latest changes you will notice smooth robot behavior even for an asynchronous control loop.

The joint names are now A1,... A7, there used to be a robot name prefix

There are some other changes which shouldn't affect you. I'll try to fix the build issue but might take some time.

Thanks for your contribution! I believe lbr_fri_ros2_stack is expected to be the best choice for kuka robots. Now many students in our laboratory are using this package!

@CarlDegio
Copy link
Author

Besides, I'm looking for end-effort control method using this package. Do you have some good demo? I tried using kinpy but it's a bit slow to solve (about 10Hz).

I write a end control node with reference to demo advance c++, link here:https://github.com/CarlDegio/lbr_end_control.git

@mhubii
Copy link
Member

mhubii commented Sep 7, 2023

Very cool, what does it do? Happy to add this to the demos if you think this could be of general interest

@mhubii
Copy link
Member

mhubii commented May 13, 2024

this problem is fixed with #147. The FRI source is now downloaded before building from https://github.com/lbr-stack/fri.

@mhubii mhubii closed this as completed May 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants