osvr::vbtracker::SCAATKalmanPoseEstimator Class Reference

Public Types
enum	TriBool { False, True, Unknown }
enum	TrackingHealth { Functioning, NeedsHardResetNow, SoftResetWhenBeaconsSeen }

Public Member Functions
	SCAATKalmanPoseEstimator (ConfigParams const &params)
bool	operator() (EstimatorInOutParams const &p, LedPtrList const &leds, osvr::util::time::TimeValue const &frameTime, double videoDt)
LedPtrList	filterLeds (LedPtrList const &leds, const bool skipBright, const bool skipAll, std::size_t &numBad, EstimatorInOutParams const &p)
	Given a list of LED pointers, filters them out according to configured parameters, updates the debug data, and returns a list of just those LEDs to process. More...
void	resetCounters ()
TrackingHealth	getTrackingHealth ()
	Determines whether the Kalman filter is in good working condition, should fall back to RANSAC immediately, or should fall back next time beacons are detected. More...

Member Function Documentation

filterLeds()

LedPtrList osvr::vbtracker::SCAATKalmanPoseEstimator::filterLeds	(	LedPtrList const &	leds,
		const bool	skipBright,
		const bool	skipAll,
		std::size_t &	numBad,
		EstimatorInOutParams const &	p
	)

Given a list of LED pointers, filters them out according to configured parameters, updates the debug data, and returns a list of just those LEDs to process.

Todo:

should we be recalculating this for each beacon after each correction step? The order we filter them in is rather arbitrary...

Todo:

use this for more speed?

This means the LED is pointed away from us - so we shouldn't be able to see it.

Todo:

This could be a mis-identification, or it could mean we're in a totally messed up state. Do we count this against ourselves?

LED is too askew of the camera to provide reliable data, so skip it.

getTrackingHealth()

SCAATKalmanPoseEstimator::TrackingHealth osvr::vbtracker::SCAATKalmanPoseEstimator::getTrackingHealth

(

)

Determines whether the Kalman filter is in good working condition, should fall back to RANSAC immediately, or should fall back next time beacons are detected.

When the algorithm switches back to Kalman, be sure to call resetCounters()

Additional case: We've been a while without blobs...

Otherwise, we're doing OK!

operator()()

bool osvr::vbtracker::SCAATKalmanPoseEstimator::operator()	(	EstimatorInOutParams const &	p,
		LedPtrList const &	leds,
		osvr::util::time::TimeValue const &	frameTime,
		double	videoDt
	)

Count up types of beacons

Decisions based on the counts.

Predict first if appropriate.

If we have no good LEDs, let's attenuate the linear velocity quickly: avoid coasting/gliding.

Shuffle the order of the good LEDS

Stick a little bit of process model uncertainty in the beacon, if it's meant to have some

subtracting from image size to flip signs of x and y, aka 180 degree rotation about z axis.

Investigate measurement variance here (difference in measurement space from expected measurement based on the model) to decide if

• it's a reasonable measurement
• it's a little unreasonable (and should get some extra variance to indicate we think it's a poor-quality measurement)
• it's totally unreasonable and should be de-identified and skipped (because we've probably mis-identified something in the environment as a beacon)

Have to still count it as bad, in case it's our model, not the beacon, that's actually bad.

That was the last place we'd reject an LED, so now we can say for sure we're using this one.

Typically, all of these will be 1 except for the variance from beacon depth. At some distance past 55cm, bright LEDs actually have lower than average variances instead of higher, but the overall mean variance follows an exponential decay trend with distance.

Now, do the correction.

Probation: Dealing with ratios of bad to good residuals

Frames without measurements: dealing with getting in a bad state

We had a measurement, we rejected it. The problem may be the plank in our own eye, not the speck in our beacon's eye.

We're on the wrong side of the camera #fail This is a fix-up after the fact, rather than a prevention: if we get here, we goofed up earlier - but better late than never.

---

The documentation for this class was generated from the following files:

• plugins/unifiedvideoinertialtracker/PoseEstimator_SCAATKalman.h
• plugins/unifiedvideoinertialtracker/PoseEstimator_SCAATKalman.cpp