IoT on Wheels Design Challenge Smart Drive Project Index
After some testing, I've realized that I need to know speed and heading as well. Speed is required in context of fall detection. Free Fall detection algorithm, which leverages LSM6DSL sensor data, is optimized for walking and not for driving (bicycle). So to reduce false positives I need to correlate speed and LSM6DSL sensor data to accurately predict falls.
Road participants moving on the same road in the same direction are experiencing similar obstacles, which may be different from obstacles experienced by drivers moving in the opposite direction. So it is important to capture heading of motion.
Until now I was using only two messages from UBX protocol NAV-POSLLH and NAV-STATUS in my project.
NAV-POSLLH is Description Geodetic Position Solution message and provides longitude and latitude information in a small 28-bytes payload, where NAV-STATUS is Receiver Navigation Status message, which describes how valid is information just by using 16 bytes of payload.
After some research I've decided to use NAV-PVT message. NAV-PVT is Navigation Position Velocity Time Solution message. It provides in one message the same information as NAV-POSLLH and NAV-STATUS, but in addition it gives ground speed, heading, accuracy of readings among other interesting data. It comes with additional cost so. The message payload size is 92 bytes, which is significantly bigger then the other two messages.
I've changed my GPS receiver configuration code, by only enabling NAV-PVT message.
// Disable UBX 0xB5,0x62,0x06,0x01,0x08,0x00,0x01,0x02,0x00,0x00,0x00,0x00,0x00,0x00,0x12,0xB9, //NAV-POSLLH off 0xB5,0x62,0x06,0x01,08,0x00,0x01,0x03,0x00,0x00,0x00,0x00,0x00,0x00,0x13,0xC0, //NAV-STATUS off // Enable UBX 0xB5,0x62,0x06,0x01,0x08,0x00,0x01,0x07,0x00,0x01,0x00,0x00,0x00,0x00,0x18,0xE1, //NAV-PVT on
As well I've added code to parse NAV-PVT message.
I believe at this point I have all required sensor readings on Nucleo board:. There are still several tasks left:
Additional modifications on server side:
Additional modifications on Nucleo board:
As I achieve a lot of progress in the last two weeks I've started preparation to move outside from my lab. But all components (Nucleo board, expansion boards, GPS receiver) and my breadboard require some packaging, so they can work on the road.
The first thing was to drop the breadboard as it was the biggest part. I've reused a cable from an old PC. The cable terminals has a nice spacing, that fit very well USB serial adapter terminals on one side for debug purpose and it can play a role of a breadboard on other side.
Then I've closed JP1 jumper as described by Douglas Wong in one of his previous blogs before adding an USB power bank. Then I've reused a transparent box from sweats to house all main components.
it is now relatively compact to bring it outside and ready for the roadtest.
In one of my previous blog posts I've described how to connect GPS receiver to the Nucleo board using STM32CubeMX tool and STM32Cube libraries.But I've realized that STM32CubeMX is not aware of Nucleo Expansion Boards. As result, I switched back to MBed platform. I was not sure if USART3 TX and RX still going to work with my Nucleo board connected to two expansion boards at the same time. I've ported again UBX GPS MultipleMessages code this time to MBed and configured Nucleo STM32L476RG Nucleo Morfio pins PC_10 and PC_11 as USART3 TX and RX ports.
Serial gps(PC_10, PC_11); //USART3 tx, rx
This time I've used MBed serial callback instead of STM32Cube interrupts to process serial input from GPS receiver.
Then I've connected the board with GPS receiver serial ports.
I've tried by connecting pins Nucleo STM32L476RG Nucleo ST morfo connector pins PC_10 and PC_11 to GPS receiver serial ports.
I was not very optimistic that it will work right away. And it was not working at first as I've added as well printf function in my serial callback processing for debug purposes. But after some googling I found that the code in callback function should be very fast and shouldn't use any expensive I/Os. After removing printf debug code the code for GPS serial output processing start start working.
The following screenshot provides a view on content of variables populated by processing GPS data. I'm using U-Blox UBX protocol NAV-POSLLH message to get location and NAV-STATUS to get details if my GPS readings are valid.
At this point all major components are in place, connected and functioning as expected. So I'm very happy about it. But there are still a lot of work left in the few remaining days before the end of the contest on November 13th.
In the end of my previous blog post I've described the situation, where I hit the wall when I was unable to progress with STM32CubeMX to interact with Nucleo expansion boards.
I've decided to get back to MBed platform as it provides a reach set of high level libraries. I've used IBM Watson IoT project as my base. I've removed NFC references. Then I've imported IKS01A2 library, replaced all references to Nucleo IKS01A1 with IKS01A2 as they are different boards.
I've tested that everything (STM32L476RG, WiFI, MEMS) still works after my modifications:
Then I've added several additional sensor readings related to my project to be communicated to MQTT broker.
These additional parameters provided by IKS01A2 library:
Again, I've tested that they get published in my terminal:
And as well get published to IBM IoT Watson:
I've published this project on MBed https://os.mbed.com/users/vlasov01/code/Watson-IoT-MQTT-WiFi-MEMS/ so you can play with it as well.
I'm quite happy with the progress I've achieved with MBed this time and looking forward to start reading GPS receiver data from my MBed based code with data from environment sensors and publish them over WiFI to MQTT broker.
My GPS module only supports serial communication. So I've again used STM32CubeMX to configure serial ports. I've configured STM32L476RG pins PC11 and PC12 as USART3_RX and USART3_TX As well I configured USART3 to use interrupts. And then I've generated the code template. It was quite straightforward.
I've ported GPS module configuration and parser from Arduino. The original Arduino code and UBX messages has been explained in UBX GPS MultipleMessages video https://www.youtube.com/watch?v=ylxwOg2pXrc . UBX is an alternative to NMEA protocol developed by u-Blox.
The configuration ensures that I only receive messages that I'm interested in, like position and status of connection with satellites (how reliable is information about position). One of the challenges during the port was to migrate from polling serial port in Arduino to use of interrupts with STM32. STM32 interrupts works great. But the challenge was that UBX messages have a variable length. So I was forced to use interrupts after receiving each byte. The next day after I've completed my code I've receive an article from STMicroelectronics Community "Efficiently use DMA with UART RX on STM32" https://community.st.com/thread/42689-efficiently-use-dma-with-uart-rx-on-stm32 . They describe a better approach to handling this situation. As I'm running out of time with my project I'll delay the change for another time.
I've connected serial ports from GPS module with Morfio pins of STM32L476RG Nucleo board. In addition I've monitored serial communication using USB to RS232 serial adapter, which was connected to my PC.
This test I executed inside the house. So GPS module was not able identify latitude and longitude. But it was sending messages as expected and parser was able to go over this messages without any issues.
STM32CubeMX accelerated and simplified parts of low level coding. I've start looking how to use it with my sensors and WiFi Nucleo expansion boards.I was surprised to find out that
it is not aware of Nucleo expansion boards at all at this time.
I've purchased a GPS module VK2828U7G5LF. It is based on UBX-M8030-KT chip, antenna and UART interface.
I've used USB TTL serial converter to connect my GPS module to PC. The manufacturer of UBX-M8030-KT chip provides free software u-blox u-center to test and configure GPS module. It is very useful tool to start working with GPS module and debug protocol and controller behavior..
u-blox provides AssistNow feature for better precision. It is quite important for ant road related application. I've registered on u-blox site and got the token to use this technology. I've entered the token in the application and got data from the server. But my attempts to load this data into GPS Module failed. I suspect it may be a limitation of my GPS module.
There is a lot of code samples for this GPS module built for Arduino platform.
I've looked at several of them:
Tiny GPS ( TinyGPS | Arduiniana )
Tiny GPS Plus ( TinyGPS++ | Arduiniana )
UBX GPS MultipleMessages ( https://www.youtube.com/watch?v=ylxwOg2pXrc )
I've selected the last one as it focus on performance and small code footprint. As well code includes configuration sequence for GPS module, which simplifies configuration process,
The small code size was especially important as it simplified the process of porting the code from Arduino to Nucleo development environment.
It was pretty simple to connect the module to UART interface on Arduino board and run tests.
It was my first experience working with GPS module. I'm generally happy with results so far.
The next steps is to explore STM32L47RG serial interface and connect it to GPS module.
This is my 4th blog post for the "IoT on Wheels Design Challenge. I've explored MQTT connectivity over WiFi and sensor board in my previous blog posts. I'm a bit late in my project activities as I faced multiple challenges working with STM32L476RG Nucleo board..
Now it is time to connect my GPS module. But the module that I have only works over UART port. I'm planning to use WiFi and sensor boards and I hope it will help me resolve potential conflicts with pin configuration conflicts as reported earlier by Douglas Wong in The Konker Connection - Blog 3 . As result I've decided to use STM32CubeMx to configure the board and generate code template for the serial communication.
I've followed a detailed tutorial "STM32 Nucleo Board Programming 4- UART printf Coding in Keil using STM32CubeMx" from https://www.youtube.com/watch?v=Oc58Ikj-lNI .
It helped me to start with STM32CubeMx and serial communication from STM32L476RG.
I've launched STM32CubeMx and selected STM32L476RG for a new project:
Then I observed my board parameters:
I've cleared all settings:
And I;ve set new parameters to configure RCC and USART2:
Then I've configured the serial port speed at 9600 BPS:
I've defined my project settings:
I've continued following the tutorial and was able to connect my STM32L476RG over serial to terminal:
My next step is to configure STM32L476RG receive data from GPS module.using a different serial port.
This is my 3rd blog post for the "IoT on Wheels Design Challenge. I've explored MQTT connectivity from the STM32L476RG Nucleo board using mbed cloud environment in my previous blogIOT on Wheels Design Challenge - Smart Drive - First Steps with mbed os - Blog #2post.
There are several type of events I'd like to detect from the MCU and its sensors in my project One of them is Fall Detected event I was very happy to discover that mbed has MultiEventIKS01A2 demo application It demonstrates capabilities of different sensors including Free Fall Detection
I've compiled it and was able to run successfully on my board.
We are frequently taking Internet connectivity for granted. It not necessary the case everywhere in the world, and definitely may be limited or absent on the roads. As result I decided to look how can I store data on the board as it has some flash. I was not able to find examples of standalone data logging for STM32 family on mbed. It seems mbed OS 5 doesn't provide the same easy way to access persistent memory as I've got used to on popular x86 or ARM based Linux boards.
Then I've read documentation on X-CUBE-MEMS1 package for expansion board on a or development boards It as well comes with MotionFD fall detection library which receives the data acquired from the accelerometer and
pressure sensor to detect fall event; it features:
But the most interesting for me feature was standalone data logging. It is using the flash sector dedicated to data storage (128 KB), allowing memorization of more than 16,000 data sets.
The documentation for X-CUBE-MEMS1 describes use of Unicleo-GUI to visualize in real-time data captured from the board/sensors. I've compiled and loaded Fall Detection application form X-CUBE-MEMS1 to the board. Unicleo-GUI was able to recognize my board.
It provides different visualization tools for different sensor types. The following one was for magnetometer:
There is one for environment:
I was a bit surprised by humidity sensor as it fluctuated a lot without any changes in the environment other then my attempts to emulate falls..
There is another visualization tool for motion sensors:
You can see there some large green spikes at times when I was trying to test falls. Unicleo-GUI has as well a GUI for fall detection:
But for some reason it hasn't detected falls compare to mbed sample, which was able to detect them quite reliably.
In addition Unicleo-GUI allows to record all sensor reading in CSV format, so they can be analyzed to tune parameters of the algorithms.
I've found the following STM User Manuals very useful in my exploration:
UM2275, Getting started with MotionFD real-time fall detection library in XCUBE-MEMS1 expansion for STM32Cube
UM1859, Getting started with the X-CUBE-MEMS1 motion MEMS and environmental sensor software expansion for STM32Cube
UM2128, Getting started with Unicleo-GUI for motion MEMS and environmental sensor software expansion for STM32Cube
I've introduced my project Smart Drive in my previous blog post.
My project requires a secure connection with Internet to exchange information. I've selected MQTT protocol as it is open, lightweight (low power consumption), supports data confidentiality (TLS) and widely adopted (including client for STM32).
The following characteristics of Nucleo Wi-Fi expansion board X-NUCLEO-IDW01M1 enable my communication requirements for a secure connection with Internet to exchange information over MQTT protocol.
X-NUCLEO-IKS01A2 - Motion MEMS and environmental sensor expansion board for STM32 Nucleo will provide sensor reading related to acceleration and orientation.
I've connected Nucleo Wi-Fi expansion board and Nucleo Motion MEMS and environmental expansion board X-NUCLEO-IKS01A2 - Motion MEMS and environmental sensor expansion board for STM32 Nucleo - STMicroelectronics with Nucleo development board
I've try several development IDEs for STM32. I've decided to use mbed os IDE https://os.mbed.com/compiler/ . It is fast, easy to use. It has some constraints in terms of debugging, but serial communication from the board provides capability to get log output.It is acceptable for me way to debug after my previous experience in a similar setup with other MCUs. As well it is possible to export project from mbed os and import into other IDEs. But I run into some errors when I've tried to build the project with STM System Workbench.
MQTT protocol support comes with one of the several STM32 ODE Function Packs - STMicroelectronics I've decided to try FP-CLD-BLUEMIX1, as it was build by IBM, which created MQTT protocol.The MQTT client implementation is based on Apache Paho project. The documentation and MQTT server hosted in the cloud. I've created a new mbed-os project using FP-CLD-BLUEMIX1 template. Then I've configured WiFi parameters in the project and removed references to a NFC board.
I've connected STM modules over USB to a serial terminal. Then after a successful compilation of the project I've uploaded the binary to STM32 USB disk. The program start execution right away after the upload. The board was able successfully connect to my WiFi access point and to the MQTT server in the cloud.
I was able to confirm MQTT connection from the cloud server by entering my board MAC address,
Thank you for stopping at my first blog post for IoT on Wheels Design Challenge!
I like exploring different ideas and I'm very happy that the idea of my project has been selected for this challenge.
STM32L4 is a new MCU for me. It has a very impressive specs in terms of performance and power consumption. I think it should be a good fit for my Smart Drive project, where processing power as important as power consumption..
I'd like to build a collaborative system, that will connect different participants on the wheels. They will be able to share data collected during their travels, Especially valuable will be data related to events like emergency breaking, collisions, crashes, this data will be linked to the position, speed and other information collected from the sensors.
There are different types of wheals on the road. You may ride your bike, drive a car, commute by bus/train or getting around in a wheelchair. The road may be full of surprises. Not all of them are good for you.. It will be great to be prepared for unexpected. How about to be advised by a friend or community in advance?
These drawing illustrates a high level idea of sharing information with community, where all participants going to benefit from the shared data. On-board Processing component is using on-board sensors and data shared by community to generate real-time alerts. These alerts then get passed to the community.
These drawing illustrates how real-time processing should work. The real-time processing is enabled by on-board components.Once a condition is detected the notification will be created. In case of "false alarm" it will be manually suppressed. In addition to sharing valid alerts with community emergency contacts may be notified in case of dangerous situations.
The components provided by Element14 and the sponsor will be complemented by a GNSS receiver, a buzzer, lights, rechargeable battery and a button.
1. Protect privacy (not share any personal identifiable information)
2. Keep it open and transparent
a. Open APIs for data sharing
b. Open source (all code is open source)
c. Open for ideas
3. Do not distract from the road (minimize false positives as much as possible)
4. Keep it simple (interface should be as simple as possible)
Thank you for being with me so far. As I'm still early in the design process you can very well influence it. I'd like to ask for a constructive feedback.
How do you feel about the idea?
Tell me about your experience of being in a dangerous situation while on the wheels.
What do you like and dislike about the design?
What would you like to change in the design?
How would you feel about sharing this type of information (without providing any personal details)?
I'll really appreciate if you can provide some input.