GithubHelp home page GithubHelp logo

michael-betz / foculus_rift_tracker_stm32f3discovery Goto Github PK

View Code? Open in Web Editor NEW
62.0 27.0 28.0 13.76 MB

Firmware for the STM32F3DISCOVERY board to emulate an Oculus Rift compatible USB motion tracker

Assembly 3.22% C 95.15% Shell 0.03% C++ 0.81% HTML 0.75% Makefile 0.04%

foculus_rift_tracker_stm32f3discovery's Introduction

The "Foculus Rift" tracker

A USB HID device, sending Accelerometer, Gyroscope and Magnetometer data over USB in an Oculus Rift compatible format.

This project comes in useful, if you are building your own DIY Head Mounted Display. It solves the problem of finding a motion tracker. The firmware runs on the STM32F3DISCOVERY board and should be compatible with all Oculus Rift games.

Note

This project is not maintained anymore and is kept here for documentation purposes only. Feel free to fork and continue the development.

Development blog

More details about the reverse engineering can be found on the development blog.

Current Status

I have been testing the headtracker under Ubuntu 13.10 and Windows 7 with various demos intended for the Oculus Rift. It is very usable already and I guess its performance in timing and accuracy is on the same level as the Oculus Rift DK1 headtracker. However, as I don't have an original Rift to compare, I would appreciate your feedback on this.

There is however still an issue with slow drift. In the latest version this has been minimized by a short calibration routine for the gyroscope. Nonetheless, I found out, that the Oculus SDK sporadically disables the correction from the magnetometer for reasons which I do not yet understand. Further work on this might be necesarry.

Things to implement

  • Evaluate the flags, I still do not have a clue what they are used for
  • What is this mysterious 16 bit command field in the Oculus packets for?
  • FixMe: There is this strange synchronization issue, where featureReportData[] sometimes contains invalid data when evaluated in main()

Organization of the code

 main.c           main logic of the tracker,
                  handling and reformating the sensor data stream and packing it into 62 byte packets to be sent over USB,
                  Assign the coordinate system directions
                  keeping track of the configuration data structures which the libOVR might send and request
 peripherals.c    setup and request data from the 3 sensor chips over SPI and I2C
                  Handle the scaling and calibration factors, so the headtracker moves in the right way
                  Zero-level calibration routine for the gyroscope
                  Save calibration factors to flash
                  PWM-patterns for the 8 status LEDs
 usb_desc.c       USB - HID descriptors, which fool the PC into thinking that there is an Oculus RIft corrected
 usb_endp.c       STM USB driver endpoint1 callbacks, just sets some global flags to inform the main routine when there is new data
 usb_prop.c       Customization of the STM USB driver, so feature reports can be sent and received
                  received data is copied in the global array featureReportData[] and then processed by the main loop

Flashing the STM32F3DISCOVERY board

For Ubuntu 13:

  1. Install open-ocd, follow the steps here (only the ones related to open-ocd)

  2. Connect the STM32F3DISCOERY board to the PC on its USB ST-LINK connector

  3. In a terminal, run this:

sudo openocd -f /usr/local/share/openocd/scripts/board/stm32f3discovery.cfg -c init -c"reset halt" -c"flash erase_sector 0 0 127" -c"flash write_image stm32f3_HID_for_real.elf"

The firmware, which is contained in the stm32f3_HID_for_real.elf binary file, should be flashed. If everything goes well, you can connect the board on the USB USER connector and it should be recognized as: "Oculus VR, Inc. Tracker DK". That's it, mount the board on your HMD and start up the Oculus World Demo.

Calibration and change of orientation

To calibrate the Gyroscope for zero-offset (which reduces drift), place the STM board on a flat surface and push the blue "USER" button for less than 1 second. Make sure that the board absolutely does not move while the calibration is in progress. The data is permanently stored in FLASH memory and retained after power down.

To change the reported coordinate system and hence the orientation of the board, push the "USER" button for > 1 second. Then you will be able to select one out of 8 preconfigured orientation settings, indicated by the blinking LED. After pushing the "USER" button again for > 1 second, the setting is also permanently saved to FLASH memory.

One of the following orientations can be chosen at the moment:

-------------------------------------------------------
LED label     Orientation
-------------------------------------------------------
LD3  (Red)    LEDs toward user     USB down
LD4  (Blue)   LEDs toward user     USB right
LD5  (Orange) LEDs away from user  USB down
LD6  (Green)  LEDs away from user  USB up
LD7  (Green)  LEDs up              USB toward user
LD8  (Orange) LEDs up              USB away from user
LD9  (Blue)   LEDs up              USB to users right
LD10 (Red)    LEDs up              USB to user right
-------------------------------------------------------

