Open junyay opened 10 months ago
Hi @junyay!
Yeah this is an ongoing problem with more recent iOS versions, in that the CLLocations tend to lie dramatically about horizontalAccuracy in some indoor conditions. The location will be 100+ metres from the real location (sometimes several hundred metres or more), but the horizontalAccuracy will be 10-30 metres. Obviously wildly wrong horizontalAccuracy values.
Those mess up LocoKit / LocomotionManager's sleep/wake cycles, causing incorrect wakeups and recording of imaginary paths during longer stationary periods (eg at home overnight).
Ultimately it needs to be fixed by the Location Services team at Apple, but filing bug reports with them is usually pure futility. So in the meantime I built the Trust Factor system into LocoKit, which is designed to learn when to distrust the reported horizontalAccuracy values.
Unfortunately for LocoKit's Trust Factor system to work you need user feedback, marking drifting samples as stationary, then the CoordinateTrustManager needs to be run as a background task each day to update the calculated CoordinateTrust (Trust Factor) values.
Have a look at the related code in Arc Mini to get a feel for what's needed.
An alternative workaround, until Apple sort it at their end, could be to modify LocomotionManager's startSleeping()
method, changing the locationManager.desiredAccuracy
setting to 100 metres instead of 1000 metres, so that when in sleep mode the CLLocationManager is still requesting reasonably high accuracy. That should hopefully reduce the risk of absurdly wrong horizontalAccuracy values, but at the cost of higher energy consumption while stationary.
I'm very appreciative of your response. I'm glad to hear that you have already modified the desiredAccuracy in startSleeping according to my suggestion, and there was no issue of positioning drifting on the first day. If you encounter any other problems in the future, feel free to consult me anytime. I wish you all the best!
Hello, after several days of testing, we still found that the positioning is unstable. Should we adjust the value of desiredAccuracy to make it more precise?
Yes you could try forking LocoKit and in your fork edit the startSleeping()
method in LocomotionManager, changing the locationManager.desiredAccuracy
to a lower value. Try 100 metres instead of 1000, and see what effect that has.
I have already tried setting it to 100, but the effect was not satisfactory. Maybe I should try a more precise value?
Hmm. I think if you set it much lower it will impact energy/battery use.
I think the next step would be to increase the sample smoothing, to reduce the risk of bad location updates causing wakeups from sleep mode.
In ActivityBrain.swift, try changing these lines, by adding 2 to each:
internal static let minimumWakeupConfidenceN = 6
internal static let minimumConfidenceN = 4
internal static let minimumRequiredN = 4
So try something like 8, 6, 6.
There's also an iOS bug in current iOS versions that causes the Core Location to lie quite dramatically about horizontalAccuracy. For example it will provide CLLocations with horizontalAccuracy of 10, when the location is more than 100 metres from the real location. This iOS bug messes up the maths quite badly! And can persist for several minutes, when it happens.
If the above changes don't help, then I suspect you'll be getting hit by the iOS bug. The bug only happens in some locations - typically taller buildings in built up city areas. Unfortunately so far there's nothing we can do to work around that iOS bug. Just have to wait and hope that Apple fix it in an iOS update someday.
I am currently using pod management, and your ActivityBrain component is not open-source, so I cannot modify its value directly.
Oh! LocoKit hasn't supported CocoaPods for along time! Or at least, the pods haven't been updated in years.
Make sure you're using Swift Package Manager, and pulling from the head of core-ml branch.
ActivityBrain and all of LocoKit has been fully open source for several years now. Presumably the last pod update still points to a version before that transition.
At night, when the phone is in a static state, the positioning will be erratic and deviate more than 100 meters.