slimevr / slimevr-tracker-esp

SlimeVR tracker firmware for ESP32/ESP8266 and different IMUs

SlimeVR Tracker firmware for ESP

Firmware for ESP8266 / ESP32 microcontrollers and different IMU sensors to use them as a vive-like trackers in VR.

Requires SlimeVR Server to work with SteamVR and resolve pose. Should be compatible with owoTrack, but is not guaranteed.

Configuration

Firmware configuration is located in the defines.h file. For more information on how to configure your firmware, refer to the Configuring the firmware project section of SlimeVR documentation.

Compatibility

The following IMUs and their corresponding IMU values are supported by the firmware:

• BNO085 & BNO086 (IMU_BNO085)
  • Using any fusion in internal DMP. Best results with ARVR Stabilized Game Rotation Vector or ARVR Stabilized Rotation Vector if in good magnetic environment.
• BNO080 (IMU_BNO080)
  • Using any fusion in internal DMP. Doesn't have BNO085's ARVR stabilization, but still gives good results.
• MPU-6500 (IMU_MPU6500) & MPU-6050 (IMU_MPU6050)
  • Using internal DMP to fuse Gyroscope and Accelerometer. Can drift substantially.
  • NOTE: Currently the MPU will auto calibrate when powered on. You must place it on the ground and DO NOT move it until calibration is complete (for a few seconds). LED on the ESP will blink 5 times after calibration is over.
• BNO055 (IMU_BNO055)
  • Performs much worse than BNO080, despite having the same hardware. Not recommended for use.
• MPU-9250 (IMU_MPU9250)
  • Using Mahony sensor fusion of Gyroscope, Magnetometer and Accelerometer, requires good magnetic environment.
  • See Sensor calibration below for info on calibrating this sensor.
  • Specify IMU_MPU6500 in your defines.h to use without magnetometer in 6DoF mode.
  • Experimental support!
• BMI160 (IMU_BMI160)
  • Using sensor fusion of Gyroscope and Accelerometer.
  • See Sensor calibration below for info on calibrating this sensor.
  • Calibration file format is unstable and may not be able to load using newer firmware versions.
  • Experimental support!
  • Support for the following magnetometers is implemented (even more experimental): HMC5883L, QMC5883L.
• ICM-20948 (IMU_ICM20948)
  • Using fusion in internal DMP for 6Dof or 9DoF, 9DoF mode requires good magnetic environment.
  • Comment out USE_6DOF in debug.h for 9DoF mode.
  • Experimental support!
• BMI270 (IMU_BMI270), ICM-42688 (IMU_ICM42688), LSM6DS3TR-C (IMU_LSM6DS3TRC), LSM6DSV (IMU_LSM6DSV), LSM6DSO (IMU_LSM6DSO), LSM6DSR (IMU_LSM6DSR), MPU-6050 (IMU_MPU6050_SF)
  • Using common code: SoftFusionSensor for sensor fusion of Gyroscope and Accelerometer.
  • Gyro&Accel sample rate, gyroscope offset and 6-side accelerometer calibration supported.
  • In case of BMI270, gyroscope sensitivity auto-calibration (CRT) is additionally performed.
  • Support for magnetometers is currently not implemented.
  • VERY experimental support!

Firmware can work with both ESP8266 and ESP32. Please edit defines.h and set your pinout properly according to how you connected the IMU.

Sensor calibration

It is generally recommended to turn trackers on and let them lay down on a flat surface for a few seconds.* This will calibrate them better.

Some trackers require special calibration steps on startup:

MPU-9250

• Turn them on with chip facing down. Flip up and put on a surface for a couple of seconds, the LED will light up.
• After a few blinks, the LED will light up again
• Slowly rotate the tracker in an 8-motion facing different directions for about 30 seconds, while LED is blinking
• LED will turn off when calibration is complete
• You don't have to calibrate next time you power it on, calibration values will be saved for the next use

BMI160

If you have any problems with this procedure, connect the device via USB and open the serial console to check for any warnings or errors that may indicate hardware problems.

• Step 0: Power up with the chip facing down. Or press the reset/reboot button.

  The LED will be lit continuously. If you have the tracker connected via USB and open the serial console, you will see text prompts in addition to the LEDs. You can only calibrate 1 IMU at a time.

  Flip it back up while the LED is still solid. Wait a few seconds, do not touch the device.

• Step 1: It will flash 3 times when gyroscope calibration begins.

  If done incorrectly, this step is the most likely source of constant drift.

  Make sure the tracker does not move or vibrate for 5 seconds - still do not touch it.

• Step 2: It will flash 6 times when accelerometer calibration begins.

  The accelerometer calibration process requires you to hold the device in 6 unique orientations (e.g. sides of a cube), keep it still, and not hold or touch for 3 seconds each. It uses gravity as a reference and automatically detects when it is stabilized - this process is not time-sensitive.

  If you are unable to keep it on a flat surface without touching, press the device against a wall, it does not have to be absolutely perfect.

  There will be two very short blinks when each position is recorded.

  Rotate the device 90 or 180 degrees in any direction. It should be on a different side each time. Continue to rotate until all 6 sides have been recorded.

  The last position has a long flash when recorded, indicating exit from calibration mode.

Additional info for BMI160

• For best results, calibrate when the trackers are warmed up - put them on for a few minutes, wait for the temperature to stabilize at 30-40 degrees C, then calibrate. Enable developer mode in SlimeVR settings to see tracker temperature.

• There is a legacy accelerometer calibration method that collects data during in-place rotation by holding it in hand instead. If you are absolutely unable to use the default 6-point calibration method, you can switch it in config file defines_bmi160.h.

