Page 1 of 1

feedback frequency and getNextFeedback

Posted: Fri May 27, 2022 4:53 am
by husch
According to the document (https://docs.hebi.us/tools.html#cpp-feedback, https://docs.hebi.us/tools.html#get-next-feedback-2) and example,
group->setFeedbackFrequencyHz(F1);

// loop frequency F2
while (!stop_loop)
{
if (!group->getNextFeedback(&feedback))
continue;
// ... read/use feedback object contents here.
}
we set feedback frequency for a background thread on host computer to collect feedbacks from actuators. We call getNextFeedback to get the next new (not previously accessed) synchronized feedback.

If F2 is faster than F1, the getNextFeedback call blocks, according to the document.
What happens if F1 is faster than F2? Will the feedbacks be pushed in a buffer? If so, what is its size? Does getNextFeedback return the latest state (feedback) or the old state?

Thank you very much.

Re: feedback frequency and getNextFeedback

Posted: Fri May 27, 2022 7:38 am
by florian_enner
getNextFeedback always returns the latest state or blocks until a new state is available. If F2 is slower than F1, it will end up skipping some measurements rather than adding lag by buffering.

The only exception to this are offline log-groups where getNextFeedback always advances by one.

Re: feedback frequency and getNextFeedback

Posted: Fri May 27, 2022 9:09 am
by husch
Cool, that is perfect! Thanks a lot :)

Re: feedback frequency and getNextFeedback

Posted: Wed Jun 15, 2022 4:04 am
by husch
A few more questions :mrgreen:

So we have two loops in two threads,
- background thread on host computer to collect feedbacks from actuators, runs @ F1
- main thread where getNextFeedback is called, runs @ F2.
When F2 is faster than F1, main thread blocks until there is a new status collected by background thread.

(1)
Do these two threads (processes) run in parallel? Or do they run in a time sharing manner on a single process, concurrently?
More information will be useful :) to predict the behaviour.

(2)
How does background thread work with UDP packages and network layers?
Could you please describe what happens when feedback UDP packages arrive at the host computer?

(3)
If there are n actuators and we only receive (n-1) states, is the main thread going to block?

(4)
What is your advice on setting the optimal F1 and F2. Do you run some benchmarks to determine the optimal F1 and F2?

Thanks a lot.

Re: feedback frequency and getNextFeedback

Posted: Tue Jun 21, 2022 4:13 am
by husch
Any update for the questions in the previous post, please?
Thank you very much :D

Re: feedback frequency and getNextFeedback

Posted: Fri Jul 01, 2022 3:32 pm
by florian_enner
Sorry for the late response. For some reason we didn't see a notification about it.

1) Both F1 and F2 run concurrently in separate OS threads

2) Workflow:
a) F1 sends messages requesting feedback. This also increments the sequence number and sets the "pc transmit" timestamp. Afterwards, F1 goes to sleep for the specified period.
b) The receiving thread "F3" blocks on the udp socket for feedback responses
c) Each incoming feedback updates the corresponding index. This also sets the "pc receive" timestamp and the receive-sequence number.
d) After receiving at least one feedback message from every actuator, the messages get packaged together and are made available as "new feedback"

3) No, it will exit after hitting a timeout. Some APIs have a settable timeout limit and/or a non-blocking API for cases where missing packets is common (e.g. mobile phones on WiFi)

4) We found that a 100Hz feedback rate works well for most applications. Some use cases like impedance control benefit from higher rates (~200-500Hz)

I hope this answers your questions. Let me know whether we can help with anything else. If for some reason it takes 2+ days to respond, please feel free to also send an email on our support address.

Re: feedback frequency and getNextFeedback

Posted: Wed Jul 06, 2022 2:39 pm
by husch
Ah yes! I forgot about feedback timeout!
Thanks a lot. That answers all of my questions. :mrgreen: