Add queue_size to the forward command controller

[saikishor]

This adds the queue_size to the forward command controller, so that setting a proper value you can avoid the commands sent from nonRT loop from being missed

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 84.91%. Comparing base (8b90d97) to head (cd95080).
⚠️ Report is 7 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #2204   +/-   ##
=======================================
  Coverage   84.90%   84.91%           
=======================================
  Files         153      153           
  Lines       14995    14997    +2     
  Branches     1290     1290           
=======================================
+ Hits        12732    12734    +2     
  Misses       1790     1790           
  Partials      473      473           

Flag	Coverage Δ
unittests	84.91% <100.00%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
...rd_command_controller/forward_controllers_base.hpp	100.00% <ø> (ø)
...mand_controller/src/forward_command_controller.cpp	62.50% <100.00%> (+2.50%)	⬆️
...ommand_controller/src/forward_controllers_base.cpp	82.45% <100.00%> (ø)
...src/multi_interface_forward_command_controller.cpp	62.50% <100.00%> (+2.50%)	⬆️

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Juliaj]

This adds the queue_size to the forward command controller, so that setting a proper value you can avoid the commands sent from nonRT loop from being missed

Thanks for this addition, the queue_size addition makes sense to avoid message loss at the DDS layer.

Is one of the intended use cases supporting action chunking (e.g. batched action sequences from a learned policy)? If so, one friction that I am seeing: FCC currently doesn't seem to have a way to consume a chunk as an ordered sequence at the intended execution cadence. To compensate for that, a policy node could:

• Publish the chunk as a single burst of N messages — all callbacks fire nearly simultaneously, each overwriting rt_command_, so only the last action in the chunk survives.
• Publish one action at a time, externally rate-limited to match execution cadence — technically works, but the policy node is now owning the timing, and the chunk semantics are effectively lost.
• ...

For action chunking to work correctly, more work may be needed. If the use case is in scope, happy to discuss more.

[saikishor]

This adds the queue_size to the forward command controller, so that setting a proper value you can avoid the commands sent from nonRT loop from being missed

Thanks for this addition, the queue_size addition makes sense to avoid message loss at the DDS layer.

Is one of the intended use cases supporting action chunking (e.g. batched action sequences from a learned policy)? If so, one friction that I am seeing: FCC currently doesn't seem to have a way to consume a chunk as an ordered sequence at the intended execution cadence. To compensate for that, a policy node could:

• Publish the chunk as a single burst of N messages — all callbacks fire nearly simultaneously, each overwriting rt_command_, so only the last action in the chunk survives.
• Publish one action at a time, externally rate-limited to match execution cadence — technically works, but the policy node is now owning the timing, and the chunk semantics are effectively lost.
• ...

For action chunking to work correctly, more work may be needed. If the use case is in scope, happy to discuss more.

@Juliaj the changes proposed in this PR has nothing to do with action chunking. That's completely different topic. It depends on the usecase, I have a usecase where every point of the Trajectory is important and I cannot miss it, and I can use this queue_size to obtain that

[Juliaj]

I have a usecase where every point of the Trajectory is important and I cannot miss it, and I can use this queue_size to obtain that

@saikishor thanks for clarifying. Just to make sure I understand, is the missing command issue caused by command bursts or a slower FCC update cycle? The fix reduces message loss at the DDS layer, but since rt_command_ is a single slot, only the last written value is guaranteed to execute.

I'm guessing you considered a LockFreeQueue on the RT side but decided not going there. If so, what were the thoughts?

[saikishor]

This is because with forwarded command controller maybe you are interested in all commands like me instead of only the latest value. The problem with using latest value is that it causes jerks.

[christophfroehlich]

release notes are missing. The SystemDefaultsQoS depends on the middleware, but what is default for fastrtps for example? keep_last(10)?

[saikishor]

but what is default for fastrtps for example? keep_last(10)?

No clue

[saikishor]

Self note: Change to add the RTBuffer to have more info stored and to not have losses between RT and nonRT loop

[christophfroehlich]

With the default value 1 of the newly introduced parameter, you just disable the queue actually?