• For faster recalibration, you disable accelerometer calibration by setting BMI160_ACCEL_CALIBRATION_METHOD option to ACCEL_CALIBRATION_METHOD_SKIP in defines_bmi160.h. Accelerometer calibration can be safely skipped if you don't have issues with pitch and roll. You can check it by enabling developer mode in SlimeVR settings (General / Interface) and going back to the "Home" tab. Press "Preview" button inside the tracker settings (of each tracker) to show the IMU visualizer. Check if pitch/roll resembles its real orientation.

• Calibration data is written to the flash of your MCU and is unique for each BMI160, keep that in mind if you have detachable aux trackers.

Uploading On Linux

Follow the instructions in this link PlatformIO, this should solve any permission denied errors

Contributions

Any contributions submitted for inclusion in this repository will be dual-licensed under either:

• MIT License (LICENSE-MIT)
• Apache License, Version 2.0 (LICENSE-APACHE)

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.

You also certify that the code you have used is compatible with those licenses or is authored by you. If you're doing so on your work time, you certify that your employer is okay with this and that you are authorized to provide the above licenses.

For an explanation on how to contribute, see CONTRIBUTING.md

slimevr-tracker-esp's Issues

Allow tracker rotation to be changed at runtime

Currently there is a hardcoded "IMU_ROTATION" parameter that needs to be set at compile time. I don't see why this parameter shouldn't be a setting on the server instead. It would be really useful for prototyping, or if you accidentally put on your tracker on the wrong side.

Per-sensor configuration

This is required for #32 and overal MPU support (#14), as well as for enabling and disabling magnetometers. Need to adjust protocol and configuration storage to implement recieving, sending, and storing of per-tracker configuration, that can store such things as magnetometer status, calibration data, etc.

This does not superceed the usage of defines to configure hardware setup.

Is there a guide for adding new sensor types?

I want to use some sensor chip that is not on the supported list, how do I add support for it and keep the code clear? What are the source code changes that must be made?

Esp doesn't reconnect automatically when wifi connection is lost

Possibly something was broken during last changes in wifi code, or it never worked.

Unable to use 9250s as auxiliary if the main imu is 20948

[DEBUG] [ICM20948Sensor:0] DMP initialized
[DEBUG] [ICM20948Sensor:0] Using 9 axis configuration
[DEBUG] [ICM20948Sensor:0] Enabled DMP sensor for sensor orientation
[DEBUG] [ICM20948Sensor:0] Set Quat9 to 100Hz frequency
[DEBUG] [ICM20948Sensor:0] FIFO Enabled
[DEBUG] [ICM20948Sensor:0] DMP Enabled
[DEBUG] [ICM20948Sensor:0] Reset DMP
[DEBUG] [ICM20948Sensor:0] Reset FIFO
[INFO ] [MPU9250Sensor:1] Connected to MPU9250 (0x71) at address 0x69
[INFO ] [MPU9250Sensor:1] Flip front to confirm start calibration
[DEBUG] [MPU9250Sensor:1] Starting calibration...
[DEBUG] [MPU9250Sensor:1] Gathering raw data for device calibration...
[INFO ] [MPU9250Sensor:1] Put down the device and wait for baseline gyro reading calibration
[INFO ] [MPU9250Sensor:1] Gently rotate the device while it's gathering accelerometer and magnetometer data
[DEBUG] [MPU9250Sensor:1] Calculating calibration data...

User exception (panic/abort/assert)
--------------- CUT HERE FOR EXCEPTION DECODER ---------------

Unhandled C++ exception: OOM

stack>>>

last failed alloc call: 4020D112(24000)

--------------- CUT HERE FOR EXCEPTION DECODER ---------------

last failed alloc caller: 0x4020d112

ets Jan 8 2013,rst cause:2, boot mode:(3,6)

load 0x4010f000, len 3460, room 16
tail 4
chksum 0xcc
load 0x3fff20b8, len 40, room 4
tail 4
chksum 0xc9
csum 0xc9
v0006f7e0
~ld

Building firmware using GitHub Actions

SlimeVR/SlimeVR-Server#76 To implement that it would be useful to build different types of firmware (for different boards) with github actions, and server could upload it by itself.
https://docs.platformio.org/en/latest/integration/ci/github-actions.html
gonna experiment with this

BMI160 Library dependency was not documented

I discovered that the BMI160 library was copied and modified from the following repository. All credit for the register mapping, function names, and general structure goes to contributors on corelibs-arduino101 (which was forked by sgbihu from arduino/ArduinoCore-arc32).

There was no dependency added to the firmware, and no fork was created from the original repo. I have performed a diff between the original library and the one in SlimeVR-Tracker-ESP -- the changes are significant, and much of the code was deleted. It appears that the main point of the changes was to offload more of the code base to the I2C library made by Jeff Rowberg (which is here). The screenshot below summarizes what happened fairly well:

Here is an example of how the remaining functions were changed:

Besides this, some blank lines and functions not used by SlimeVR were removed.

I'm not sure if any action is needed or can be taken, but I wanted to somehow document what happened and give credit to the original developer of the BMI160 library we use.

MPU6050 doesn't work

MPU6050 wasn't properly tested and returns 0s.

A fatal error occurred: Failed to connect to ESP8266: Timed out waiting for packet header *** [upload] Error 2

On one of my fully assembled trackers, when i upload the firmware it spits out this error
`Using manually specified: /dev/ttyS0
Uploading .pio/build/esp12e/firmware.bin
esptool.py v3.0
Serial port /dev/ttyS0
Connecting......................................_____

A fatal error occurred: Failed to connect to ESP8266: Timed out waiting for packet header
*** [upload] Error 2`

On a board without anything attached, it works.

For some reason the one with battery power shows up on the port "/dev/ttyS0" but on the one with nothing on it it shows up on "Serial port /dev/ttyUSB0". Could this be a power issue? should i upload the firmware before connecting the battery?

