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

Question regarding controller computation time #159

Open
StephanSchwarz96 opened this issue Aug 8, 2024 · 1 comment
Open

Question regarding controller computation time #159

StephanSchwarz96 opened this issue Aug 8, 2024 · 1 comment

Comments

@StephanSchwarz96
Copy link

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
Copy link
Contributor

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

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

No branches or pull requests

2 participants