Whether it's our cars, bikes, motorcycles, scooters, or skateboards, our wheels are important to us. They get us to work and school, and offer a speedy way to visit a friend or just have some fun. However, even though we love our wheels as is, they certainly could be safer, smarter, or more efficient. That was the goal of our IoT on Wheels Design Challenge with STMicroelectronics. They helped us design a fantastic kit for our contestants to use to upgrade their wheels, and the kit proved its worth as our challengers returned impressive new designs, so I decided to have an electronic chat with our three top finishers, dixonselvan, dougw, and vlasov01.
What inspired you to join this design challenge? Was there a specific experience you had with transportation, or perhaps something you read, that gave you the inspiration for your design?
Douglas Wong: In my first job, I spent 10 years working on all kinds of transportation-related projects – trains, planes, cars, boats, trucks, even submarines, and more recently I had done a vehicle simulator project on element14 based on the Beaglebone Black. It took me a while to decide to apply for the challenge. I first investigated the kit to see if it was of interest, and I discovered this NUCLEO-L476RGNUCLEO-L476RG module is very powerful and I had always wanted to learn more about the Nucleo line.
Next, I thought about issues I had with my wheels. The things that stood out were not knowing the time while commuting on my motorcycle, and not knowing the amount of gas left in the tank. Once I started thinking about a clock and using GPS to get an accurate time, it was an easy leap to thinking about tracking the location of the bike. I didn't want to pay for a cell phone link, so I investigated LoRa.
Dixon's Traffic Predictor
Dixon Selvan: Every day I travel a total of 16 kilometers to my office, and it usually takes me 30 minutes because of traffic. One day, when I took along a stranger along with me, he showed me a shortcut that avoided much of the traffic. But this route was not available in Google Maps. That's when I decided to make a system which gets the user's best routes to save time.
Sergey Vlasov: I spend a lot of time commuting, and I think there are a lot of opportunities to improve transportation. Google does a great job of collecting and sharing information on traffic and accidents, but it has a main focus on cars. Blubel is focusing on cyclists, but it seems to be a closed platform, and there are several other closed platforms which are trying to solve similar problems. I was hoping to design an open and flexible platform to support the whole community on wheels.
What surprised you about your work as you developed your design over the 11 weeks of the challenge? Did you have any earlier “draft” ideas for the project that you did not choose, and if so why did you choose your final design?
Douglas Wong: I was a bit surprised that all the Nucleo daughter cards only used the Arduino connector, given that Nucleo has its own, more comprehensive Morpho connector system. This results in a lot of pin conflicts between Nucleo cards and 3rd party Arduino ones.
How did you feel about working with the STMicroelectronics Stackable Hardware?
Dixon Selvan: I was having fun stacking one over the other, which rekindled my love for building blocks. They were really elegant in design, compact, easy to stack and very important with their useful hardware (Bluetooth, MEMS, and Wi-Fi). As I had more to design and learn within the 2 months, I substituted these communication stacks with the already known HC-05 in my design to communicate with the Android app.
Douglas Wong: The WiFi card by itself used most of the Arduino pins, so it could be difficult to find other cards that could be stacked and only use the few unused pins. This is pretty common when trying to stack a lot of cards onto Arduino connectors.
Was the kit provided to you appropriate for your design?
Sergey Vlasov: The kit provided most of the capabilities needed to implement my design ideas. I’ve added a GPS module as location, speed, and heading are very important on the road. I think a cell data connection could add value from a connectivity perspective for this type of challenge, as well.
Dixon Selvan: Yes and no. I felt that a GPS module could have been added to the kit; with the theme being related to travel it would have been appropriate to add one. I could see that most of the contestants had to buy one, while I used my phone’s GPS. But a big Yes for the STMicro Stackable Hardware, which was really more relevant for my design.
What was the biggest technical problem you encountered during the challenge? Did you have to make significant changes to your approach at any point?
Douglas Wong: It turned out it was going to be very expensive to implement a LoRa gateway for the Nucleo LoRa card I bought, so I purchased a 3rd party LoRa card that mated to a low-cost LoRa gateway. The LoRa radio card I ended up using had drivers programmed in an Arduino IDE. Fortunately, there is an Arduino-compatible IDE available for the Nucleo MCU which would allow my custom interface card software to access the LoRa radio. Unfortunately, the Arduino IDE implementation for Nucleo did not have Arduino-compatible SPI commands, which caused the LoRa radio code to fail. It was not feasible for me to port that complex code to MBED or System Workbench in the time available, especially since I have never used either IDE.
Dixon Selvan: The first challenge I faced was when I wanted my project to be mobile and also to power it through a portable power supply I overcame this after reading the Nucleo-L476RG board’s manual and finding the answers there Next I had an issue with serial communication I was left clueless as my setup was working as expected with Arduino and when I shifted it to Nucleo-L476RG it did not work After some time I found that it was the fact that the Nucleo-L476RG board had an alternative CN3’s TX and RX instead of usual TX and RX for serial communication
Dixon's sensor output
How did the community help in your project?
Dixon Selvan: The community molded my design with their valuable comments, which reinforced my ideas and kept me motivated. I would like to mention DAB, who was consistently reading my blogs and commenting on them, and CharlesGantt for his weekly roundup blogs. The co-contestant’s blogs also really helped me; to mention a few, I would say dougw blog on making use of the Arduino IDE to code the Nucleo-L476RG board and vlasov01 blog on coding the stackable hardware through the Mbed Online Compiler.
Sergey's data visualized
What techniques have you used for the first time in this build?
Douglas Wong: This project attempted to measure fuel level using acoustic resonance – that is a first anywhere, as far as I know.
Sergey Vlasov: There was a lot that was new for me in this challenge: STM32L4, Mbed, IBM Watson IoT, gyroscopes, accelerometers, STM32CubeMx, UBX, u-center, and ARM C.
What did you have to consider - especially regarding safety - before taking your project out onto the road?
Douglas Wong: The fuel I was trying to measure was gasoline, which can be dangerous in many ways. I totally avoided making any alterations to the fuel system by trying to measure the fuel level externally, without even opening the gas cap.
Sergey Vlasov: It was important to protect my device from environmental impacts like rain. At the same time, it was meant to be compact and easy to observe and access, as well as easy to replace its power source and upload a new firmware. But, most importantly, it shouldn’t take your attention away from the road.
Top Comments