added in deadband on startup for uam driver#44
Open
osullivan-locus wants to merge 1 commit intolocus-develfrom
Open
added in deadband on startup for uam driver#44osullivan-locus wants to merge 1 commit intolocus-develfrom
osullivan-locus wants to merge 1 commit intolocus-develfrom
Conversation
osullivan-locus
changed the title
osullivan-locus
force-pushed
the
RST-15267-another-bad-data-prevention-measure
branch
from
a3e6a0b to
3cf1f43
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
prior context: #42
The previous commit ended up fixing only 1 of 2 issues. This was enough to reduce the issue incidence rate such that I thought it was a full fix. After noticing the lidar still, occasionally, produced bad data on startup I did a deep dive into the Hokuyo lidars.
I wrote a script to decipher the lidar's network traffic to see if the issue was in the lidar firmware or the driver (spoilers, it's the driver).
Nominal boot (reconstructed from tcp packets)
Here we see the encoder count for the lidar start right off at a normal value in the first data packet sent
And we see reasonable values for the minimum reported distance (probably some part of the robot in this case).
Faulty boot (reconstructed from tcp packets)
But on the faulty boot, we see the encoder count start off as zero for a while
And the minimum reported distance (and reported distances in general) are all over the place until settling back down.
Encoder count and the distances seem to be the only fields with this transient behavior. Luckily nothing on the driver end of things uses the encoder count.
Fix
Unfortunately there is no indicator in the network packets as to when the distances will sort themselves out, so the best option is just to use a timer and throw away the first few packets from a boot/reboot.
There is an over-lap between this fix (removes orange) and the previous PR (removes red). But I believe it is valuable to have both methods active. The previous PR specifically protects us from the fully null scans, while this PR just cuts off all of the beginning data.
I have not observed this behavior on another bot yet, so I plan on keeping the default behavior off and just enabling it for this bot in FA for now.