 Todd Oates
|
Posted: 1 October 2009, 9:15 AM
Keith, that error is funny but it also suggests to me that the map is wrong for 11 and 12 (where I lost a lot of time too!) or is it just wishful thinking?
|
|
Bryan
|
Posted: 6 October 2009, 10:12 PM
A Future Alternative to Sportident?
Apologies for the long post.
Here are the results of the GPS test I did using Michael's data. The basic conclusion is that GPS offers an alternative to Sportident (with extra information available to the competitor).
********************************************************************
Michael's email about the sample GPS data to me:
----- Forwarded Message ----
From: Michael Wood
To: Bryan Teahan
Sent: Thu, October 1, 2009 2:02:56 PM
Subject: Test Files for GPS
Heres a couple of files. The control locations are waypoints, they have no inherent order in GPX but Ive named them St/Fin, C1, C2 etc. The track was as I rode the course (a pretty funny one as there were optional controls that were out-and-back but
Ive pretended that this was a regular course).
No SI data but by inspecting the track in Mapsource here are some approximate answers.
St 11:53:00
C1 12:09:00 00:16:00
C2 12:17:00 00:08:00
C3 12:39:00 00:22:00
C4 12:56:00 00:17:00
C5 12:00:00 00:04:00
C6 13:13:00 00:13:00
C7 13:31:00 00:18:00
C8 13:40:00 00:09:00
C9 13:56:00 00:16:00
C10 14:04:00 00:08:00
Fin 14:20:00 00:16:00
The most interesting thing is, can you create an algorithm that says I went to each control (within a certain margin for GPS error).
And how big does that margin have to be for this particular case.
Best regards, Michael
********************************************************************
I've created a script to take the control GPS data, create intersection points with the GPS tracks and return split times, GPS errors and elevation data.
Example Details shown for each split:
eg C2 Split:
Minimum Distance from GPS Track to control: 23.14 m
Cumulative Distance: 4.34 km
Cumulative Rise: 113.44 m
Cumulative Fall: 51.43 m
Cumulative Time: 24.46 mins
Details shown on ST/Fin marker:
Total Distance: 21.56 km
Total Rise: 928.63 m
Total Fall: 930.08 m
Total Time: 234.35
Number of Controls: 10
Number of GPS Points: 1529
Highest Point: 420.71 m
Lowest Point: 39.07 m
My analysis:
It would require more examples and testing to fine tune it.
The first trkpt had to be discarded as it contained a negative elevation. The last trkpt had to be disarded as it was 1 hr and 26 minutes after the last one. Universal date and time caused a small hiccup as the date changed during Michael's course and he was on the course after midnight!
A finer time calculation could be done by interpolating the time of the intesection point on the track (the difference would be fractional as track points are generated every few seconds).
Also, there were many track points around the start/finish so more work is required to end up with only one start/finish point and time.
I needed to use geometry routines to calculate intersection points of control with the tracks.I also needed to use a routine to calculate distance in kms travelled between two lat/long points via the shortest great circle.
Execution time was less than 1 second for 10 controls with 1528 GPS points.
Advantages compared to Sportident is the ability to show distance travelled and rise and fall (and also the highest point and lowest point reached on the course).
A Google kml file was created showing the split points created and each placemarker has detailed split information. Total times and info are shown in the ST/FIN placemarker.
The results are shown here in Google maps:
http://www.omaps.co.nz/OM/splitstest.htm
For each control the minimum distance in metres from the track to the control is shown. This ranges from 0m to 23m. It wouldn't take much to have a warning saying you didn't visit a control - the margin of GPS error could be found by testing more examples.
Cheers,
Bryan Teahan
********************************************************************
Micheal's response:
----- Forwarded Message ----
From: Michael Wood
To: Bryan Teahan
Sent: Tue, October 6, 2009 12:20:47 PM
Subject: RE: Test Files for GPS
Wonderful! Pleased for you to report.
This is not a going system, this is an experiment to see whether the concept would work when GPS devices are more accurate than they are today.
There are lots of sources of error in this test. The accuracy of the competitors GPS (Garmin 60CSX) and the accuracy of the control
points are generally regarded as being within 15m and these could conceivably combine to make a 30m discrepancy possible (for a competitor who went to each control). There is a particular problem before the start and after the finish when the competitor is stationery or moving around slowly but the GPS is recording the out-of-race data can interfere with the good stuff.
However these are just challenges to overcome. This is most encouraging.
Best regards, Michael
|
|
Greg
|
Posted: 7 October 2009, 12:54 AM
23m, I've been within 23m of a control and not been able to find it, the biggest problem is that the gps are not actuate enough, there are lots of things like 'satellite drifting' later in the day etc.(from an attackpoint discussion)
|
|
Greig
|
Posted: 7 October 2009, 1:09 AM
It would be interesting to have a few runners use GPS at an event and see how close they are to each control to know if the margin of error is actually 30m or if this is the worst case and not likely to be seen. I'd hate to be disqualified just because I didn't get enough satellites above me at the right time so a wee way to go yet. It seems some progress is being made.
|
|
Bryan
|
Posted: 7 October 2009, 1:54 AM
I'd agree that the GPS is not accurate enough yet to prove that someone has visited a control.
However, with current technology, using the old system of clip cards along with GPS offers an alternative to SportIdent. Splits can be calculated along with the ability to show your actual route with rise and fall - to my mind this would be better than Sportident. No purchasing of expensive software/hardware and and no putting out of bricks (or periodic brick maintenance) and no setup required. People just turn up with their GPS watches and turn them on when they start
and after they finish, they could see their course in Google earth or Google maps and their splits could be calculated via a program.
I would still like to compare actual Sportident splits against calulated GPS splits so if someone has some or wears a GPS logger next time they compete on a Sportident course, I would like to do some further tests.
|
|
The Map Guy
|
Posted: 7 October 2009, 8:28 AM
Think you need to have the GPS set to record minimum time (1 second) rather than minimum distance (10m ?). Not sure what the GPS watches record.
|
|
Michael
|
Posted: 7 October 2009, 1:26 PM
Good point Map Guy. I find 10m is mostly OK for mapping and I like the idea that I'm not storing lots of points while I'm standing still. But for a competition we might as well measure position more often. Bryan I've got another race I did last night but I might instead wait until I generate another one with more points. And at an event where we can get SI data. Got any suggestions about the start and finish split - they must be hard for your method to sort out! Other than reminding the GPS wearer to stop track recording ASAP after the finish!
|
|
mark
|
Posted: 8 October 2009, 4:13 AM
30 metre accuracy for foot orienteering is not good enough, but isn't it ok for MTBO?
I've been looking at a NASCAR tracking system for work. It is interesting to see that they claim 2cm accuracy with their GPS unit. It is a little bit too big to stick on your mountain bike though.
(The NASCAR GPS is queried 5 times per second.)
|
|
Michael
|
Posted: 8 October 2009, 5:48 AM
Yes you are right Mark, it's "just" possible but unlikely that there could be little complexes of dense tracks under 30m apart. But long-distance MTBO provides a nice testbed for experimentation, while we wait for GPS's to get better.
Sometime I'd like to try getting the data into Routegadget. The map and controls I can do. Bryan, can you generate a splits file in the required format from my test data? I don't know the specification but the OE2003 software that most clubs use complies with its csv output. And (maybe Greg) how do you put your GPS track into RG instead of manually clicking your way through the course?
|
|
Greg
|
Posted: 8 October 2009, 6:18 AM
GPS link at top of the page, simple upload, drag and click (and click, and click and click to get it to match)
|
|
Bryan
|
Posted: 8 October 2009, 8:43 AM
Michael, can you send me an example splits file and I'll produce a splits file from your test data.
|
|
Michael
|
Posted: 9 October 2009, 5:11 AM
Another step forward - successfully loaded the GPS test into RouteGadget. The "event" is called MTBO/GPS/Test and its on 13 Sep 09.
If you try an animation for plain "Michael Wood" this is me putting my route in by clicking as usual, and the timing information comes from the splits file that Bryan generated. Must have a look at that, the last split and the total time seems to be too long.
If you try an animation for "GPS Michael Wood" this is me putting in my route via GPS (thanks Greg). You have to be patient - there's a big pause at the start before it gets going - presumably between switching on the GPS on and starting the ride. There's a similar pause at the end before the marker evaporates. But the fact that the timing comes from the GPS track (in this case set on 10m recording) means that you can see me whizzing down the hills and crawling up the other side. Interesting - if everyone had a GPS then RG wouldn't even need the splits file
|
|
Greg
|
Posted: 9 October 2009, 5:21 AM
The GPS route doesn't use the splits file at all, it is all inside the track data, hence why you get the slower and faster bits. I've done my GPS routes for Auck and Cant Champs and can quite clearly see the difference between my actual speed route and a route that where each leg has a consistent speed of running length/split time.
|
|
Michael
|
Posted: 9 October 2009, 7:39 AM
So the whole notion of discrete "splits", which seemed like such a great leap forward with the Casio watch, and taken further by electronic punching, might be overtaken by continuous recording. Still, our game involves moving between discrete points, so maybe the split times will endure.
|
|
Bryan
|
Posted: 9 October 2009, 10:04 PM
The calculation of the first and last splits needs some fine tuning
which I will attempt to do with more examples. Really an official start and finish time should be obtained separately from the start and finish clocks. Alternatively, unlike
the 'normal' splits which are just calculated from the closest intesection track point to the control, the start and finish times
could be better calculated as the latest (for the start) and
earliest (for the finish) track point near enough to the start and finish points. If tracks are generated every second it should be reasonably accurate - really only the finish time needs to be super accurate.
|
© Ruffneck Productions