Add ID command

An ID command sent from the server should force tracker to light up the LED for identification. Command can contain trackerId but the tracker can ignore it if there are no way to identify only extension. Command should be acknowledged by replying it back to the server. Another command with state off should stop the process and again be acknowledged to the server.

ESP32 firmware

Add firmware support for ESP32.

Fancy wifi provisioning

This is both for firmware and software. Here are features that needs to be implemented:

• Tracker creates an AP with configuration protal, if it can't connect to any wifi network (pr #59 already implements this)
• Tracker can be commanded to provision nearby trackers. With this command it tries to connect to all unconfigured trackers (it gudges by an AP name) and sends them credentials of its own wifi network
  • Server should be able to command trackers to provision other trackers remotely or via USB
• When tracker is connected via USB, but it doesn't have a wifi connection, a popup offering wifi configuration should pop up
  • This pop up should let user select out of found wifi networks, it should have an checkbox "Connect other trackers", see above

6050 does not work when the first IMU is BNO085 and the second IMU is 6050

My configuration:

// Set parameters of IMU and board used
#define IMU IMU_BNO085
#define SECOND_IMU IMU_MPU6050

I found that in the above situation, I ignored the second 6050 without any message in the log.

[INFO ] [SlimeVR] SlimeVR v0.2.2 starting up...
[INFO ] [Configuration] Found up-to-date configuration v1
[INFO ] [Configuration] Loaded configuration
[INFO ] [BNO080Sensor:0] Connected to BNO085 on 0x4a. Info: SW Version Major: 0x00 SW Version Minor: 0x00 SW Part Number: 0x00 SW Build Number: 0x00 SW Version Patch: 0x00
[INFO ] [WiFiHandler] Setting up WiFi
[INFO ] [WiFiHandler] Loaded credentials for SSID kamilake and pass length 24
[DEBUG] [WiFiHandler] Status: 7
[NOTICE] OTA updates allowed
...[INFO ] [WiFiHandler] Connected successfully to SSID 'kamilake', ip address 192.168.1.204
[INFO ] [UDPClient] Looking for the server...
[DEBUG] [UDPClient] Handshake successful, server is 192.168.1.234:6969

I've already connected the second sensor and it worked well in other configurations

Expected Results:

[INFO ] [MPU6050Sensor:0] Connected to MPU6050 (reported device ID 0x68) at address 0x69
[DEBUG] [MPU6050Sensor:0] Enabling DMP...
[DEBUG] [MPU6050Sensor:0] DMP ready! Waiting for first interrupt...

The above output should be displayed


I'm looking back on the source code
Is there a problem with my code or hardware? Then let me know)))

Ability to set the device hostname

Being able to set the device hostname over serial(much like wifi credentials are currently) would make it easier to identify each tracker on access point admin pages, as currently they all show up as "esp8266" or "espressif", on some buggy routers this also causes them to get the same ip address.

[INFO ] [MPU9250Sensor:0] Connected to MPU9250 (reported device ID 0x75) at address 0x68

[INFO ] [MPU9250Sensor:0] Connected to MPU9250 (reported device ID 0x75) at address 0x68

why my mpu9250 device ID is 0x75
if i modify mpu9250.cpp 0x71 to 0x75
it can start calibration, but

[DEBUG] [MPU9250Sensor:0] [INFO] Magnetometer calibration matrix:
[DEBUG] [MPU9250Sensor:0] {
[DEBUG] [MPU9250Sensor:0] -nan, -nan, -nan, -nan
[DEBUG] [MPU9250Sensor:0] nan, -nan, -nan, -nan
[DEBUG] [MPU9250Sensor:0] nan, -nan, -nan, -nan
[DEBUG] [MPU9250Sensor:0] }

calibration matrix is nan

Sorry I am from China, My English isn't good

ESP disconnects from the server when the Wifi window closes

When setting wifi credentials, the ESP will connect with the Wifi window open. When you close the Wifi window the LED on the ESP flashes quickly, then it disconnects from the server.

It almost seems like closing the Wifi windows sends a restart command to the ESP.

MPU9250 does not work properly after this commit

I asked in discord a month ago but no one seemed to notice https://discord.com/channels/817184208525983775/1054741415579619430

The commits: fd3e463

After flashing ,The 9250 's yaw data is very confusing, If I rotate to the left, the data increases first and then decreases after a while, and tends to return to its original value. If I rotate to the right, just the opposite

In actual use, the tracker rotates at weird angles,so it is basically unuseable

Rollback to the previous version everything is fine

I have compared the code , it seems that enabling Mahoney / Magiwick causing the problem btw

Make sensor fusion algorithm IMU-independent

There is a sensor fusion algorithm being used right now to fuse the dmp-enabled 6dof gyro + accel data in the MPU9250 with the magnetometer.

Would it be possible to extract this code into an IMU-agnostic class? That way it could be easier used in other IMUs. Also, my understanding was that mahoney can be used for 9dof or for 6dof. Can we make the class able to do either? This would be useful because the ICM-20602 does not have a DMP so it must run the fusion on the ESP.

Implement proper serial commands handling

Need to handle a few commands from serial port for debug, testing and configuration. Need to implement the system as a whole, and a few necessary commands:

• Health report
• Reboot
• Factory reset
• Set up WiFi credentials
• Getting firmware config

Issue with Sensor data from MPU-9250

Hello Again!

I've been trying to set up some trackers of my own with this.
I have gotten to a point where its mostly stable for one sensor, for a while (+- 5 minutes). However, all other sensors after a short time (within a few seconds) start reporting "NaN NaN NaN" for their rotation value.

I've run a short sketch on my esp's to ensure the MPU's are wired and configured correctly - and they are, showing data across the range.

