Open ounsworth opened 7 years ago
I like it.
A related idea is data validation. For example, this is bad:
Robot.arcadeDrive(some_factor * ultrasound.getDistance(), gyro.getHeading() - camera.getTargetHeading() );
I made this up, but assuming the logic was correct, there are still problems because this code doesn't (can't) verify the values are good. The robot could careen wildly and you'd have no idea why. A better approach would be:
get ultrasound distance
run it through a filter
verify it looks reasonable
log it
now you can use it
Same for all other sensor values.
We could even do things like value interpolation. If we know the ultrasounds update every, say, 5 ticks (100 ms) and we timestamp every time the value changes, then we can figure out how old a value is, and use it differently. The simplest approach might be to only use a value when it is freshest, and ignore it if we see it again. A fancier solution would be to track the last 2 or 3 values and track the rate of change, and then we can guess/interpolate what an intermediate value could be when the data is 1 tick out of date, 2 ticks out of date, etc.
A great deliverable for this issue could be a wrapper class for, say, the ultrasonic sensors, that take these factors into account and provide a smoothed output, and/or additional data such as the age and confidence level of a distance reading.
One thing that has been a problem this year and we could look at in the fall as a research project is smoothing sensor reading so the robot doesn't freak out if there's one bad value. For example, imagine the ultrasound gives the following series of readings:
15.3, 15.4, 15.4, 138.2, 15.3, ...
We don't want the robot to freak out at the 138.2 and rocket backwards.
Some buzz words that we could google for ideas: