search

frankaemika / libfranka

C++ library for Franka research robots
https://frankaemika.github.io
Apache License 2.0
242 stars 157 forks source link

Question regarding controller computation time #159

Closed StephanSchwarz96 closed 1 week ago

StephanSchwarz96 commented 3 months ago

Hello everyone,

I am currently implementing a computational heavy controller in my panda and am reaching the time limits for the 1kHz frequency of the system.

I use a PREEMT RT kernel, adjusted the CPUs and also cleared several CPUs just for my process to avoid any rt conflicts. My network test gave me an average RTT of around 0.2ms with 0.3ms max. Not perfect but even after several attempts it did not went over 0.3.

To evaluate the performance, I made some tests using the communication_test script by adjusting the sleep time. The results are, that a sleep time of 0.3ms (resulting in an average comuptation time of 0.35) is the upper limit with already quite low communication_seccess_rates (between 0.8-0.9). Using a sleeptime of 0.35 results in a commincation error.

Assuming we lose 0.3ms for network, 0.35ms from my computation that leaves 0.35ms for the "Time needed by the robot to process your data and step the internal controller" as stated in the Franka Docs which sounds quite a lot to me.

Does anyone have some experience if this is about to be right or have ideas on how to improve this?

Thanks, Stephan

AndreasKuhner commented 1 month ago

Hi @StephanSchwarz96 , for a bit of in-depth view: The Panda user (now speaking specifically about this) has roughly 0.2 to 0.3ms time for receiving, processing and sending the robot command successfully back. Why? Whenever we do our internal cycle, we first check for a newly received robot command, process it and at the end of our cycle, we send our a new robot state. That means, a user has time while our cycle sleeps to do their bit. Sometimes, our internal cycle is a bit faster - so you get something closer to 0.3ms - and sometimes it needs a bit more, so you only have time closer to 0.2ms.

Now, for FR3 users, this changed a bit over the time and will improve even further. Some under-the-hood changes improve how resources are used and we work in upcoming image release even more on the robustness of the communication. So.. maybe worth to look into getting a FR3.... :)

Cheers, Andreas

AndreasKuhner commented 1 week ago

Hi @StephanSchwarz96 , did this help? Could you improve the situation?

StephanSchwarz96 commented 1 week ago

Hi @AndreasKuhner , thank you for the information! I managed to reduce the computation time of my loop down to under .2ms and now it works smoothly again.