I added some debug print lines to the MPU9250Sensor::getMPUScaled() call to show me the raw data, and then another to show me what gets sent over the wire.

This results in values like such:

[DEBUG] Sent data: -0.00,39145.87,32490.37RM, 0.00,0.00,1.00A, -0.00,0.77,0.64M, nan,nan,nanQ.
[DEBUG] Raw data: 32767,32767,-3476A, -308,-243,-1429G, -129,-129,27890M
[DEBUG] Sent data: -0.00,61243.93,54674.87RM, 0.00,0.00,1.00A, -0.00,0.75,0.67M, nan,nan,nanQ.
[DEBUG] Raw data: 32767,32767,-3532A, -178,-211,-1414G, -129,-129,13554M
[DEBUG] Sent data: -0.00,33119.12,26440.05RM, 0.00,0.00,1.00A, -0.00,0.78,0.62M, nan,nan,nanQ.
[DEBUG] Raw data: 32767,32767,-3524A, -130,-236,-1419G, -129,-129,15602M
[DEBUG] Sent data: -0.00,37136.96,30473.60RM, 0.00,0.00,1.00A, -0.00,0.77,0.63M, nan,nan,nanQ.
[DEBUG] Raw data: 32767,32767,-3600A, -296,-218,-1411G, -129,-129,-3855M
[DEBUG] Sent data: 0.00,-1034.39,-7847.05RM, 0.00,0.00,1.00A, 0.00,-0.13,-0.99M, nan,nan,nanQ.
[DEBUG] Raw data: 32767,32767,-3688A, -339,-224,-1399G, -129,-129,-26383M
[DEBUG] Sent data: 0.00,-45230.51,-52216.04RM, 0.00,0.00,1.00A, 0.00,-0.65,-0.76M, nan,nan,nanQ.
[DEBUG] Raw data: 32767,32767,-3604A, -150,-230,-1350G, -129,-129,-4879M
[DEBUG] Sent data: 0.00,-3043.31,-9863.82RM, 0.00,0.00,1.00A, 0.00,-0.29,-0.96M, nan,nan,nanQ.
[DEBUG] Raw data: 32767,32767,-3636A, -195,-219,-1436G, -129,-129,-13071M
[DEBUG] Sent data: 0.00,-19114.62,-25998.00RM, 0.00,0.00,1.00A, 0.00,-0.59,-0.81M, nan,nan,nanQ.
[DEBUG] Raw data: 32767,32767,-3624A, -335,-229,-1390G, -129,-129,-9999M
[DEBUG] Sent data: 0.00,-13087.88,-19947.68RM, 0.00,0.00,1.00A, 0.00,-0.55,-0.84M, nan,nan,nanQ.

Any ideas? Again - checked the sensor with another sketch to ensure it is working and all are working perfectly fine.

I'm just not smart enough / clued up enough to understand the Quaternion maths that goes into translating the raw sensor values.

EEPROM handling causes a LoadStore Error

Hello! Trying to build a DIY version of this but something is not very happy.

When running the project on an esp32, I'm getting the following error: (backtrace debugging turned on for help)

Rebooting...
ets Jun 8 2016 00:22:57

rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:1044
load:0x40078000,len:10124
load:0x40080400,len:5828
entry 0x400806a8
Guru Meditation Error: Core 1 panic'ed (LoadStoreError). Exception was unhandled.
Core 1 register dump:
PC : 0x400d0a62 PS : 0x00060530 A0 : 0x800d0bcc A1 : 0x3ffb1f60
A2 : 0x3ffc1730 A3 : 0x000186a0 A4 : 0x0000000d A5 : 0x00000000
A6 : 0x00000003 A7 : 0x00000000 A8 : 0x3f400120 A9 : 0x3ffb84d5
A10 : 0x000000ff A11 : 0x000000ff A12 : 0x00000000 A13 : 0x00000064
A14 : 0x00000064 A15 : 0x60013000 SAR : 0x0000001c EXCCAUSE: 0x00000003
EXCVADDR: 0x3f400120 LBEG : 0x4000c2e0 LEND : 0x4000c2f6 LCOUNT : 0x00000000

ELF file SHA256: 0000000000000000

Backtrace: 0x400d0a62:0x3ffb1f60 0x400d0bc9:0x3ffb1f80 0x400d713a:0x3ffb1fb0 0x4008a30e:0x3ffb1fd0
#0 0x400d0a62:0x3ffb1f60 in DeviceConfig* const& EEPROMClass::get<DeviceConfig* const>(int, DeviceConfig* const&) at src/configuration.cpp:58
(inlined by) getConfigPtr() at src/configuration.cpp:44
#1 0x400d0bc9:0x3ffb1f80 in setup() at src/main.cpp:99
#2 0x400d713a:0x3ffb1fb0 in loopTask(void*) at C:\Users\User-PC.platformio\packages\framework-arduinoespressif32\cores\esp32/main.cpp:18
#3 0x4008a30e:0x3ffb1fd0 in vPortTaskWrapper at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/freertos/port.c:355 (discriminator 1)

Any assistance? Tested on an ESP DOIT DevKit v1 as well as a Firebeetle ESP32 V4, both thow the same issue.

BNO08X Calibration

I've noticed while spinning through BNO08X datasheets that it recommends a self calibration from the user
For best motion tracking performance, it is recommended to calibrate the BNO08X. Since each MEMS sensor
part has different individual characteristics, each device using the BNO08X must be calibrated individually.
This seems to be a one time thing.
Ceva suggests that even if this isn't done, the BNO will still work using factory calibration but I believe it could be worth a look in to if a user calibration could improve overall drift time.
I would be interested to hear others opinions though.

Trackers not connecting without WiFi reboot