Changelog

 09.03.2014:  Fixed bug in handleConfigPacketEvent() by adding break; statements (data rate was always 1 ms before)
 10.03.2014:  Changed wMaxPacketSize from 62 to 64
 19.03.2014:  Changed I2C Bus speed to 400 kHz, which allows to read all 3 sensors in 0.65 ms  (before it was > 2 ms)
 20.03.2014:  Now evaluating the "new data ready" pins of all 3 sensors (improves timing a lot, reduces jitter)
              Enabled FIFO in Streaming mode of Accelerometer and Gyro (no samples will be lost!)
              Fixed Glitches in Magnetometer output by setting it to 75 Hz measurement rate (was 220 Hz before)
 23.03.2014:  Fixed a problem with the USB interrupt and atomic access, not allowing the tracker to change sensor scale
              Changed sensor scaling to floating point numbers and scaled to values as expected from the SDK
 29.03.2014:  Added gyroscope "set to zero" calibration routine (Press the user button on the STM board and keep it very still)
              Added temperature readout from gyro
              Added some nice LED animations for IDLE mode, Tracker running mode and Calibration mode
 01.04.2014:  Gyro offset calibration is now saved to Flash at address 0x08006000 and hence retained after power off
 08.05.2014:  Fixed bug in readSensorAcc(): an array was accessed outside its boundaries.
              also included the .hex file and switched on compiler optimizations
 11.05.2014:  Experimental: Setting of board orientation ...
              Push the user button for > 1 s to choose between 8 preconfigured orientation settings
              Push the user button again for > 1 s to save the setting to FLASH memory

foculus_rift_tracker_stm32f3discovery's People

Contributors

michael-betz avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

foculus_rift_tracker_stm32f3discovery's Issues

Calibration perculiar on Linux

Partly discussed in issue1, reported here for clarity.

Using the code from this repo:
https://github.com/jherico/OculusSDK

The amount of turn (gyro) seems to be able half of that expected. I tried with the 'stable' and '0.3-preview' (the only ones which would compile). The same hardware works on a Windows machine running the official download.

Will continue to investigate.

Windows ST-Link can't use pre-built ELF

The pre-built elf (stm32f3_HID_for_real.elf) can not be used in Windows ST-Link utility, it only accepts bin, hex, s19 and srec.

Any chance of one of these (pre-built) to save new users having to install the full tool kit and build their own?

Help Flashing/Installing

Hey
I have been trying to get the Foculus Rift working on my STM32F3 Discovery board and I have had no luck at all. Both the OpenOCD and STM32 ST-Link Methods have not worked, STM32 ST-LINK says the program is written, but when I plug it in the USB user port and nothing shows up. Also, the Linux method says the Adapter speed is not configured right. I really want to get my VR working, so any help would be appreciated!

Benji

FoculusRift->War Thunder

Good day! I really liked Your work! Thank you! My question is have you ever tried to run Your Foculus with the game War Thunder?

Magnetometer Calibration not emulated.

With the new 0.4.3 SDK the 'foculus' is not recognised properly, it seems that this due to the magnetometer calibration data not being emulated

simon@bigbox:/storage/ovr_sdk_linux_0.4.3$ sudo ./oculusd 
OVR::DeviceManagerThread - running (ThreadId=0x7fd12575c700).
OVR::DeviceManager - initialized.
OVR::Linux::HIDDevice - Opened '/dev/hidraw3'
                    Manufacturer:'Oculus VR, Inc.'  Product:'Tracker DK'  Serial#:'3AC4A55AFFFF'
Error: {ERR-011} [SensorImpl] Magnetometer calibration not found!
[TrackingManager] Sensor added: PrintedSerial= UUID=

Using the 0.3.2 SDK as a reference we can see what data it is expecting to see, a 52byte block described here in 'unpack()':
https://github.com/jherico/OculusSDK/blob/0.3.x/LibOVR/Src/OVR_Sensor2ImplUtil.h#L163

In 0.3.2 it is read via a feature report here:
https://github.com/jherico/OculusSDK/blob/0.3.x/LibOVR/Src/OVR_SensorCalibration.cpp#L45

Request - Configurable Orientations

At present the Foculus outputs it's data so that it is held vertically, USB sockets down and LED's toward user.

