SlimeVR
[Feature Request] Queue-Like System.
I'd like for there to be an option/toggle called 'Queue' or something like that, which basically enables the usage of a queue-like-system.
Currently, residential people may face issues with using slimevr-firmware-flashed trackers (this inclues DiY, and vanilla/stock SVR trackers) due to possible congested channels, leading to non-smooth tracking experience, and spikes in the ping of individual/all trackers, this is present within the direct discord server of SlimeVR, and there has been many posts on this already.
My presented suggestion: A queue-like system, where instead of one tracker sending 96 KBS (96 KBS at rapid/constant movement, 8-16 KBS at near-idle) constantly (no end, no pause, sort of like DDOSing when there's multiple trackers), one tracker will only send the necessary data when given a signal from the server.
A proposed idea on how this could work:
- Server sends a packet to the tracker, the tracker returns with data (location/rotation/battery/etc) No other trackers send their data, until the server gives it the signal.
This may not stop a tracker alone from simply sending concurrent/mass requests, so this would also need to be implemented directly into the firmware of the tracker, SlimeVR/SlimeVR-Tracker-ESP.
Of course, there may be LAG, however this can be mitigated and/or fully nullified by leveraging existing filters like prediction. And if you use a third-party application to smooth the trackers, this should not be a big problem.
This suggestion and proposed solution may provide better smooth tracking for people in residential, and potential non-residential areas, so they won't need to buy a separate router, which may not even help.
I used Windows 11's hotspot for better performance with 11-point tracking. Just for reference with 11 point tracking, and 96 KBS of constant movement, this becomes around 1.056 MB/s a second of constant packets, resulting in non-smooth tracking, where I could only use a few of my trackers (like 4-5) and then tracking suddenly becomes smoother again.
If I connect the trackers to my router, I get even worse spikes, and I can get higher MS.
I'm going to see if I can create a new branch implementing this feature both in the firmware repo, and this repo.
I don't know if fair queues would be the correct congestion algorithm we need. I can see it being useful if it would prioritize what the skeleton needs but that sounds overly complex.
My recommendation is that we should implement a congestion control algorithm that allows us to send packages at minimum delay but with package loss in exchange. There is one such algorithm wrote on paper but I'm not sure if it's been implemented anywhere
I don't know if fair queues would be the correct congestion algorithm we need. I can see it being useful if it would prioritize what the skeleton needs but that sounds overly complex.
My recommendation is that we should implement a congestion control algorithm that allows us to send packages at minimum delay but with package loss in exchange. There is one such algorithm wrote on paper but I'm not sure if it's been implemented anywhere
-
Is it truly that complicated? First time making changes to firmware code, or making firmware code in general, however I took a look in main.cpp in the firmware on the main branch, and it doesn't seem all that complicated, with the way it's currently set up, in fact it's pretty small.
-
When sending packages at minimum delay, can you elaborate on that? What do you mean 'but with package loss' in exchange?
Disclaimer, i have not much knowledge about details on WiFi The main problem on WiFi is to catch a sending spot. If you now add the server to request each packet you nearly double the needed sending spots on the air. Also managing this Spot is on a low layer that cant be changed on the ESP/WiFi Spec (WiFi4 for ESP8266 when i remember correctly)
Most "easy" way to control the load on WiFi would probably be to reduce the TPS for each tracker. Maybe depending on position of a tracker (hip, chest lower TPS than like arms, legs) Making sending values async from calculating could help a little.
I didn't implement the algorithm, however I focused on simply implementing the queue-like feature. There's no 'toggle' to simply resume default behavior implemented in the ESP. https://github.com/WuDoMiRa/SlimeVR-Tracker-ESP/commit/ab2056b00b94e491eb838265368bc81b14e6f06c
However, you can achieve ABOUT the same effect as before by simply sending requests to all the trackers at once continuously instead of one by one.
As we use fifo stuff on communication with the IMU and SensorFusion, you want still to run the tracker on full speed. But only affect the sending of the gyro/accel data less often. (also for axel data not sure if you want to send the max values to the server. Depending for what it is used on it) i belive for most sensor it is here, but you have to check all the sensors if they have a custom function for that: https://github.com/SlimeVR/SlimeVR-Tracker-ESP/blob/main/src/sensors/sensor.cpp#L53 Sleeping the ESP is till now not rly a option as its wakeup time is too long, or would shutdown the modem.
As we use fifo stuff on communication with the IMU and SensorFusion, you want still to run the tracker on full speed. But only affect the sending of the gyro/accel data less often. (also for axel data not sure if you want to send the max values to the server. Depending for what it is used on it)
That should be already handled in the commit.
Sleeping the ESP is till now not rly a option as its wakeup time is too long, or would shutdown the modem.
What would be a viable alternative then? Just let it run no code uselessly until it's told to update? I mean that is an option but.. taking into consideration this comment, are there no other alternatives?
Not sure. I did not a full deep dive into all energy savings. I think the best would be just without delay restart it again. it gives it time to fetch wifi stuff faster again. Wich will help the connectivity. The esp8266 is on its limit of speed anyway with the current sensorfusion enabled. (BNO085 and ICM20948 is not affected by this as they have sensorfusion on the IMU.)
This is implementation code within the Server now. https://github.com/WuDoMiRa/SlimeVR-Server/commit/46a06a3bb447d6eb3d80d561f72a9612ed5282f8
So I can start testing this method. NOTE: There are NO settings, no configuration available here YET, as well as no GUI changes. Only code that works to the implementation, so testing can be done.
EDIT: There's an error in that commit, this followup commit fixes it, and now it builds successfully. https://github.com/WuDoMiRa/SlimeVR-Server/commit/a4f445f84a7c8d041c4ed7ecd71971f2e79327f0
Pushed. These are now changes to the server. https://github.com/WuDoMiRa/SlimeVR-Server/commit/bc75c6e25748aa18651ecadbf27176ac31892e61
The additional changes are also in here (more recent than the first commit above to change a value): https://github.com/WuDoMiRa/SlimeVR-Server/commit/1dd3e2deccfe56d3f259f08ff1724a7f8e867cf9
It is NOT ready for merging as there's stuff like configuration to worry about, however, here are statistics. One tracker at constant movement now only sends around 72 KBs, instead of the previous 94. We reduced the size of the packets by like around 22%.
So, in summary: Trackers no longer:
- Continuously spam packets to the router/AP, until they are requested to by the server.
And the server:
- Requests data from trackers sequentially with 10 ms intervals.
I am able to test with 2 trackers and even one. I'm going to test with full 11 trackers.