Discussion is on Discord: https://discord.com/channels/817184208525983775/1027559999574114376

There seems to be an issue with specific routers where a reboot is required to get Slime trackers to connect.

Routers known to have this issue:

• TP-Link Archer C4000 (AC4000)

Routers that might work using a workaround introduced in firmware version 0.3.0 (WIFI_PHY_MODE_11G):

• TP-Link Archer AXE75 (AXE5400)
• ASUS RT-AX56U
• ASUS RT-AC66U
• ASUS RT-AC68U
• ASUS ROG AX11000
• ASUS ROG AXE11000
• ASUS ZenWiFi AX Mini (XD4)

Routers that require to be set to "Legacy" Wireless Mode:

• ASUS TUF-AX5400
• ASUS RT-AX55
• ASUS RT-AX82U
• ASUS RT-AX88U
• ASUS RT-AX92U

(From Loler920a-Frank)

Routers that do not have this issue:

• ASUS RT-AX58U

Low battery LED signal

Should start blinking LED when battery level drops too low (like 3.3v probably?)

Brownout Sensor was detected

Im using an esp32-wroom and a MPU6050. I haven't built the tracker to use an external power source and its running solely on USB. The error goes away when I disconnect the MPU but I get another error that it can't detect SCL or SDA pins so not much space to do anything.

fff

fff

Add wifi signal strength indicator

It would be useful to see signal strength to better diagnose connectivity issues. Arduino framework provides a method to get signal strength of the current connection: https://www.arduino.cc/en/Reference/WiFiRSSI

Flash failure from Wifi writing credentials

Wifi.begin() writes credentials to flash every time it is called, on some boards this causes the flash to fail quickly, resulting in Wifi.begin() resetting the board.

Calling Wifi.persistent(false) before Wifi.begin() (and potentially other wifi functions) stops the credentials from being written. On boards with failing flash, this will continue working.

[Feature Request] Allow multiple Wifi's to be saved

It would be nice if i could save an arbritrary amount of Wifi's to the Tracker and it connects to the one with the highest signal.

That would allow for multiple Wifi SSIDs being set up in a house/apartment and also make it easier if you either need to move between divorced parents or just visit friends often.

Issues when cloning repo

Hey there!

I've been getting random include errors when trying to build.
There's always a random file missing, according to PlatformIO.
Cloning the repo again does not fix the issue, then there is another file missing

Fix GET TEST command

GET TEST command prints mac address wrong, need to remove it from the reply or fix it.

Switching magnetometer on and off at runtime

This is something that @Fishvap requested on discord, though I vaguely recall some separate discussion about doing something like this for the BNOs.

This is a cross-cutting concern, but I'm starting with an issue on the Firmware, since it doesn't matter if we add UI for it if the trackers don't support it.

