-
-
This is the screen shown to truck drivers, from this screen they are able to view the area/fleet around them and update their status.
-
This is the screen that a dispatcher would see from the operations center, showing them the locations and statuses of their entire fleet.
Inspiration
I really like logistics, and one of the key challenges of logistics (and management as a whole) is just knowing where your resources are and what the status of those resources is, and so being able to do that effectively is something I've been a little bit obsessed with from time to time, so when I saw the theme for this weekend, I immediately knew what I needed to build.
What it does
TruckTrack automatically reports location data to a central server to allow for effective tracking of logistics resources, in particular trucks and other fleet vehicles. In addition to this TruckTrack also enables those resources to send status update messages at a click of a button, and allows both drivers and the operations center to view all of the location and status data in real time to facilitate situational awareness.
How we built it
From a tech perspective, this project is actually quite simple, a client page uses the JavaScript geolocation API to check for changes in location, then, once found, sends updates information to the server via AJAX requests. The status indicator buttons are quite similar, sending "canned" messages using AJAX requests when clicked. For updating all data output on the client end, Server-Sent Events (SSE) messages are used to notify the client of updates and re-render the appropriate portions of the page. Data is stored in a simple MySQL Database, then pages are generated using PHP. The UI was made considerably nicer with the addition of some simple Bootstrap, and Location data is rendered using the Leaflet.js Library.
Challenges we ran into
There were a few technical issues I ran into, Firstly was implementing SSE, both with them sending updates too often, causing the application to create very unnecessary amount of network traffic, and, in trying to solve that issue, not sending when they should. This was ultimately solved by saving a hash for each connected client of the data being updated, then only sending the message if it's hash was different from the last message sent to that client. The other big issue was storing geospatial (location) data effectively, especially with the precision of data needed to see which specific street a vehicle is on. This required a fair bit of experimentation with different datatypes, and even different implementations of some data types, to finally find a way to effectively store the location data. Ultimately, solving this issue came down to figuring out and understanding how all of our different datatypes worked and where there drawbacks lie to make to good assessment of which ones to use.
Accomplishments that we're proud of
I'm really proud of finally building a simplified app. Typically, when I build apps, I build incredibly powerful apps that let you control anything and everything and use them however you want. As a consequence of that, my apps usually have massive learning curves, even for the most tech savvy people. In building this app, I really wanted to avoid that, because the target audience of this tool is often not the most tech savvy crowd, and are often against having to learn new ways to do things, just look at the backlash against ELDs. Because of that, I automated as much of this tool as possible, and where it couldn't be (like the status messages) I made sure that use of the tool could theoretically be picked up in just a few seconds.
What's next for TruckTrack
While I wrote TruckTrack into a particular use case (albeit a very widespread one), This tool is actually very versatile. For example, my college rescue squad will often spread EMTs throughout the crowd at events and it is very important to keep updated on where all of them are and what their status might be. Currently, this is all done verbally (including our locations) over handheld radios, but in order to complete patient charts, we already carry all of the equipment needed to run this tool, and by changing the text of the status messages, this could be a perfect tool for us to use. It's not just that one extra use case either, there are dozens of them that just depend on changing that text. Because of that, my future plans are to enable system administrators to customize the status message text to expand the usefulness of this tool to many more use cases.
Log in or sign up for Devpost to join the conversation.