[Ovmsdev] Locations and scripts
Michael Balzer
dexter at expeedo.de
Thu May 30 16:29:22 HKT 2019
This seems to be a specific issue of the roadster GPS. I never had or heard of a false alert from the modem GPS.
Regards,
Michael
Am 30.05.19 um 04:37 schrieb Greg D.:
> Given Steve's data, a filter would seem to be the best answer to the sporadic Flatbed alerts. If we're forced to use a distance threshold, 2km seems a bit
> large to be a GPS error. Even 1km is big, but again given the data, that should be sufficient. I think I've only gotten the alert twice in the over 4 years
> that I've owned the car. It's parked in a garage with a second story overhead, and a metal sectional door to the outside.
>
> Greg
>
>
> Mark Webb-Johnson wrote:
>> Steve,
>>
>> Great work. Thanks for tracking this down.
>>
>> The intent of the ‘flatbed’ feature was to alert the user of the car moving while parked. I don’t think we’re ever going to be able to alert early enough for
>> the owner to be able to rush out and stop the theft (even if that was a wise things to try to do); so perhaps the solution is to simply increase the
>> threshold. The difference between 500 metres and 2,000 metres, for example, would not impact the use case much. I suggest that we simply increase the theft
>> alert radius to 2,000 metres, to workaround this issue.
>>
>> As to the GPS data itself, perhaps we can smooth out readings to reduce spikes and invalid values? 200kph is 55 metres in one second. We get readings from
>> the roadster every 10ms, and it is not reasonable to see a difference of 640m or 753m between neighbouring readings. From your data, it seems that the
>> invalid readings last for some time (several consecutive readings), so it is not trivial. Perhaps a kalman filter?
>>
>> https://en.wikipedia.org/wiki/Kalman_filter
>> http://www.cs.unc.edu/~welch/kalman/Levy1997/index.html <http://www.cs.unc.edu/%7Ewelch/kalman/Levy1997/index.html>
>> http://kalman.sourceforge.net/index.php
>> https://github.com/lacker/ikalman
>>
>>
>> Some people talking about the issue here:
>>
>> https://stackoverflow.com/questions/1134579/smooth-gps-data
>>
>>
>> I suspect that when the Roadster is in motion, the GPS uses velocity to smooth out its location. But when the car is parked, it doesn’t have that capability.
>>
>> Regards, Mark.
>>
>>> On 30 May 2019, at 8:08 AM, Stephen Casner <casner at acm.org <mailto:casner at acm.org>> wrote:
>>>
>>> I caught one! (An instance of a "vehicle on flatbed" alert while
>>> recording a CAN log of the GPS data.)
>>>
>>> What I see is a sharp deviation in the GPS position at the time of the
>>> alert. So it may just be that I should set the alert threshold to a
>>> larger value, or perhaps that the default value should be increased.
>>> We might also make the trigger more robust by considering the rate of
>>> change to be consistent with moving the car rather than a shift in GPS
>>> position calculation.
>>>
>>> The deviation that triggered the alarm was followed by a deviation of
>>> larger magnitude about an hour later, but repeat alarms are disabled
>>> until the car is turned on and then parked again. The duration of my
>>> recording was approximately one day; I should probably gather more
>>> data to see if I get any deviations that are even larger.
>>>
>>> I've attached the data and my analysis for others to view. It is a
>>> zip file containing four files:
>>>
>>> location.crtd is the recording of CAN bus 1 with a filter for ID
>>> 0x100 and a hack to keep only records with data.u8[0] = 83, 84 or
>>> 85.
>>>
>>> location.graf is the output of an awk script I wrote to graph the
>>> deviations in the GPS latitude, longitude and altitude values.
>>> These are output as a sequence of three X,Y timeseries with the X
>>> values being GMT timestamps and the Y values being the difference
>>> in the GPS coordinate values relative to the first sample in the
>>> recording. The latitude and longitude values are in degrees; the
>>> altitude values are in megameters to make them similar in scale to
>>> the lat/lon. A fourth timeseries shows the calculated distance
>>> relative to the first sample, again in megameters. A fifth
>>> timeseries shows artificial values to mark GPS lock transitions;
>>> there was no transition near the time of the alert. I translated
>>> the CRTD timestamps to absolute time by equating the last log
>>> timestamp with the log file write time, so there may be some
>>> inaccuracy. The notification I received on my phone was at 21:30
>>> GMT and in the data the spike begins at 1559079188.763 = 21:33:08.
>>>
>>> wander.png is a large screenshot of the graph presented by a
>>> little graphing tool named graf that runs under X on *nix and is
>>> good for data exploration. If you are interested you can find the
>>> source at https://github.com/kernelsid/graf
>>>
>>> zoomed.png is a screenshot of the same graf session zoomed in on
>>> the spike that triggered the warning.
>>>
>>> The distance that triggered the warning was 640 meters, greater than
>>> the 500 meter default threshold. The larger distance that occurred
>>> about an hour later was 753 meters.
>>>
>>> -- Steve
>>>
>>> On Thu, 23 May 2019, Stephen Casner wrote:
>>>
>>>> Finally, after some travel and other delays, getting back to this
>>>> question of the false flatbed alarms. I've started logging with:
>>>>
>>>> OVMS# can log crtd /sd/location.crtd 1:100
>>>>
>>>> Plus I've hacked the filter function in canlog to save only those
>>>> frames with data.u8[0] = 83, 84 or 85, so the total is about 5MB per
>>>> day. I can leave that running for a while.
>>>>
>>>> -- Steve
>>>>
>>>> On Tue, 2 Apr 2019, Mark Webb-Johnson wrote:
>>>>
>>>>> The 'can log crtd ...' would be fine. That logs directly to disk, and would be the easiest for a replay (to try to recreate the problem).
>>>>>
>>>>> I don't think there is any easy way to pre-filter for B1, so the whole of ID 0x100 would be fine.
>>>>>
>>>>> If we can get a full crtd trace around the time of the problem, then get told 'I got a text notification of vehicle on flatbed at 7:50pm on 4th', we can
>>>>> narrow it down and replay just that part.
>>>>>
>>>>> Regards, Mark.
>>>>>
>>>>>> On 2 Apr 2019, at 2:53 PM, Stephen Casner <casner at acm.org <mailto:casner at acm.org>> wrote:
>>>>>>
>>>>>> I think Mark is requesting "can log trace" rather than "can log
>>>>>> crtd". For the former you have already implemented rotation of
>>>>>> the log files based on max size as configurable in the web UI, right?
>>>>>>
>>>>>> -- Steve
>>>>>>
>>>>>> On Tue, 2 Apr 2019, Michael Balzer wrote:
>>>>>>
>>>>>>> I've used the trace command to log high volume CAN traffic, that's no problem (at least with a recent module having the SD speed fix).
>>>>>>>
>>>>>>> The tracing just lacks a file rotation, but that shouldn't be hard to add.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Michael
>>>>>>>
>>>>>>>
>>>>>>> Am 02.04.19 um 04:58 schrieb Mark Webb-Johnson:
>>>>>>>> I am not sure if the SD is fast enough to store can log files. It would not be too hard to start/stop logging in javascript (without code changes).
>>>>>>>>
>>>>>>>> Regards, Mark.
>>>>>>>>
>>>>>>>>> On 2 Apr 2019, at 10:28 AM, Stephen Casner <casner at acm.org <mailto:casner at acm.org>> wrote:
>>>>>>>>>
>>>>>>>>> Well, for my car this event has occurred twice in a few months, so the
>>>>>>>>> idea of running a CAN bus dump in a wifi session all the time is not
>>>>>>>>> practical. What we would need would be a CAN bus dump to rotating
>>>>>>>>> files, like the error message logging can do.
>>>>>>>>>
>>>>>>>>> -- Steve
>>>>>>>>>
>>>>>>>>> On Tue, 2 Apr 2019, Mark Webb-Johnson wrote:
>>>>>>>>>
>>>>>>>>>> Steve,
>>>>>>>>>>
>>>>>>>>>>> What should I look for when this false alarm occurs? Is it likely
>>>>>>>>>>> that the alarm is issued when stable GPS operation is restored, so
>>>>>>>>>>> what I really would need to see is a log of conditions before the
>>>>>>>>>>> alarm?
>>>>>>>>>> What we would ideally need would be at the time of the issue:
>>>>>>>>>>
>>>>>>>>>> metric list v.p
>>>>>>>>>> CAN bus dump (can1) ID #100, B1=0x83,0x84,0x85
>>>>>>>>>>
>>>>>>>>>> I appreciate that is hard. Perhaps just leave a CAN bus dump running
>>>>>>>>>> over wifi throughout the event? You could leave that running for
>>>>>>>>>> hours. We could then replay that back through a box to recreate the
>>>>>>>>>> issue.
>>>>>>>>>>
>>>>>>>>>>> And now that I have issued some messages in the app, how do I switch
>>>>>>>>>>> back to other functions? Is there a way to make the keyboard drop and
>>>>>>>>>>> then find the buttons at the bottom of the screen? (I realize that
>>>>>>>>>>> restarting the app would be a solution.)
>>>>>>>>>> Just click on the screen, away from the keyboard.
>>>>>>>>>>
>>>>>>>>>> Regards, Mark.
>>>>>>>>>>
>>>>>>>>>>> On 2 Apr 2019, at 5:47 AM, Stephen Casner <casner at acm.org <mailto:casner at acm.org>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Mark,
>>>>>>>>>>>
>>>>>>>>>>> The false alarm occured again a few minutes ago. I wanted to use the
>>>>>>>>>>> web shell UI to check some status, but using the new messages feature
>>>>>>>>>>> of the iPhone app I found the wifi was wedged again. After I turned
>>>>>>>>>>> wifi off and then back to client mode I would log in from the web
>>>>>>>>>>> again. I issued a location status command that indicated good lock.
>>>>>>>>>>>
>>>>>>>>>>> What should I look for when this false alarm occurs? Is it likely
>>>>>>>>>>> that the alarm is issued when stable GPS operation is restored, so
>>>>>>>>>>> what I really would need to see is a log of conditions before the
>>>>>>>>>>> alarm?
>>>>>>>>>>>
>>>>>>>>>>> And now that I have issued some messages in the app, how do I switch
>>>>>>>>>>> back to other functions? Is there a way to make the keyboard drop and
>>>>>>>>>>> then find the buttons at the bottom of the screen? (I realize that
>>>>>>>>>>> restarting the app would be a solution.)
>>>>>>>>>>>
>>>>>>>>>>> -- Steve
>>>>>>>>>>>
>>>>>>>>>>> On Mon, 1 Apr 2019, Mark Webb-Johnson wrote:
>>>>>>>>>>>
>>>>>>>>>>>> I don't see this on the Model S vehicle.
>>>>>>>>>>>>
>>>>>>>>>>>> I suspect the issue is not handling GPS lock indicator correctly
>>>>>>>>>>>> in the vehicle modules. For the roadster, we use ID#100, B1=0x85
>>>>>>>>>>>> (GPS direction and altitude), B2==1 to control this, but that was
>>>>>>>>>>>> always a 'best guess' without much data to back it up.
>>>>>>>>>>>>
>>>>>>>>>>>> Regards, Mark.
>>>>>>>>>>>>
>>>>>>>>>>>>> On 31 Mar 2019, at 11:12 PM, Stephen Casner <casner at acm.org <mailto:casner at acm.org>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Mark,
>>>>>>>>>>>>>
>>>>>>>>>>>>> This message reminds me to mention that both Timothy Rodgers and I
>>>>>>>>>>>>> have received false alarm car-theft notifications from OVMS. Have
>>>>>>>>>>>>> you? I presume these are caused by temporary inaccuracy in the GPS
>>>>>>>>>>>>> signal.
>>>>>>>>>>>>>
>>>>>>>>>>>>> -- Steve
>>> <gps.zip>_______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>
>>
>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20190530/920ea5a5/attachment.htm>
More information about the OvmsDev
mailing list