The concept is that for users with trackers that have magnetometers and appropriate firmware flashed, we can eventually add a switch to the UI somewhere (per-tracker? globally?) that switches between ignoring the magnetometer or not. This would allow people to fiddle with enabling or disabling the magnetometer without having to re-flash firmware. (one potential use-case might be for someone who is travelling, their home happens to have a good magnetic environment, but wherever they are right now isn't.)

This roughly requires:

• In the firmware, a build variant which can choose this at runtime.
  • This is more difficult for things like the mpu9250, since many users in 6dof mode use the DMP, while users in 9dof mode can't and instead use our own sensor fusion. Including both sets of code might inflate firmware size.
    • This might end up being a choice of "use DMP, or have the ability to switch" at compile time.
  • This is easier for things like the BNOs, which do the sensor fusion for us and we can choose to request magnetometer vs no magnetometer, or for IMUs where we always need to do our own sensor fusion anyway.
    • Something that I haven't checked: what fusion algorithms do we support that are compatible with which modes?
• In the firmware protocol, a means for the server to communicate whether a magnetometer should be considered or not to the tracker
  • Do we already have a means for the server to communicate runtime settings to trackers?
• In the GUI, the actual toggle.

Make the logs have unique id for each message in front of each log line

In the gui or the server there is instances where we look for some specific lines of logs in the serial to do other actions.
it can causes issues if someone decides to change de text of that log line to something else and forget to change the server or gui that are lookig for it.

My proposal is that each log lines have their unique id. kinda like error id but for everything. Log lines that hold data would be the execption because you have to actually parse the log line to get data. but for all the others like

looking for server...
handshake successfull

it would be better to have something like

{1} looking for server ....
{34} handshake successfull ...

that way code inside the server could just use the id as a reference instead of the log text

Analyze I2C signals between ESP and BNO085 module

Capture signals during normal operation, try to capture server crash, send captures to CEVA.

OTA Push does not update WiFi Settings

Been banging on this for an hour or so now.

If I push an update over OTA, the tracker will take the update, but it will not change the hardcoded WiFi settings on the tracker if I've changed them in platformio.ini.

Dismantling my tracker and looking at the serial port monitor, the tracker was looking for the old WiFi AP, not the new one.

Pushing the same firmware over USB does not fix this either. The only way for me to fix it was to use the WiFi button in Server. Had to dismantle all 6 of my trackers.

Implement proper state and error signaling with LED and serial

Currently all LED signaling is disabled and only Orange Light of Death is used when sensor stop responding. Current signaling ideas:

• Implement state and error priority, only highest error is signaled displayed, for example: OK > Loading > Connecting WiFi > Connecting to server > Death
• Repeat current states in serial every few seconds
• Signal end of loading with debug data for testing purposes

Compilation error for TTGO T7 V1.3

TTGO T7 V1.3 framework defines LED_BUILTIN const instead of definition, this causes the conflict with LED_BUILTIN definition in consts.h in SlimeVR firmware. We may want to add this board type specifically and create separate set of definitions for it.

Body now rotates around the head when you turn left/right.

Issue seems to be introduced between these commits.
9d93df6
b8bd02e

Both reports of this issue are from ICM 20948 users.

Wifi credentials doesn't save after reset

Wifi credentials set by serial command don't recover after reset. Have to set each time (and also impossible to use because at the same moment i disconnect usb, it already gone)
Only hardcode credentials work fine

Tested on 2 node mcu v2

Unable to save AUX IMU calibration data when using MPU9250*2

Setup:

MCU:ESP32-WROOM-32E
IMU:MPU9250*2

Version:

main

Tried:

clear flash and reflash firmware. (x)
swap esp32 (x)
use rel 0.2.2 (x)

Screenshots:

calibration data saved

after restart, (No calibration data found for sensor 1):

Full log(rel 0.2.2):

--- Terminal on COM5 | 115200 8-N-1
--- Available filters and text transformations: colorize, debug, default, direct, esp32_exception_decoder, hexlify, log2file, nocontrol, printable, send_on_enter, time
--- More details at https://bit.ly/pio-monitor-filters
--- Quit: Ctrl+C | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H

<clear flash & flash firmware>

ets Jul 29 2019 12:21:46

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4    
load:0x3fff001c,len:1044 
load:0x40078000,len:10124
load:0x40080400,len:5828 
entry 0x400806a8



[INFO ] [SlimeVR] SlimeVR v0.2.2 starting up...
.pio/libdeps/esp32/LittleFS_esp32/src/lfs.c:1076:error: Corrupted dir pair at {0x0, 0x1}
E (13) esp_littlefs: mount failed,  (-84)
E (16) esp_littlefs: Failed to initialize LittleFS
[E][LITTLEFS.cpp:90] begin(): Mounting LITTLEFS failed! Error: -1
[WARN ] [Configuration] Could not mount LittleFS, formatting
[E][vfs_api.cpp:64] open(): /littlefs/config.bin does not exist
[INFO ] [Configuration] No configuration file found, creating new one
[DEBUG] [Configuration] Saved configuration
[E][vfs_api.cpp:64] open(): /littlefs/calibrations does not exist
[WARN ] [Configuration] No calibration data found, creating new directory...
[DEBUG] [Configuration] Found calibration data directory
[INFO ] [Configuration] Loaded configuration
[INFO ] [MPU9250Sensor:0] Connected to MPU9250 (0x71) at address 0x68
[WARN ] [MPU9250Sensor:0] No calibration data found for sensor 0, ignoring...
[INFO ] [MPU9250Sensor:0] Calibration is advised
[DEBUG] [MPU9250Sensor:0] Enabling DMP...
[DEBUG] [MPU9250Sensor:0] DMP ready! Waiting for first interrupt...
[INFO ] [MPU9250Sensor:1] Connected to MPU9250 (0x71) at address 0x69
[WARN ] [MPU9250Sensor:1] No calibration data found for sensor 1, ignoring...
[INFO ] [MPU9250Sensor:1] Calibration is advised
[DEBUG] [MPU9250Sensor:1] Enabling DMP...
[DEBUG] [MPU9250Sensor:1] DMP ready! Waiting for first interrupt...
[INFO ] [WiFiHandler] Setting up WiFi
[INFO ] [WiFiHandler] Loaded credentials for SSID  and pass length 0
[E][WiFiSTA.cpp:221] begin(): connect failed!
[DEBUG] [WiFiHandler] Status: 4
[NOTICE] OTA updates allowed
...........[ERROR] [WiFiHandler] Can't connect from saved credentials, status: 6.
[DEBUG] [WiFiHandler] Trying hardcoded credentials...
...[INFO ] [WiFiHandler] Connected successfully to SSID ' ', ip address  
[INFO ] [UDPClient] Looking for the server...
[INFO ] [UDPClient] Looking for the server...


<Cal main IMU>

ets Jul 29 2019 12:21:46

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:1044
load:0x40078000,len:10124
load:0x40080400,len:5828
entry 0x400806a8



[INFO ] [SlimeVR] SlimeVR v0.2.2 starting up...
[INFO ] [Configuration] Found up-to-date configuration v1
[DEBUG] [Configuration] Found calibration data directory
[INFO ] [Configuration] Loaded configuration
[INFO ] [MPU9250Sensor:0] Connected to MPU9250 (0x71) at address 0x68
[INFO ] [MPU9250Sensor:0] Flip front to confirm start calibration
[DEBUG] [MPU9250Sensor:0] Starting calibration...
[INFO ] [MPU9250Sensor:0] Gently rotate the device while it's gathering magnetometer data
[DEBUG] [MPU9250Sensor:0] Calculating calibration data...
[DEBUG] [MPU9250Sensor:0] [INFO] Magnetometer calibration matrix:
[DEBUG] [MPU9250Sensor:0] {
[DEBUG] [MPU9250Sensor:0]   93.763382, 1.211771, 0.015985, 0.024742
[DEBUG] [MPU9250Sensor:0]   -165.140350, 0.015985, 1.209103, 0.004458
[DEBUG] [MPU9250Sensor:0]   260.576416, 0.024742, 0.004458, 1.101298
[DEBUG] [MPU9250Sensor:0] }
[DEBUG] [MPU9250Sensor:0] Saving the calibration data
[DEBUG] [Configuration] Saved configuration
[DEBUG] [MPU9250Sensor:0] Saved the calibration data
[INFO ] [MPU9250Sensor:0] Calibration data gathered
[DEBUG] [MPU9250Sensor:0] Enabling DMP...
[DEBUG] [MPU9250Sensor:0] DMP ready! Waiting for first interrupt...
[INFO ] [MPU9250Sensor:1] Connected to MPU9250 (0x71) at address 0x69
[INFO ] [MPU9250Sensor:1] Flip front to confirm start calibration
[WARN ] [MPU9250Sensor:1] No calibration data found for sensor 1, ignoring...
[INFO ] [MPU9250Sensor:1] Calibration is advised
[DEBUG] [MPU9250Sensor:1] Enabling DMP...
[DEBUG] [MPU9250Sensor:1] DMP ready! Waiting for first interrupt...
[INFO ] [WiFiHandler] Setting up WiFi
[INFO ] [WiFiHandler] Loaded credentials for SSID  and pass length 63
[DEBUG] [WiFiHandler] Status: 6
[NOTICE] OTA updates allowed
[NOTICE] OTA updates disabled by timeout, this is not an error
...[INFO ] [WiFiHandler] Connected successfully to SSID ' ', ip address  
[INFO ] [UDPClient] Looking for the server...
[INFO ] [UDPClient] Looking for the server...

<Cal AUX IMU>

ets Jul 29 2019 12:21:46

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:1044
load:0x40078000,len:10124
load:0x40080400,len:5828
entry 0x400806a8



[INFO ] [SlimeVR] SlimeVR v0.2.2 starting up...
[INFO ] [Configuration] Found up-to-date configuration v1
[DEBUG] [Configuration] Found calibration data directory
[DEBUG] [Configuration] Found sensor calibration for MPU9250 at index 0
[INFO ] [Configuration] Loaded configuration
[INFO ] [MPU9250Sensor:0] Connected to MPU9250 (0x71) at address 0x68
[DEBUG] [MPU9250Sensor:0] Enabling DMP...
[DEBUG] [MPU9250Sensor:0] DMP ready! Waiting for first interrupt...
[INFO ] [MPU9250Sensor:1] Connected to MPU9250 (0x71) at address 0x69
[INFO ] [MPU9250Sensor:1] Flip front to confirm start calibration
[DEBUG] [MPU9250Sensor:1] Starting calibration...
[INFO ] [MPU9250Sensor:1] Gently rotate the device while it's gathering magnetometer data
[DEBUG] [MPU9250Sensor:1] Calculating calibration data...
[DEBUG] [MPU9250Sensor:1] [INFO] Magnetometer calibration matrix:
[DEBUG] [MPU9250Sensor:1] {
[DEBUG] [MPU9250Sensor:1]   134.978104, 1.554181, -0.000397, -0.016114
[DEBUG] [MPU9250Sensor:1]   107.958794, -0.000397, 1.532582, 0.016181
[DEBUG] [MPU9250Sensor:1]   161.959076, -0.016114, 0.016181, 1.508269
[DEBUG] [MPU9250Sensor:1] }
[DEBUG] [MPU9250Sensor:1] Saving the calibration data
[DEBUG] [Configuration] Saved configuration
[DEBUG] [MPU9250Sensor:1] Saved the calibration data
[INFO ] [MPU9250Sensor:1] Calibration data gathered
[DEBUG] [MPU9250Sensor:1] Enabling DMP...
[DEBUG] [MPU9250Sensor:1] DMP ready! Waiting for first interrupt...
[INFO ] [WiFiHandler] Setting up WiFi
[INFO ] [WiFiHandler] Loaded credentials for SSID  and pass length 63
[DEBUG] [WiFiHandler] Status: 6
[NOTICE] OTA updates allowed
[NOTICE] OTA updates disabled by timeout, this is not an error
...[INFO ] [WiFiHandler] Connected successfully to SSID ' ', ip address  
[INFO ] [UDPClient] Looking for the server...
[INFO ] [UDPClient] Looking for the server...

<Restart MCU>

ets Jul 29 2019 12:21:46

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:1044
load:0x40078000,len:10124
load:0x40080400,len:5828
entry 0x400806a8



[INFO ] [SlimeVR] SlimeVR v0.2.2 starting up...
[INFO ] [Configuration] Found up-to-date configuration v1
[DEBUG] [Configuration] Found calibration data directory
[DEBUG] [Configuration] Found sensor calibration for MPU9250 at index 0
[DEBUG] [Configuration] Found sensor calibration for MPU9250 at index 0
[INFO ] [Configuration] Loaded configuration
[INFO ] [MPU9250Sensor:0] Connected to MPU9250 (0x71) at address 0x68
[DEBUG] [MPU9250Sensor:0] Enabling DMP...
[DEBUG] [MPU9250Sensor:0] DMP ready! Waiting for first interrupt...
[INFO ] [MPU9250Sensor:1] Connected to MPU9250 (0x71) at address 0x69
[WARN ] [MPU9250Sensor:1] No calibration data found for sensor 1, ignoring...
[INFO ] [MPU9250Sensor:1] Calibration is advised
[DEBUG] [MPU9250Sensor:1] Enabling DMP...
[DEBUG] [MPU9250Sensor:1] DMP ready! Waiting for first interrupt...
[INFO ] [WiFiHandler] Setting up WiFi
[INFO ] [WiFiHandler] Loaded credentials for SSID  and pass length 63
[DEBUG] [WiFiHandler] Status: 6
[NOTICE] OTA updates allowed
...[INFO ] [WiFiHandler] Connected successfully to SSID ' ', ip address  
[INFO ] [UDPClient] Looking for the server...
[INFO ] [UDPClient] Looking for the server...

SlimeVR Server gone?

Hey, your project sounds interesting and i have some spare ESP laying around here. Unluckily the SlimeVR Server is gone from Github. Can you tell me why?

ESP 8266 / 32

Any advantage one over the other? Any future feature plans that would require the 32? Just future planning here thanks :)

