Software apps and online services
Acceleration is what makes an object change its velocity: when a force of sufficient strength is applied to an object and makes it slow down, speed up or change direction acceleration has occurred. It is a fundamental characteristic of our experience of the world and a core concept in the mental tool box we use to make sense of that world.
Not only is it exhilarating to experience, it is also fascinating and educational to analyse. Being able to visualise the forces associated with dropping or throwing a ball, or an accelerating rocket, or seeing what happens when a moving object hits a wall, provide unique insights into this building block of creation.
The project will show you how to use a micro:bit and IoT to analyse acceleration over a time period. You can use the code and techniques described here to measure the acceleration that applies to any moving object that you can fix a micro:bit to.
Below is an example of a visualistion of acceleration: the chart shows real data from an object moving in a plane. I won't say much more about it right now - I encourage you to look at the acceleration profile and try to infer what is going on (e.g. is it a ball bouncing, or a head rolling, or something else?). The final section of this blog reveals the real world event that is represented below.
One of the great features of the BBC micro:bit is it's onboard accelerometer. Many a young learner has spent loads of productive time reading data from the accelerometer and using it in all sorts of creative ways. I've seen countless RC cars that are controlled by tilting, gloves that act as controllers, some very clever balancing robots and even gesture based musical 'instruments'.
But the accelerometer also has great potential as a learning tool to support the perennial speed / distance / time triangle that is so important, ostensibly in physics but in so many spheres of knowledge. What better way to teach acceleration than by getting young learners to witness an event, then review the forces behind that event?
In this blog I am going to show you how to:
- Use a micro:bit to collect a pile of accelerometer readings. This micro:bit will collect the data 'remotely', which means it will collect the data during the event and store it on the micro:bit, to share later (I'll explain why in a bit).
- Once the event we are measuring is complete, we'll then use the Wi-fi based XinaBox IoT starter kit for micro:bit (which I refer to here as our micro:bit gateway) to take that data and to transfer it to an IoT platform.
For this example we will throw a ball between 2 people then fling the data onto the Ubidots IoT platform.
The micro:bit includes radio functionality, which can be used to enable a Bluetooth connection between a micro:bit and another device (NOT another micro:bit though).
In some circumstances it is possible to transmit the data as you collect it, using either radio or Bluetooth. This approach did not suit the circumstances that led to this blog though. When I was asked to look at the real world problem that generated the chart at the beginning there were some specific challenges to consider:
- It was critical that the data did not get lost. I needed to store the data during the run, then extract it later. I could not afford for radio packets to go missing or for a Bluetooth connection to drop out. Saving the data during the run means we can retrieve it at our leisure afterwards, and if that data retrieval fails we can keep trying.
- For reasons I will briefly explain later, during the acceleration event (which I will call a run henceforth) I wanted to use ALL of the processor power to take accelerometer readings. If I transmit the data during the run it reduces the amount of data we can sample, which impacts on the quality of the data.
- I wanted to store a LOT of data so I needed to ensure minimal memory was being used by non-essential processes. The production-level data collection program (not included here) really stretches the little micro:bit to its limits!
- The object that is moving in the run moves over quite a distance. It is risky to have a receiver in a fixed location. Think of it this way - the code here could be used to measure acceleration of a body being dropped from a height. The code could be adapted to read data for 10 seconds or more, and in that time a body will have fallen a long way from where you dropped it.
So, I've gone with the following workflow:
- Flash the attached microPython code Catch_Collector_Simple or Catch_Collector_Advanced onto a micro:bit.
- Connect it to a battery pack
- Cut a hole in your ball that is big enough to fit the micro:bit and battery pack into.
- Pack the loose space in the ball with a filler (I used bubble-wrap, which I hoard!)
Once the ball is built do the following to activate it:
- Click the reset button to clear out any old data, then click the A-button
- A countdown from 3 will commence - at the end of the countdown a full stop is shown on the LEDs indicating that the micro:bit is taking measurements. Throw the ball during this period.
- Once the measurement phase is complete a small square is shown on the LEDs. The sample code will record data for about 3 seconds, but you can tweak the code to extend or reduce this.
- When you click the B-button it will initiate the process of transferring data to the micro:bit gateway.
The difference between the Simple and the Advanced versions lies in the data collection technique. For both, 1 reading is saved every 25ms (which amounts to 40 readings per second). For the Simple version we read the accelerometer just once every 25ms, but the Advanced code will read the accelerometer up to 75 times in this 25ms period. We then save a single value that is the average of all 75 readings. This 'smooths' out the data: it reduces outliers and gives a decent approximation of the acceleration across the whole 25ms period. The difference in data quality is marked and I encourage you to check this yourself: try a few times with both versions of the code and look at the data charts. You can read a lot more detail about this method, when to use it and why it is effective here on my blog.
If you look at the code you will notice that I am recording acceleration in the y-plane. For the real world scenario that I developed this code for that was adequate as the micro:bit was moving in that plane. When it comes to throwing the ball, though, the forces acting in the y-plane will be in part determined by the orientation of the micro:bit when you throw it. Consider adapting the code to record x and z readings and also ways that you can throw the ball in such a way that the acceleration acts in plane you are recording.
You may also notice that the code provided takes 120 readings. With 1 reading every 25ms this amounts to 3 seconds of data collection. You can play around with this. I found that it was possible to record up to 400 data points in this way. My production code used a file to store the data, rather than a list. Both ways have their pros and cons, which I won't elaborate on here (but please ask if you are interested).
You will need to do the following:
- Build and setup a micro:bit gateway.
- Connect to an IoT platform
I'd recommend having a look at this blog, which contains all the info you need to get connected.
Before completing the experiment ensure your gateway is powered up and connected to Ubidots.
Note that the microPython code in the gateway for this project is almost identical to the code used in the other blogs I've written. Adapting it for each circumstance is relatively easy. When MakeCode blocks are released (soon!) this process will be greatly simplified.
- Set up and throw the ball, as described.
- When measuring is complete, ensure your ball micro:bit is within range of the micro:bit gateway (a couple of meters should do).
- Ensure your gateway is ready to receive data.
- Click the B-button on the ball
- Sit back and watch the process unfold. Its fun to watch the data accumulate in Ubidots.
My code takes about a minute to transmit all the data to the IoT platform. This can be reduced significantly.
The reason it takes so long is that I have been very cautious - I spent some time adjusting the various sleep commands, and when I found a mix that worked consistently I left it at that. I would love to see it working much more quickly, so if you crack this please get in touch and let me know how.
Lets take another look at the chart from the beginning of the blog. This time I've put some lines in to mark the interesting 'phases':
- Phase 0: The object is at rest.
- Phase 1: A rapid (you might even say, explosive) acceleration is applied. It peaks at the point marked, but the object speeds up throughout this period. At the end of this period the object has reached its maximum speed
- Phase 2: At the beginning of this period the forces slowing down the object have exceeded those accelerating it, and a rapid deceleration occurs.
- Phase 3: The data here is a bit 'noisy' - the object is decelerating for most of the period, so the object slows down in this phase. Occasional changes to the rate of deceleration are interesting.
- Phase 4: A rapid deceleration occurs, followed by an equally rapid decrease in that deceleration, until it reaches zero. The object has encountered a barrier that is not a solid wall, but which brought it very quickly to a stop.
- Phase 5: the object is once again at rest.
Have you guessed what it is yet?
It is a rocket powered car. In Phase 1 the rocket engine fires, then stops firing and we enter Phase 2. This phase sees forces of resistance work strongly against the car. In Phase 3 the car bounces a bit, perhaps sometimes leaving the ground and going briefly into freefall (which might explain the minor acceleration noted in that period, idk?). In Phase 4 it then hits a specially designed breaking system which slows it to dead stop in about 1.5 meters.