We wanted to see just how tossed around the packages we send out for the holidays get, so we set up an experiment. Follow Mariah and Cassy as they set out to see what really goes on in those delivery trucks!Favorited Favorite 0
Have you ever received a package in the mail that looks like it might have fallen off the truck? Then probably ran over by that same truck a couple of times? Well I wanted to know just how handled packages get when traveling to their destinations. With some SparkFun parts inside 3 identical boxes sent out through 3 different mail carriers all to the same destination, we calculated some data about their journeys.
Most packages arrive at my front door looking just as I expect. This was until I remodeled my kitchen and I had to order the same sink 3 times because they kept arriving with huge cracks through them. Through this experience, I wanted to know what a package goes through on its journey to its destination. How beat up does it get? How often is it dropped? How much force is pushed on it while traveling on a truck?
We came up with a little experiment using SparkFun parts to get some hard data. I asked Mariah to build a prototype that could read acceleration data for any movements or drops, and any force data the boxes might encounter when being stacked in a truck or facility. We created 3 identical boxes to use different delivery companies and then compare the sets of data. They traveled about 1000 miles to our Design Manager Blake who works remotely in northern Idaho and then the 1000 miles back to SparkFun in Colorado.
Each of the trackers comes equipped with 4 force sensitive resistors (FSRs), a qwiic micro 6-axis accelerometer, a qwiic redboard, an openlog with a 1GB SD card, a 10Ah battery pack, a solderable breadboard, and various jelly bean parts needed to make it all work!
There’s one part included, a super bright blue LED, that doesn’t actually add anything to the data collection circuit; this is only added to increase the current draw of the system so that it doesn’t fall under the minimum threshold of the battery pack, which is 60mA. Without this LED, the circuit draws around 35mA, and is boosted to around 80mA with it. This keeps the battery pack from entering stand-by mode and allows for the full charge to be used as it’s traveling.
Now, let’s do a quick run-down of the type of data we’re collecting on our openlog! The accelerometer will record values from 3 axes: the X, Y, and Z. This will tell us how much the package is jostled around left to right, front to back, and up and down. Initially we’d planned to include gyroscopic data as well, which would track the rotation of the package about those axes, but ran into some trouble with it that couldn’t be sorted out within the timeframe we were shooting for. We’ll just have to save that for version two!
In addition to the accelerometer data, we also have force data from our 4 FSRs; these are placed catty-corner from one another on both the top and bottom of the box, so that we can get a sense of the full force exerted over the surface. The FSRs are able to record values and then convert those into units that we recognize, such as grams or pounds. Since we didn’t expect such a small package to be put under a ton of pressure, we went with grams as our unit of choice to get a more granular (or maybe gram-ular) view of the force data.
Check out the full list of parts here!
We sent these 3 identical boxes out to our Design Manager Blake in Idaho about 1000 miles away. Now we knew that sending a box full of wired up electronics might raise some red flags, but we thought that just might create some added suspense. We named the boxes based on the shipment companies we used: Brown, Blue, and Orange.
They all arrived within a few days and Blake was able to pull the data from the microSD and give us an update. The Blue and Brown boxes arrived with a dead battery and plenty of data. However the Orange box had multiple boards and the battery disconnected inside once it arrived. Blake recharged the batteries, reconnected the Orange box, and sent them back over to us in Colorado.
Mariah and I received the boxes safe-and-sound… sort of. Blue and Orange had dead batteries and plenty of data, but Brown was delayed a couple of days and arrived with its electronics pretty battered. Like someone took a handful of the wires and pulled. Regardless we got our results from the data that was gathered and here it is!
After getting all of the data off of each respective SD card, it looks a little something like this:
As you can see, we got a ton of force data for our FSR0 (this is the top left sensor on the box); this is largely due to the placement of our little LED tent providing a much more solid surface to press against than the ESD bubble wrap around the rest of the box. In another iteration we’d likely duplicate this effect on the other sensors, or try to prevent it from being concentrated on a single spot.
Now, we can toss all of our data into a Processing sketch we put together to parse out each data type, and save those as separate files (this doesn’t run anything in the draw function, so it’s not much to look at, but it works!).
So here you can see that we have all of the raw force values for our blue box’s return data (the files for the other boxes look similar). From this, our colleague Lauren was able to create some visualizations of our values! Let’s take a look:
Above is our accelerometer data for the trip out to Blake; you can see in these charts that our orange box has significantly fewer plotted points than our brown and blue. This is because that box arrived unplugged (and with a fully charged battery, so we can assume this likely happened pretty early on in its journey). On the flip side, the brown box returned back to us unplugged, so our return data for brown is similarly cut off:
Now, unfortunately we did not take any timestamp data, nor concurrent values across all three axes in this iteration; this limits what we can specifically determine about the boxes’ trip and how they moved around. We can look at the sheer number of recordings from our accelerometer, which may give us some insight into which carrier had the most movement overall, but won’t give us a detailed account of the type of movement that occurred. These are all considerations for version two!
Lastly, let’s check out our overall force data for each box over both trips:
Here, again, we can tell that our orange and brown boxes did not record for the entirety of both trips by the fact that our scale for the number of recordings is quite different between those two and our blue box, which we know stayed running to and from Blake. Interestingly, however, our blue box did have the least variation of force out of the three, with brown having both the greatest range and highest recorded value of 1200g (which is about 2.5 lbs).
Well now we just want to do this experiment again but with even more electronics to get more extensive data! What would you have done differently and what do you think we should add to version 2?
You can check out our video on this project here!