Ultra bike race tracking using waylay

Participating in an ultra race is like riding the Tour De France from 100 years ago. Everyone starts at the same time and tries to reach the finish line as fast as possible, passing by obligatory checkpoints and passages. Unsupported. So no 3rd party support, private lodgings, or resupply. All food, drinks, and equipment must be carried or acquired at commercially available services. All this on the open roads. 

‍

The ultra race I participated in took me from Brussels to La Turbie. Along checkpoints in Huy, Colmar, Annecy and Milan where we had to stamp a brevet card. And obligatory passages over Mur the Huy, Ballon d'Alsace, Col du Grand Colombier and Pas de Morgins where we had to take a picture. This was the route I planned to take, about 1650km with 18500m of climbing. My goal was to complete it in 4 - 5 days.

There were about 40 participants, and we all got a tracker attached to our bike. These trackers would send out our location and current speed over gsm networks. This data was then displayed on a webpage for everyone to see. 

Indeed, as a Waylay employee, I quickly understood that there was a lot of potential to improve the experience and add value to the collected data.

What did I try to solve?

• Cluttered visualization provided by the tracker company (MisterTrack). My friends and family would not be able to easily see where I was. I wanted to create a custom dashboard for them with my location, speed and current position in the race.
• I wanted to add sms notifications to friends and family when I reached a checkpoint during the race.
• I also wanted to store my race data for analysis afterwards.

How did I get data into Waylay?

I analyzed the API of the dashboard provided by the tracker company and realized that I could just call the same API, as it was not protected. By calling the same API endpoints, I was able to receive data from all the trackers that were active during the race.

Once I figured out the ID for my tracker, I was ready to set up a connection to store data in Waylay. In order to achieve this, I created a task in the polling mode which was executed every 60 seconds.

Here is the template:

• First I used a callUrl sensor to fetch the latest locations of all the trackers using the API call above. 
• Then I used the transformer sensor to filter out the location relevant to my tracker
• Finally I stored that data on a (Digital twin) resource using the storeMessage sensor and forwarded the data to the Waylay Broker so we could use the same payload in reactive tasks (in order to further process the individual message by another tasks)
  

Digital Twin set-up

• I first set up a resource type called Tracker. This allowed me to define default fields for all resources of type ‘Tracker’, I also could automate the instantiation of tasks for all resources with that type just by linking all my templates to the type.
• Then I linked a resource constraint to the resource type. This made it possible to use the provisioning portal to provision my digital twin.
• So as soon as I provisioned my (digital twin) resource in the provisioning portal the task to fetch data was automatically instantiated.   

Creating my personal dashboard

• Using the resource (digital twin) of my tracker I provisioned, I’m able to create a dashboard with a map widget to show my current location and the location history.
• I also added geo-fences to visualize the checkpoints and passages on the map.
• I added a widget with the current speed, so you can see if I was moving or not.
• Lastly I added a widget to read metadata on the resource to show when I passed by the checkpoints and passages (these were updated in the notification task).

Checkpoint notifications task

• The geo-fences to visualize the checkpoints and passages on the dashboard can also be used in a rule to send notifications when my tracker enters one.
• I created a rule that did the following

• When data arrives in my digital twin resource via the Waylay broker, I checked whether the location was within one of the geo-fences I defined.
• If it was inside one of the geo-fences I sent a sms to my parents and friends.
• And I sent a Slack message to a channel with my co-workers.
• I also stored the moment of arrival in the resource metadata.

• The rule itself looked like this:

• I also linked this rule to the ‘Tracker’ resource type, so It would be instantiated automatically as soon as a new tracker is provisioned.

How much effort did I put in?

• Everything got set up quickly before the race (“between the soup and the potatoes” like we would say in Flanders). I did some testing by mocking some data and everything worked fine.
• All in all it took maybe 6 hours of work to set everything up including the dashboards, rules, digital twins, geo-fences, etc. I can hear you think ‘That's a lot of work for only one tracker’, but this implementation was completely generic, so I could have provided the same functionality for all the participants without any extra effort. So I could have scaled up the same tasks and dashboards for thousands of trackers without issue! 

Detected issues during and after the race

• Tracker issues: the trackers only update every 3 hours, most races have trackers that update every 15 minutes.

• This gave issues with my notification task, since I wouldn’t stay at a checkpoint long enough for the update to be inside the geo-fence (except when I got lucky a few times that the update of the tracker was just when I arrived). So the logic wouldn’t always trigger.
• When I got lucky that the update was just in the geo-fence, then my friends and family got spammed with messages every 15 minutes because the update would stay there for the next 3 hours. (They weren’t happy about that, especially during the night 🙈)

Conclusion

Trackers

• The frequency of the data being sent is a vital part of information you need to know to be able to implement effective rules. I expected data to be sent every 15 minutes, but the data only was sent every 3 hours. If I knew that beforehand my notification rule would have looked a lot different.
• Next time I’ll try to take my own gps tracker so I have full control of the frequency data is sent with and I can build my rules accordingly. 

No custom software

• All out of the box functionality available on Waylay
• Only some basic knowledge of JSONPath and javascript was required

Analysis after the race

As you can see in the graph showing my speed, the data isn’t fine-grained enough to get a lot of insight from, but I think you can see that I didn’t get a lot of sleep 🥱!

I have another race planned in the Pyrenees in September. I will also try to get my tracker data into Waylay during the race and set up the same functionality for my friends and family (or anyone who is interested in it). 

If you want an in-depth run through - please contact Waylay.

‍
‍

Curious about the preparation for my next race? Please follow https://www.instagram.com/antondj_/’

Final note

For the people curious about my final result. I ended up scratching from the race at the last checkpoint in Milan after about 1300km of riding with 16000m of climbing in 3 and a half days (while I was in third position). I had a fallout with the race organizers, there were clear rules set from the start which they enforced on some riders and did not on others. Making it an unfair race which I didn’t want to be part of any more.