slimevr / slimevr-tracker-esp Goto Github PK

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

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?

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

Add firmware support for ESP32.

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.

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.

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

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.

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

MPU6050 wasn't properly tested and returns 0s.

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

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.

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

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?

fff

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.

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

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.

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.

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

[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

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.

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.

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

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

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 :)

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.

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.

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

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

Both reports of this issue are from ICM 20948 users.

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.

Wifi credentials not saving when sent from the Server.

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

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.

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.

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

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.

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.

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.

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?

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

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.

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.

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...

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

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.

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)))

[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

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.

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