I think the more common orientations would be:

  • flat on a desk/car/etc (STM32 chip topside, LEDs on front/leading edge)
  • on the front of a display (LEDs facing forward/away from user), USB to the user's right.

Would it be possible to have control so that the orientation can be changed between the 6(?) 'standard' rotations? This should only involve picking the appropriate accelerometer/etc data to fill the USB packets.

These could be selected with the button, in a manner similar to gyro calibration. Does the STM32 include any EEPROM registers for long term storage?

Foculus rift can't recognise

Hello.
I recently purchased a stm32f3discovery board. Stitched this board according to the instructions through Linux. The board is not recognized as oculus. In "Devices and Printers" it is recognized as "Tracker DK", but this board does not work in games. In Linux, recognized without letters (as in the screenshots).

Rift debug:

"Time":	"2019-18-05_19:18:17",
"System Specifications":	{
	"Operating System":	"Microsoft Windows 7 ???????????? ",
	"Processor":	"AMD FX(tm)-6300 Six-Core Processor             ",
	"Video Controller Name":	"NVIDIA GeForce GTX 950",
	"Video Controller RAM (MB)":	2048,
	"Total RAM (GB)":	8
},
"Drivers":	[{
		"Path":	"\\system32\\OVRDisplay64.dll",
		"Version":	"1.0.22.0"
	}, {
		"Path":	"\\system32\\OVRDisplayRT64.dll",
		"Version":	"1.0.22.0"
	}, {
		"Path":	"\\syswow64\\OVRDisplay32.dll",
		"Version":	"1.0.22.0"
	}, {
		"Path":	"\\syswow64\\OVRDisplayRT32.dll",
		"Version":	"1.0.22.0"
	}, {
		"Path":	"\\system32\\drivers\\RiftEnabler.sys",
		"Version":	"1.0.22.0"
	}, {
		"Path":	"\\system32\\OVRDisplay32.dll",
		"Version":	"1.0.22.0"
	}, {
		"Path":	"\\system32\\OVRDisplayRT32.dll",
		"Version":	"1.0.22.0"
	}, {
		"Path":	"\\system32\\drivers\\RiftEnabler32.sys",
		"Version":	"1.0.22.0"
	}, {
		"Path":	"\\system32\\drivers\\OCUSBVID.sys",
		"Version":	"0.0.1.6"
	}],
"Devices":	[],
"LocalProtocolVersion":	{
	"Major":	1,
	"Minor":	0,
	"Patch":	0
},
"RemoteProtocolVersion":	{
	"Major":	1,
	"Minor":	0,
	"Patch":	0
}

ocu_td

terminal

Rebuild in Atollic TrueSTUDIO Cause LEDs Blink Slowly

Just a small problem...
I'm using Atollic TrueSTUDIO for ARM Lite. And since your codes are written in eclipse, I use the Demo Project provided by STM32F3-Discovery Board Firmware Applications Package and import your files in inc and src folders. It successfully compiled and reprogrammed the firmware of the board. And I can play Oculus' games.
But the LEDs blink very slowly and when I press the USER button to enter calibration routine, it stuck with the LD5 on. After reconnect it, windows cannot recognize it...

Also, I use the STM32 ST-LINK Utility to flash your stm32f3_HID_for_real.hex file to the board. It works really fine!

Is that any extra setting with the clock or something? Because I notice "SysTick_Config(RCC_Clocks.HCLK_Frequency / 1000);" in main and I change it to "SysTick_Config(RCC_Clocks.HCLK_Frequency / 100);" but nothing happened...

Device got unplugged midflash, any help

My Stm32f3 got unplugged while it was getting flashed and it's acting weird. It's not recognized in windows as the Oculus Rift sensor or as the STM32F3 but rather unknown device. When I try to reflash it this is the error I get:

0 0 127" -c"flash write_image stm32f3_HID_for_real.elf"
Open On-Chip Debugger 0.8.0 (2014-06-21-00:31)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info : This adapter doesn't support configurable speed
Info : STLINK v2 JTAG v16 API v2 SWIM v0 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 2.891327
Info : stm32f3x.cpu: hardware has 6 breakpoints, 4 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08004058 msp: 0x2000a000
Info : device id = 0x10036422
Info : flash size = 256kbytes
erased sectors 0 through 127 on flash bank 0 in 0.025622s
Error: couldn't open stm32f3_HID_for_real.elf
in procedure 'flash'

But when the cord is in USB USER I get the whole lights according to how you said it would look. Any help or did I brick it?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.