BeamNG: Personal Micro Blog(s) - Feburary 2015

Cool stuff! Do you know what latency (input lag) we're talking here? I'd imagine there's some software latency in Android? A good Wi-Fi connection shouldn't add any notable input lag.

 

Well I often do quake nights with the computing society at uni.

We've found ping on a cheapo 2.4ghz single antenna B/G (not even N) wireless router tends to be about 5ms for 1 device connected going up to 20ms for 2 devices connected as reported from the windows ping command on a PC hooked directly via the ethernet port on the rear. This remained constant when we added the other 7 LAN PC's via a cisco 2960 catalyst series switch (including moving the one hooked direct to router onto the switch instead). This setup was chosen as the quake server itself is a wired device, we figured the 6 non server LAN machines would benefit more from only contacting the router for DHCP. Having the server connected on wireless would have forced all traffic over wireless instead of just 3 machines. The LAN machines had a flat 0 ping on one another and only gained 1ms for wifi connected devices over the shared ethernet channel. We've since started using a different router and although we havent tested figures, it seems to perform a tad better, it supports gigabit ethernet (allowing a gigabit link back to the switch, the switch has 2 ports capable of gigabit) and wireless N, still only single antenna.

So lets say best case 5ms, maybe worst case of 50ms depending on network.

Most accelerometers used in android phones are only 10Hz update rate, that is fixed. This then means accelerometer latency is somewhat variable, if you check on it exactly after its updated itself, thats essentially a 0ms latency, but it can easily reach 100ms if you check on it just before it updates.

So we're now looking at 5 to 150ms depending on network and exactly when it updates. Some phones are capable of higher update rates on the accelerometer, dont know if this needs software enabling from android or not.



That is as a rough prediction anyway.

 

Wi-Fi latency doesn't worry me, my personal testing shows that with good devices I get virtually no lag (1 ms to ISP), and you can always run it on locked channels and 5 GHz to reduce latency spikes and interference.

But what I'm asking is the Android software implementation, I've read some about it before saying there's "pretty high" latency to various hardware components with Android, but we also know this has been improved upon. The computer software side of things really isn't an issue here, it shouldn't add much latency when done right.

- - - Updated - - -

Wi-Fi latency doesn't worry me, my personal testing shows that with good devices I get virtually no lag (1 ms to ISP), and you can always run it on locked channels and 5 GHz to reduce latency spikes and interference.

But what I'm asking is the Android software implementation, I've read some about it before saying there's "pretty high" latency to various hardware components with Android, but we also know this has been improved upon. The computer software side of things really isn't an issue here, it shouldn't add much latency when done right.

 

See we were using a positively ancient wireless access point anyway.




I think regardless of android application stack latency, the biggest factor will be that 10Hz update rate on the accelerometer.

 

Yeah. But seriously, 10 Hz, where did you get that from? Seems stupidly low.

Is this a hardware limitation?

 

Datasheets. The actual accelerometer IC's genuinely don't update very quickly in their default mode. Some of them do support 100 or even 1000Hz modes, but they drain huge amounts of power (some of the 1000Hz ones you have to give a really good ground plane on the PCB to act as a heat sink) so of course thats undesirable in mobile and 10 just seems to be the standard. Rotating an app to match your phone orientation only really needs 1 or 2Hz so for 99.99% of accelerometer usage in a phone even 10Hz is overkill.
The gyroscopes usually update a little faster where present, but they only measure the rate of change in orientation and not the absolute orientation as the accelerometer does.

You also have inaccuracy of the accelerometer, they lose huge amounts of accuracy when in motion which is why for true inertial positioning you usually use a full 12 axis system (3dof each on accelerometer, gyroscope, some kind of positioning system (GPS most common) and compass, we can drop the GPS in this case and probably compass) to combine data from each. These other sensors are usually even more power hungry than the accelerometer, however they are usually switched off when not in use whereas most phones run the accelerometer from power on right through to shutdown.

- - - Updated - - -

I just wrote a huge post explaining my testing with a diagnostics app on my own android handset to enquire into its accelerometer frequency and also checked some android SDK references.

But my internet barfed mid upload and I've lost it.


You can set the sensor listener in an android app to 1 of 4 modes, normal (default and 5hz on my devic), UI (typically should be a low sensitivity/frequency mode, 10 at idle, increases to 20 with motion), GAME (fixed 50) and FASTEST which is unusual as it sits at 107Hz until I put the device down stationary and it drops to 5.0 again (presumably power saving measure as it immediately ramps up in motion). I have no other android device to test with.




I'm more interested in seeing the protocol though. Got another project I want to "exploit" the game with.

 

I have done some testing and the results seem very different to what have mentioned. I only found one sensor on my device that had a fairly low update rate. Most of them were very fast and my phone isnt exactly modern.

Sorry for the video quality, i usually record things on my phone but without setting up an elaborate series of mirrors or similar that would have been difficult.


So yeah, dont worry about it, it should be absolutely fine.

 

I don't have many sensors at all on phone compared to that. GPS, accelerometer and that's about it. Your phone may be older but was a flagship in its day. Accelerometers are MEMS devices, haven't gotten much better inn recent years.

 

It does seem to have a fair few sensors built in. I can remember i used to use it in science because its lux sensor had a far far greater range than the schools dedicated sensors. They had to cover the lights with multiple layers of tissue before you got them to a measurable level. The phone states that this one has a range of up to 10240 lux, which was way more than i have ever needed.

I find it kinda odd that they have used multiple different parts manufacturers rather than an all in one solution (STMicroelectronics, Asahi Kasei Microdevices and Capella Microsystems), i wonder if they just used what ever was in stock at the time or if they intended to use each manufacturer for each part.

 

Go on RS components or Farnell or Mouser or whoever. All in one solutions are rare.
Most integrated I have seen is an accelerometer, gyro, compass combo.
Light sensor wise, sometimes you get a sensor capable of operating in IR mode and visible mode, otherwise you don't tend to get them in combos. Proximity is just an ldr.

Once you are using separate sensors, you then just use whichever is cheapest and meets your requirements. Hence multiple manufacturers.

 

I see. Interesting stuff.

Do you know of a way I could test this on my phone?


I can see this protocol being used with many cool projects.

 

Download advanced tools from the play store, you will be able to see the raw values from the sensors as well as do many other useful things. Then you can see how fast and how much latency there is in your own device.

 

That Roamer Doe

(imported from here)

 

will we ever see crashing sound integrated into this? like the game detects when the beam is at a certain level of flexing and initiates a sound clip that gains volume and (tempo?) based on the speedof the beam deformation/ stress. would we also be able to tailor this to certain beams? (for creating a certain suspension noise like a creaky shock absorber for example)

 

I think I now understand why you made the "keep distance" AI package some time ago. Any chance that the player car was placeholder for the moving red dot there?