Resend the previous data to the NUC if no new data was received from the servos. #23
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Brief
Does not update the filtered data (e.g. present position) in the nanopb message if the filter-count is zero, i.e. if no new data was received from the servos.
This is a compromise before a proper filter is implemented.
Context
Some of the data received from the servos is averaged between transmissions to the NUC. This is a crude way of downsampling from a variable asynchronous polling rate to a consistent 100 Hz.
Originally, when no new data was received from the servos, the fields in the nanopb message would be set to zero. This would happen rarely for some servos when servo-targets were being sent to NUSense, e.g. during KeyboardWalk, and the Dynamixel bus had a lot of activity. How ever rare it was, it would nonetheless yield a spike in the data, as seen below.
If the nanopb fields are not assigned, then, they are kept to their previous filtered values instead of zero. As seen below, there are no spikes towards zero.