[Magneto] Handle infinite samples with constant memory usage

the first thing magneto does with the input sample is first expand each sample into a 10 item row/column, treat the input as a 10xN matrix, and multiply it by it's own transpose, resulting in a 10x10 matrix.

expanding out the math, it turns out that taking each sample as a 10x1 matrix, multiplying by its own transpose, then summing each resulting matrix together results in the same matrix, except for floating point imprecision. I'm not sure whether the result is more or less precise, but according to my testing it's fairly close.

https://blog.demofox.org/2017/01/02/incremental-least-squares-surface-and-hyper-volume-fitting/ suggests we can do it with even less space than a full 10x10 matrix due to the structure of the input, 19 elements instead of 100. nevertheless, even if we don't go that far, we can still save quite a bit of memory. (currently, for mpu9250 at least, we save 3*300 elements, which gets expanded to 10*300 elements, before we end up with the 10x10 matrix of 100 elements.)

However, since we'd be doing the calculations on the fly, we lose the current method of outlier rejection. If we wanted to keep outlier rejection, we'd need to find a way to do it 'online', as samples are streaming in.

Replace Mahoney and Magiwick code with include of Fusion library

https://github.com/xioTechnologies/Fusion

We should include (a for of) this library into firmware code instead of copying Magiwick/Mahoney fusion code. This will improve license compatibility and overal code support.

