- Member addAlias
signify invalid route in some other way?
signify not to pass relative paths here in some other way?
signify not to pass relative paths here in some other way?
- Member cget
- figure out why MSVC can't perform overload resolution with a non-const argument if this is named
get
- Module Child factories
eventually fix: Right now assumes that there is only one IMU per body
assumes the IMU is at the origin of the body (most important for velocity)
- File ContextC.h
- Apply annotation macros
- Member csvtools::StringField::loadIntoStringStream (std::istringstream &iss) const
- might be able to do stuff with streambuf::sputn to make this more efficient, but...
- Member directx_samplegrabber_callback::shutdown ()
- this is an awfully crude and hacky way of ensuring the callback has finished.
- Member DOTGraphOutput::addEdge (NodeInterface &tail, NodeInterface &head, std::string const &type, std::string const &data=std::string())
- not including
- Member getSerialPortStateImpl (std::string const &port)
- just assuming it's available on platforms where we don't know how to check.
- File JSONTransformVisitor.cpp
- Replace the utility functions in here with osvr/Common/JSONEigen
- Member main (int argc, char *argv[])
- add usage
- page Main Page
` in code
` in code
- Be able to operate in IMU-only mode (as VideoIMUFusion did), essentially just passing through the IMU data.
- Multiple optical targets per body.
- Figure out why room calibration sometimes (seemingly randomly) is a rather prolonged struggle. (Seems to be better since changing to use more RANSAC iterations, converting the OpenCV poses to Eigen poses differently, and thus doing the pinhole flip differently, but it's again, seemingly randomly...)
- Slide-joint target (the rear target of the HDK) - modeling a target with one linear (or one linear and one rotational) degree of freedom from the body.
- Update IMU code to have IMU hold a yaw drift state variable that is autocalibrated (like the beacon positions are)
- Multi-camera tracking.
- Modeling: IMU and "neck model", etc - IMU is not co-located with the origin of the body's coordinate system - how to deal? (Transform the state/error before and then transform it back?)
- Be able to allocate sets of patterns to devices for third-party devices to use.
- goal is to avoid having to have fixed allocations of the limited pattern space: just let the plugin at runtime hand out patterns as long as you give it constraints. Important constraint that was missed earlier: adjacency - don't want two adjacent beacons bright at the same time or you get the effect seen on the left side of the HDK 1.3.
- Member Main::Main ()
- Come up with actual estimates for camera and distortion parameters by calibrating them in OpenCV.
- Namespace osvr
can we split out this include? I don't think all consumers of this header need it.
try this out - it does build, and I think it makes logical sense as well.
This is a workaround for Clang and Boost pre-1.50, to fix a build error caused by a syntax error in Boost.Containers allocator traits.
warning - cross-library internal header!
- Member osvr::client::AnalogRemoteFactory::operator() (common::OriginalSource const &source, common::InterfaceList &ifaces, common::ClientContext &ctx)
- find out why make_shared causes a crash here
- Member osvr::client::ButtonRemoteFactory::operator() (common::OriginalSource const &source, common::InterfaceList &ifaces, common::ClientContext &ctx)
- find out why make_shared causes a crash here
- Member osvr::client::DirectionRemoteFactory::operator() (common::OriginalSource const &source, common::InterfaceList &ifaces, common::ClientContext &ctx)
- find out why make_shared causes a crash here
- Member osvr::client::DisplayConfig::getViewerEyeSurface (OSVR_ViewerCount viewer, OSVR_EyeCount eye, OSVR_SurfaceCount surface)
- right now only a single surface per viewer eye
- Member osvr::client::DisplayConfig::getViewerEyeSurface (OSVR_ViewerCount viewer, OSVR_EyeCount eye, OSVR_SurfaceCount surface) const
- right now only a single surface per viewer eye
- Member osvr::client::EyeTrackerRemoteFactory::operator() (common::OriginalSource const &source, common::InterfaceList &ifaces, common::ClientContext &ctx)
need to append sensor number here!
need to append sensor number here!
need to append sensor number here!
need to append sensor number here!
we actually should be using it on direction and origin
- Member osvr::client::EyeTrackerRemoteHandler::~EyeTrackerRemoteHandler ()
- do we need to unregister?
- Member osvr::client::ImagingRemoteFactory::operator() (common::OriginalSource const &source, common::InterfaceList &ifaces, common::ClientContext &ctx)
- find out why make_shared causes a crash here
- Member osvr::client::ImagingRemoteHandler::~ImagingRemoteHandler ()
- do we need to unregister?
- Member osvr::client::Location2DRemoteFactory::operator() (common::OriginalSource const &source, common::InterfaceList &ifaces, common::ClientContext &ctx)
- find out why make_shared causes a crash here
- Member osvr::client::LocomotionRemoteFactory::operator() (common::OriginalSource const &source, common::InterfaceList &ifaces, common::ClientContext &ctx)
may need a transformation here for 2D vector
find out why make_shared causes a crash here
- Member osvr::client::LocomotionRemoteHandler::~LocomotionRemoteHandler ()
- do we need to unregister?
- Member osvr::client::NetworkDirectionRemoteHandler::~NetworkDirectionRemoteHandler ()
- do we need to unregister?
- Member osvr::client::NetworkLocation2DRemoteHandler::~NetworkLocation2DRemoteHandler ()
- do we need to unregister?
- Member osvr::client::RemoteHandlerInternals::forEachInterface (F &&f)
- is this needed? it increments a shared_ptr reference count which is expensive.
- Member osvr::client::TrackerRemoteFactory::operator() (common::OriginalSource const &source, common::InterfaceList &ifaces, common::ClientContext &ctx)
right now always reporting pose if we report either position or orientation as a backward-compatibility move, since we did so before, at least until we have a report like pose with validity bools in it.
find out why make_shared causes a crash here
- Member osvr::common::addAliasFromSourceAndRelativeDest (PathNode &node, std::string const &source, std::string const &dest, AliasPriority priority=ALIASPRIORITY_MANUAL)
- signify invalid route in some other way?
- Member osvr::common::addDevice (PathTree &tree, std::string const &deviceName, elements::DeviceElement dev=elements::DeviceElement())
remove added node here?
What about intermediate paths between a plugin and a device? (device types, for instance) We leave them null for now.
What about intermediate paths between a plugin and a device? (device types, for instance) We leave them null for now.
What about intermediate paths between a plugin and a device? (device types, for instance) We leave them null for now.
- Member osvr::common::appendCurrentIface (Json::Value &augInterface, Json::Value &currInterface)
- mergeIdenticalInterfaces(currInterface, augInterface, detail)
- Class osvr::common::CallbackStorage
- can't use quote because of bad interaction with MSVC 2013 that causes types to get mixed up - only the first quote works.
- Member osvr::common::elements::AliasElement::setSource (std::string const &source)
support relative paths - either here or at a different level
validation?
- Member osvr::common::getPathFromOldRouteSource (Json::Value obj)
- remove this method in the future.
- Member osvr::common::getTrackerSensorInfo (OriginalSource const &source)
- Apply modifications based on transforms. translation causes report of position in orientation trackers, etc.
- Member osvr::common::InterfaceState::getState (util::time::TimeValue ×tamp, traits::StateFromReport_t< ReportType > &state) const
- do we fail silently or throw exception if we are asked for state we don't have?
- Member osvr::common::mergeIdenticalInterfaces (Json::Value &existingIface, Json::Value &newIface, std::string const &detail)
- when appending interfaces you might encounter that there are independent interfaces that are same as subinterfaces for example, eyetracker device and tracker device plugin eyetracker breaks down into 4 interfaces including tracker so to avoid replacing tracker data, we need to safely merge them
- Member osvr::common::messages::VRPNPing::identifier ()
- add test to verify that this matches VRPN: message type string not accessible as a constant, so we have to extract the message ID instead.
- Member osvr::common::messages::VRPNPong::identifier ()
- add test to verify that this matches VRPN: message type string not accessible as a constant, so we have to extract the message ID instead.
- Member osvr::common::normalizeDeviceDescriptor (std::string const &jsonDescriptor)
process for tracker interface
for tracker
for future interfaces
for tracker
for future interfaces
for tracker
for future interfaces
- Member osvr::common::processDeviceDescriptorForPathTree (PathTree &tree, std::string const &deviceName, std::string const &jsonDescriptor, int listenPort, std::string const &host)
warn about failed descriptor parse?
no change in descriptor so no processing?
no change in descriptor so no processing?
no change in descriptor so no processing?
- Class osvr::common::RawMessageType
- add test code to ensure that the default value matches vrpn_ANY_TYPE as found in vrpn_Connection.h
- Class osvr::common::RawSenderType
- add test code to ensure that the default value matches vrpn_ANY_SENDER as found in vrpn_Connection.h
- Member osvr::common::RegisteredStringMap::getStringFromId (util::StringID id) const
- should we throw here?
- Member osvr::common::serialize (BufferType &buf, MessageClass &msg)
- add another functor to first compute message length and reserve buffer space?
- Member osvr::common::TreeResolutionVisitor::operator() (elements::AliasElement const &elt)
- update the element with the normalized source?
- Member osvr::connection::ConnectionDevice::setDeviceDescriptor (std::string const &jsonString)
- validate descriptor here
- Class osvr::connection::RequestToSend
- allow timeout on RTS
enum RequestResults { RR_CTS_GRANTED, RR_DENIED, RR_TIMED_OUT };
- Member osvr::connection::vrpn_BaseFlexServer::mainloop ()
- service device here? Some device parts end up being serviced in this object's owner, the VrpnConnectionDevice.
- Member osvr::connection::VrpnBasedConnection::~VrpnBasedConnection ()
- wait until all async threads are done
- Member osvr::kalman::CorrectionInProgress< StateType, MeasurementType >::denom
- Figure out if this is the best decomp to use
- Member osvr::kalman::orient_externalized_rotation::State::getCombinedQuaternion () const
- is just quat multiplication OK here? Order right?
- Member osvr::kalman::pose_externalized_rotation::State::getCombinedQuaternion () const
- is just quat multiplication OK here? Order right?
- Member osvr::kalman::predictErrorCovariance (StateType const &state, ProcessModelType &processModel, double dt)
- Determine if the fact that Q is (at least in one case) symmetrical implies anything else useful performance-wise here or later in the data flow.
- Member osvr::pluginhost::findPlugin (SearchPath const &searchPaths, const std::string &pluginName)
- does this mean symlinks get excluded?
- Member osvr::pluginhost::getPluginSearchPath ()
- add user's home directory to search path
- Member osvr::pluginhost::PluginRegPtr
- why did unique_ptr not work here?
- Member osvr::pluginkit::detail::UpdateTrampoline< DeviceObjectType >::update (void *userData)
- catch exceptions here?
- Member osvr::server::ConfigureServer::constructServer ()
- Detect/report invalid or contradictory options here.
- Member osvr::server::ConfigureServer::processDisplay ()
- don't style this string!
- Member osvr::server::ConfigureServer::processRenderManagerParameters ()
- don't style this string!
- Member osvr::server::resolvePossibleRefWithDetails (Json::Value const &input, bool stringAcceptableResult, std::vector< std::string > const &searchPath)
- remove things after the filename in the ref.
- Class osvr::typepack::quote< C >
- doesn't work if used more than once in a single translation unit on MSVC2013?
- Member osvr::util::createProjectionMatrix (Rectd const &bounds, double near, double far)
- Look into using Eigen::Projective3d?
- Member osvr::util::DefaultOSVRPort
- Update this for 1.0!
- Member osvr::util::detail::CSVRowProxy< Derived >::~CSVRowProxy ()
- Does it make sense to skip finalizing if we haven't had any data added? Think so...
- Member osvr::util::ei_quat_exp_map::QuatExpMapBase< Derived_ >::avoidSingularities () const
- assert Derived::AlwaysPureVec || derived().pureVec()
- Member osvr::util::ei_quat_exp_map::QuatWrapper< Scalar_ >::pureVec () const
- floating point equality comparisons are bad
- Member osvr::util::functor_trampolines::detail::ComputeGenericCaller< FunctionPtr, FunctionObjectType, ThisLocation >::Arity
- static assert that the argument lists are compatible
- Member osvr::util::log::Logger::makeWithSinks (std::string const &name, spdlog::sinks_init_list sinks)
- should we be making a fallback logger here, just hoping spdlog will deal with a bad sink pointer without issue, or filtering the init list to a non-nullptr vector?
- Member osvr::util::log::LogRegistry::getOrCreateLogger (const std::string &logger_name)
- should this level be different than other levels?
- Member osvr::util::log::LogRegistry::setConsoleLevel (LogLevel severity)
- Does it make sense that we must adjust overall level as well in this case?
- Member osvr::util::log::LogRegistry::setLevel (LogLevel severity)
- right now this means the filtering is a harmless no-op
- Member osvr::util::time::TimeValueClock::is_steady
- is this true?
- Class osvr::util::tree::TreeNode< ValueType >
- methods to remove a child (by pointer and by name)
- Member osvr::util::tree::TreeNode< ValueType >::visitChildren (F &visitor) const
- does this overload clutter the interface and reduce clarity between const and non-const visitors?
- Member osvr::vbtracker::AssignMeasurementsToLeds::resumbitMeasurement (LedMeasurement const &meas)
- do we throw a logic error here?
- Class osvr::vbtracker::BeaconData
- refactor? ported directly
- Member osvr::vbtracker::ConfigParams::ConfigParams ()
this is just a guess of how high my camera is.
this is just an estimate of how to not break most apps.
- Member osvr::vbtracker::detail::OptionalStream::operator<< (T &&rhs)
- figure out how to deal with std::endl and friends, who are overloaded functions...
- Member osvr::vbtracker::history::detail::HistorySubsetRange< ValueType >::HistorySubsetRange (iterator begin_, iterator end_)
- consistency checks on the iterators...
- Member osvr::vbtracker::history::HistoryContainer< ValueType, AllowDuplicateTimes_ >::pop_before (timestamp_type const &tv)
- is this right?
- Member osvr::vbtracker::ImagePointMeasurement::getCovariance (State &state) const
make this better, perhaps state dependent?
make this better, perhaps state dependent?
- Member osvr::vbtracker::Led::addMeasurement (LedMeasurement const &meas, bool blobsKeepId)
Identify "theft" is possible and takes place - right now it's handled just the same as any other change in ID.
it seems like LEDs are re-recognized every frame? so presumably it's possible that oldId != m_id without one being a sentinel.
- Class osvr::vbtracker::LedIdentifier
Consider adding a distance estimator as a parameter throughout, which can be left alone for unknown or estimated based on a Kalman filter; it would be used to scale the expected brightness.
Consider adding a distance estimator as a parameter throughout, which can be left alone for unknown or estimated based on a Kalman filter; it would be used to scale the expected brightness.
- Member osvr::vbtracker::RANSACPoseEstimator::operator() (CameraParameters const &camParams, LedPtrList const &leds, BeaconStateVec const &beacons, std::vector< BeaconData > &beaconDebug, Eigen::Vector3d &outXlate, Eigen::Quaterniond &outQuat, int skipBrightsCutoff=-1, std::size_t iterations=5)
- find out why OpenCV is now returning these values sometimes
- Member osvr::vbtracker::RANSACPoseEstimator::operator() (EstimatorInOutParams const &p, LedPtrList const &leds)
- Copy the existing angular velocity error covariance
- Member osvr::vbtracker::SCAATKalmanPoseEstimator::filterLeds (LedPtrList const &leds, const bool skipBright, const bool skipAll, std::size_t &numBad, EstimatorInOutParams const &p)
should we be recalculating this for each beacon after each correction step? The order we filter them in is rather arbitrary...
use this for more speed?
This could be a mis-identification, or it could mean we're in a totally messed up state. Do we count this against ourselves?
- Member osvr::vbtracker::TrackedBody::createTarget (Eigen::Vector3d const &targetToBody, TargetSetupData const &setupData)
eventually fix: Right now assumes that there is only one target per body
handle multiple targets!
handle multiple targets!
- Member osvr::vbtracker::TrackedBody::getParams () const
- refactor
- Member osvr::vbtracker::TrackedBody::getState ()
- Note that this is stored in camera space!
- Member osvr::vbtracker::TrackedBody::getStateAtOrBefore (osvr::util::time::TimeValue const &desiredTime, osvr::util::time::TimeValue &outTime, BodyState &outState)
- should this block others from trying to submit updates for times between outTime and desiredTime?
- Member osvr::vbtracker::TrackedBody::hasPoseEstimate () const
- handle IMU here.
- Member osvr::vbtracker::TrackedBody::incorporateNewMeasurementFromIMU (util::time::TimeValue const &tv, CannedIMUMeasurement const &meas)
- handle this better
- Member osvr::vbtracker::TrackedBody::replaceStateSnapshot (osvr::util::time::TimeValue const &origTime, osvr::util::time::TimeValue const &newTime, BodyState const &newState)
- number popped should be the same (or very nearly) as the number of IMU measurements we replay - except at startup.
- Member osvr::vbtracker::TrackedBodyTarget::updatePoseEstimateFromLeds (CameraParameters const &camParams, osvr::util::time::TimeValue const &tv, BodyState &bodyState, osvr::util::time::TimeValue const &startingTime, bool validStateAndTime)
make this state correction less hacky.
move state machine logic elsewhere?
- Member osvr::vbtracker::TrackingDebugDisplay::triggerDisplay (TrackingSystem &tracking, TrackingSystem::Impl const &impl)
- TEMPORARY DEBUGGING CODE - REMOVE!
- Member osvr::vbtracker::TrackingSystem::getParams () const
- refactor;
- Member osvr::vbtracker::TrackingSystem::isRoomCalibrationComplete ()
- should just be able to do this by checking the state of the calibrator.
- Member osvr::vbtracker::TrackingSystem::setUseIMU (bool useIMU)
- just for debugging
- Member OSVR_EDGEHOLE_UMAT
Disabled for now because in one testing/timing run with ETW, measured to increase average blob extraction time from 2.17ms to 2.53ms...
Can't enable this even though we now have a persistent thread, because we don't have a timing guarantee on the operations and it may actually be slower (as it was in initial testing for me on an Intel Core i7-4600)
- Member OSVR_USE_POSIX_SIGNAL_SHUTDOWN_HANDLER
- the world isn't just Win32 and POSIX signal()
- Member OSVR_UVBI_ASSUME_CAMERA_ALWAYS_SLOWER
- Remove when we no longer assume that IMU reports arrive before video reports with same timestamps.
- Member OSVR_UVBI_ASSUME_SINGLE_CAMERA
- Remove when we no longer assume a single camera or monotonic camera timestamps, and the build will break in a few places where known "gotchas" exist
- Member OSVR_UVBI_ASSUME_SINGLE_IMU
- Remove when we no longer assume a single IMU in the whole system.
- Member OSVR_UVBI_ASSUME_SINGLE_TARGET_PER_BODY
- Remove when we no longer assume a single optical target per body.
- Member OSVR_VALIDATE_OUTPUT_PTR (X, DESC)
- move this into a shared header between here and ClientKit/DisplayC.cpp
- Member OSVR_VALIDATE_SURFACE_ID
- actually check the config for number of surfaces
- Member OSVR_VALIDATE_VIEWER_ID
make these an "always" check? instead of an assert
actually check the config for number of viewers (viewer < disp->cfg->size())
- Member osvrAnalysisSyncInit (OSVR_PluginRegContext ctx, const char *name, OSVR_DeviceInitOptions options, OSVR_DeviceToken *device, OSVR_ClientContext *clientCtx)
- Use an interface factory that handles relative paths.
- Member osvrClientGetDisplay (OSVR_ClientContext ctx, OSVR_DisplayConfig *disp)
Decide if relative viewport should be constant in a display config, and update docs accordingly.
Decide if distortion params should be constant in a display config, and update docs accordingly.
Decide if distortion params should be constant in a display config, and update docs accordingly.
- Module PluginKitEyeTracker
- Handle creating an EyeTracker on the same device as separate button, tracker, direction, and 2D location interfaces.
- File PoseStateExponentialMap.h
- incomplete
- Member VideoIMUFusion::handleIMUVelocity (const OSVR_TimeValue ×tamp, const Eigen::Vector3d &angVel)
- Do we need a factor of 0.5 to turn angular velocity vector into quaternion derivative?