Being motorcycle enthusiasts and engineering students we were interested in not only being able to improve our riding ability but also being able to quantify our abilities. In Motorsport the simplest way to achieve this is by monitoring the status of the vehicle through the use of telemetry. Motorcycles being different from cars there were some factors we were specifically interested in: speed, lean angle, pitch angle, lateral acceleration, and longitudinal acceleration. In order to accomplish the majority of these things with a simple accelerometer would be incredibly difficult and require intimate knowledge in the use of Kalman Filtering. Fortunately, Bosch has created a sensor called the BNO-055 that does all of this for you and allows you to just retrieve the processed data in terms of absolute orientation of the sensor as well as the raw data if you so choose. Also GPS would allow us to keep track of position and speed. By also keeping track of position it would then be possible to overlay our logged data on to a map for a easy to process visualization of your riding performance.
1 / 2 • A visual map overlay of collected lean angle data. Can be used to view any data collected in terms of position. This is a much easier way to view and understand your data besides viewing it raw!
We wanted to be able to create this sort of telemetry system but we needed to achieve passing a command from one Particle to another so we came up with the idea of detecting when the system was within a certain distance from home and having it trigger a light. That way if you were to come home after dark you would be able to see.
Map overlay of proximity variable being triggered to turn on the light at my house.
We were able to get the telemetry system to work at 10Hz without error. While this may seem like a lot of information and tell you everything you need to know for most cases, there are instances when that is not quite fast enough. Unfortunately the other week I had a small lowside (meaning I did not loose contact with the ground) crash on my motorcycle and happened to be running the telemetry system at the time. In viewing the incident after the fact I was able to see my speed, the acceleration I was experiencing, and the bike start to fall over. The whole crash took place in less than half of a second and it was obvious that to be able to tell what caused it would take a lot more information. I have been working on trying to log the accelerometer data at 100Hz while keeping the GPS at 10Hz which are the limits of those two sensors but have been running into errors with the GPS data whenever I try to run the loop at more than 10Hz despite only calling the GPS at 5Hz. So for now 10Hz will have to do but in the future we may try to make that faster.
1 / 4 • MotoidIoT on a breadboard
A switch was added that controls whether or not the SD card is writing data due to issues with SD card corruption. With our code when that switch is in the write position it turns the D7 led to high for a visual confirmation that you are in write mode. Note: If you remove the SD card or turn the power off with the SD card in the write position, you will corrupt that working data file. Because the D7 LED was being used, another LED was wired to D4 for prototyping purposes and it lights up whenever you are within the set proximity of home. It also serves as an indicator of whether or not there is an error with the device. If you try to write to the SD card and it fails it will flash on and off to let you know of the error. It will give that same signal if it fails to detect one of the breakout boards.
1 / 2 • The MotoidIoT was soldered to a prototyping Board due to issues with wires coming loose mid-ride and preventing proper data collection.
Because this is a system that is mobile and you may want it to work even when it is not located in a Wifi connected area, the Particle is set to Semi Automatic. The Particle will connect to Wifi upon start up but if it does not connect within 15 seconds or loses Wifi it will turn the Wifi module off to save battery and will not attempt to reconnect until it is restarted. If you want to still be able to use your Proximity function though you can always set your phone up as a Mobile Hot Spot and broadcast a consistent signal to your Particle at all times.
Since the MotoidIoT saves it's data as a.CSV you can choose to analyze your data however you choose. However, if you have access to Excel than I have a pre-made template that you can use and improve upon for your analysis. This will allow you to see some statistics about your ride, focus on a section of your ride, see graphs of all your statistics, and see a heat map overlay of your ride in regards to your statistics.
In order to use the template:
- 1.) Create a new document using the template.
- 2.) Excel will ask you to refresh the data. Choose the.CSV file you wish to analyze and it will upload it to the template.
- 3.) In order to view the Heat Map overlay go to Tab GPSLOG
- 4.) Select Insert and 3D Map.
- 5.) There should already be a pre-made tour with Heat Map settings on it so you don't have to do a thing.
Some screenshots of the template in use are below, unfortunately some data could not be shown so for personal and safety reasons but there is nothing stopping you from collecting and viewing your own.
1 / 6 • A screenshot of the MotoidIoT excel templates raw data page. From this tab you click insert and 3D map to access the map overlays of your ride.
The receiving device uses a digital pin configured as OUTPUT to actuate a relay located on the relay module. The particular relay module used was built with 3.3/5V logic in mind, which simplified implementation of load switching, as separate transistors were not required in order to source the higher current demands of typical 5V relay coils. Typically, relays such as these (the actual relays on the module) can draw on the order of 40-50mA, which exceeds the maximum current draw of the logic pins. One way to overcome this would be to use an NPN transistor, with the collector connected to an additional voltage source capable of higher current draw (such as a few AA cells in series), the emitter connected to one leg of the relay coil, and the base wired to the logic pin on the micro controller. Another solution (the one ultimately used) was to purchase an overseas (read: China) manufactured relay module. The module's logic is such that current is drawn in order to hold the relay in its normal off state. One could either choose to physically rewire the relay in order to use normal HIGH logic to activate the relay, or reverse the logic in the software. Since the wiring was already complete, we chose the software route. When the transmitting device sends a signal to the receiver that the load needs to be active, the digital pin controlling the relay goes LOW, allowing the load to draw current. The downside of this configuration is that if the voltage source powering the relay module were to drop below a certain threshold, the relay would activate the load. Again, the ease of manipulating the software was the reason this configuration was chosen.
Receiver / Relay Module wiring
It is worth mentioning that despite the ratings printed on the relays themselves, they were inadequate for switching the level of current demanded by a 100W halogen flood light. Two of the four relays failed after approximately 60 seconds of use. Perhaps this relay would be fine for switching your remote fish feeder or general learning purposes, but certainly not for permanent integration with mains wiring.