Indicate when IMU is calibrated

Send a packet once the IMU is calibrated (currently lies about it) so that the server can tell the user when their tracker is calibrated in GUI or/and don’t send rotation packets until IMU is calibrated.
Maybe also do a certain blink pattern once calibrated.

Idle Drift compensation

Would it be possible to implement some sort of idle compensation for drift, my thought process was that if you stay at, lets say 100 degree of rotation, and it stays between 100±1 for 5 minutes that the tracker would go into an "idle" where if after more than 5 minutes of being in that range, it shifts outside it by a single degree for more than a minute over a period of time, that it would deem it as drift and put a 1 degree offset on the tracker in the opposing direction.

of course in order to prevent accidental movement, if you shift more than 1 degree outside the range it would disable the idle and would require that tracker to stay still to the ±1 degree for more than 5 minutes to go back into it, this could help for people sitting/laying for extended times without a need to reset as often.

from my short experience the only time i have drift is over a period of time ~5m minimum per degree of rotation in the worst case,

the only way this should cause issues is if someone continually moves one degree at a time in a direction, perhapse make a setting to toggle on when you are sitting still for periods of time/adjust the 5 minute window

ESP32 Gateway

This is rather a suggestion than a bug report.

Coming from an "ESP32 background", where I use them to automate almost everything, let me chime in:

I've seen these trackers being used by some YouTubers now and must say that using WiFi to make it communicate likely isn't the best idea, since 2.4G networks are often crowded, either by neighbors or by the network itself (slow routers, lot of devices talking at once, etc). All of that makes the latency go through the roof, setup is painful and its generally a bad idea imo.

Why don't use the ESP32 bluetooth capability? Connect all of them to a central ESP32 over Bluetooth, which is then plugged directly over USB-C into the PC or Quest. This will likely decrease latency and remove the need for a router. A "gateway", if you wish.

Granted that Bluetooth is still in the 2.4G range, however the gateway is likely much closer to the trackers than any neighbor. Also there's no traffic inside that particular Bluetooth network, which is good.

This also would make pairing a lot easier by simply pressing the button on the gateway, putting it into pairing mode and then turning on the trackers holding a button too. Kinda like WPS used to work. After the initial setup, the gateway would hold the devices paired, and there would be no need to reassign IPs or something like that. It would just work.

I watched the video on ThrillSeeker and found it kinda rushed. "Oh, now you download the Arduino IDE, and compile, and assign IPs and ..." I don't get why this wasn't already set up to review for a YouTuber. It kinda pushed SlimeVR into the mud. With bluetooth pairing this wouldn't have been an issue. Compile it, ship it, tell the people "Press buttons, done".

Yes, the gateway is one more device, but the advantages quickly overrule the disadvantages.

---

Initially I wasn't going to comment, but since it's completely open-source, I thought why not. I want this to get better than it is, but I don't have time neither focus to make something like this from scratch, so feel free to improve :)

ESP8266 has solid blue light after flash, no wifi connection

No matter what I do to the firmware code in platform.ini and defines.h (I've tried the website auto writer and manually), every time I flash the code to the board, it absolutely will not connect to my network. I am now 100% sure all the pins are connected and configured correctly in defines.h. I did install the USB to UART driver by Silabs and restarted my PC multiple times in case it needed it (idk).

Some information I know right now:

• Board: HiLetgo ESP8266 (NodeMCU V2)
• IMU: MPU6050
• When the ESP is connected via micro USB, the devices shows in PlatformIO under COM4
• upload_port does not come specified in platform.ini on the current commit, so I added it myself with the value COM4
• Flashing returns as "SUCCESS"
• ESP doesn't connect to WiFi, which I've tried both hardcoding and via SlimeVR Server (which failed)
• SlimeVR Server doesn't recognize I2C device on COM4 (assuming it works correctly)

Things I've tried:

• Commenting upload_speed
• Flashing the firmware stock (defines.h still configured)
• Hardcoding WiFi credentials, both on home network and PC hotspot

I swear, the board is just doing nothing, the only time that LED flashes for any reason other than being flashed, is the exact moment I open the port with SlimeVR Server, and that's it. As I said, SlimeVR doesn't recognize, but more specifically: "Can't find an I2C on specified address, scanning for other I2C devices and returning" then I assume it returned with no result.

Wifi credentials not saving

Wifi credentials not saving when sent from the Server.

Make hardcoded credentials actually work

wificredentials.h doesn't do anything right now, tracker connects to WiFi only via WPS. Need to fix it in addition to future configuration through USB.