search

OSVR / OSVR-General

Catch-all project for issues and information not specific to a single repo
10 stars 7 forks source link

OSVR HDK: Access to Raw IMU data and firmware source code #11

Closed ChristophHaag closed 6 years ago

ChristophHaag commented 7 years ago

When OpenHMD added support for the HDK IMU they were not happy that the HDK2 only provides a Quaternion and no raw sensor data access. And then it's a Quaternion in an absolute position in regards to gravity, so you have to always add a 90° rotation around the X axis, and then you're still not done, you need to switch around a couple of axes and negate some of them.

All (?) other HMDs just provide sensor data and that is what OpenHMD would prefer for the HDK too. Can the firmware be updated to provide this data?

The second issue is closely related: All of this is controlled by closed source firmware. In a true "Hacker Development Kit" the firmware should be open, so that the users can implement behavior like this themselves. It would be nice to have at least a rough ETA when we can expect open firmware for the HDK.

ChristophHaag commented 7 years ago

Just saw older request for the firmware in https://github.com/OSVR/OSVR-HDK/issues/2

Is there a reason it takes so long?

rpavlik commented 6 years ago

Mis-communications and a legacy codebase with vendor-supplied code from vendors who default to closed and confidential would be why it took so long. Presumably too little too late, but it is open now.

Nothing we can do to get the raw IMU sensor data, though. The fusion takes place inside the BNO070 chip, all the main MCU does is configure it and relay the data.

(FWIW, there are lots of trackers like this - sensor fusion is a very in-depth field, and also very diverse in the inputs. Plus, if you consider e.g. mo-cap style optical trackers, or magnetic trackers, or... there's not really a useful way to get "raw data" in a way that a third-party system would be able to work with to convert to poses. Even if you want to provide optional sensor fusion for sensors that don't do it themselves or that can do it but do it badly, it's important to have your base tracker interface expose fully-fused pose and its derivatives.)