Open mihdalal opened 2 years ago
Hi Murtaza, sorry for the delay! -- I was on leave for several weeks, and just noticed this.
I just want to check that you're running this on the real-time patch. Also, there are cases where communication constraints are violated depending on the controller logic you're using. cc @exhaustin for any insight on move_ee performance.
If you want to hop on a call to debug together, also happy to do that!
Sorry for overlooking this github issue.
I think it is highly likely that you are being limited by your hardware. According to my experience Intel i5 @ 2.2GHz would struggle to maintain the real time communication loop. This was tested two years ago on a different setup so it might not be the case for your particular setup.
A good way to check if your particular hardware system is capable is to install libfranka natively by following the official instructions, then running the provided communication test example.
We've managed to successfully control the Franka using Polymetis on any NUC equipped with an i7 CPU, so If you are getting packet drops, then I would advise switching to one of those.
We recently fixed several performance-related issues which could have been impacting you, in addition to upgrading PyTorch 1.10 -- feel free to try it out!
Please raise a new issue if you encounter performance issues after this upgrade. Thanks!
Hey - I'm running a NUC7 with i5 @ 2.2Ghz and seeing intermittent (every few seconds) communication constraint violation messages. Is this a known bad configuration? From the thread above it wasn't clear if the issue was solved by the perf updates in December or if older NUCs with i5s are too slow. I'm running 5.9.1-rt20 on Ubuntu 20.04.3. This NUC was stable running the ROS/frankalib stack on an older (5.4 series) rt kernel.
I have experience with i5 @ 2.2Ghz being underperformant with libfranka indepedent of Polymetis, but my experiences are limited to a few machines so I wouldn't say with certainty that the configuration is bad although it likely is.
Something you should do (on older i5 NUCs before deeming it too slow) is to disable CPU scaling and running the communication test to see if results are better. (Note that the libfranka communication test example is now included with the conda installation of Polymetis -- you no longer need to build libfranka to access it.)
Update relevant to this issue: A new version of Polymetis is now available which fixes the annoying issue of triggering "communication_constraints_violation" at times when sending a trajectory-based controller.
For local builds, simply pull from latest main and rebuild.
For conda installations: conda update -c pytorch -c fair-robotics -c aihabitat -c conda-forge polymetis
I'm having this same issue, but I can't pull the most recent version because it requires the most up to date lib Franka software, which would be a pain for me to install. is there another way I can address my issue?
@AlexanderKhazatsky Consider building from source & checking out your version of libfranka, as described in the docs
When I tried this last week, it didnt work because the build procedure assumed a certain lib Franka version, has this been addressed?
Also, I'm encountering these issues with the recommended NUC model.
On the main branch, please checkout the version of libfranka you require, as described in the docs linked above.
Discussions regarding building with alternative libfranka versions are continued at #1191
Type of Issue
Select the type of issue:
Description
Unsure if this is actually a bug or just a hardware issue but I find that polymetis ends up dropping a significant number of commanded actions due to packet failure. This is the error I get on my NUC (when running random end-effector control actions using the polymetis API):
Is this to be expected? I am finding that a significant number of actions are dropped and I've had to include retrying on failure in my code to prevent this sort of behavior, but that seems to be a hack at best. My code when getting this behavior:
My NUC has the following specs (in case its an issue with too weak of a CPU):
My question is primarily: given my hardware is this behavior expected and I should buy a better NUC (if so what specs are recommended - this would be great to add to Documentation!) and if not, then any idea if there is a bug?