Course project 2018¶
The future technology megatrends IoT and AI are becoming massive. In this course, we aim to equip students with such basic skills and in the course project, we implement a real-world wearable computing application with SensorTag.
Your application should detect, from accelerometer sensor data (SensorTag MPU9250), the user mode of movement, i.e. is he/she climbing up by stairs or using an elevator to move between different floors in our building.
When the application has detected the mode, it will show supportive message to the user in device display and broadcast a supportive message to every other device in range.
It is best to adjust your application to work in the premises of our building Tietotalo, where you can also test the application.
Your application MUST have the following features:
- Minimal user interface.
- Use the accelerometer (MPU9250) to collect data, but additional other sensors can be used.
- Your mode detection algorithm should be able to differentiate (somehow) between these two modes. It does not matter whether the user is moving up or down, but different mode is important. The quality of the detection is not graded, as long as it works in a demonstrative way.
- Your application must show supportive messages in the device display.
- Your application must send and receive supportive messages. The received messages are shown in the device display. Maximum message length is 16 bytes.
- Your application design and implementation should be based on a (simple) finite state machine.
The basic idea is to try out the SensorTag in the real-world, without being attached to a computer. For this purpose, here are instructions on how to install a coin battery to the device.
Nowadays the vast majority of AI research and applications focuses on large-scale big data analytics and machine learning based on statistics. However, as these are not the topics of our course, we have a much simpler idea.
Your application needs to compute some simple data features from the sensor data and classify the movement mode by simple comparison.
- Tresholding: find out what are threshold for different modes
- Data features: average, variance, standard deviation, ...
- Variance can be calculated for example with the algorithm here.
Classification can be done with simple comparison of features and/or thresholding between different modes. Generally using these two methods should be good enough for detection in your application.
IMPORTANT! The quality of your detection algorithm is not graded as these techniques are not the topics of the course. However, your algorithm should be able to somehow detect different modes. More about grading below.
Data for testing¶
The course staff has collected data for initial implementation and testing of your detection algorithm by using the SensorTag MPU9250 sensor. In the files below, the data format is:
[timestamp, acc_x, acc_y, acc_z, gyro_x, gyro_y, gyro_z].
The test data is illustrated below. The X axis shows timestamp and Y axis accelerometer values for that particular direction (X, Y and Z).
1. Stationary user
2. Moving downwards with elevator
3. Walking down the stairs
Note! Pay attention to the included gyroscope sensor data. It could be useful to implement extra features, as discussed below.
You can increase your course project score by implementing any additional features, such as listed below:
- 1 point Enhanced User Interface (UI)
- UI works based on menu
- Different supportive messages for different situations
- Use the buzzer to produce sound
- Other means to support the user, with leds, etc.
- 2 points Using SensorTag components/features
- Display information from additional sensors
- Display shows pixel graphics
- Display shows animated graphics
- Mode detection works in online (while running the application) and not just offline (after the measurement)
- 3 points significant new functionality
- Detailed mode detection, i.e. pedometer. This feature is counted atop your mode detection algorithm that is not graded
- Additional modes detected, i.e. cycling, travelling with bus
- Sensor data analysis requires/benefits from data fusion
- These features does not need to focus on mode detection solely, but additional functionality with other sensors, etc, can be implemented
Each new feature is calculated only once, i.e. extra sensor on the display counts once and not 2 points for each sensor.
To evaluate the points for new features, the course staff uses their experience in real-work with embedded systems.
It could be a good idea to start working on the project with Top-down design. This way you can partition a bigger problem into smaller problems that are easy to tackle in turn.
- A good design significantly reduces the amount of implementation work
- Do not leave the work for last minute, you will not succeed. Years of experience tells us that beginners can't finish the project in time, even when they have previous experience with embedded systems
- Check the features and APIs that TI RTOS:n provides for SensorTag
- It might be beneficial to code algorithms and such first in PC, before moving the working code into the device.
- Implement debugging for your project, its signicficantly reduces the time used for bug hunting
IMPORTANT! If you get stuck, do not delay your work but visit the exercise sessions.
This chapter will be updated as the work progresses..
- The FSM example in the (Finnish) lecture material could be adapted here.. literally adapted, copy & paste does not work, be warned.
- It is useful to implement Measurement on/off-functionality.
- Example code of using MPU9250 sensor is here.
- It could be useful to collect sensor to an array for easy processing.
- Note that you have about 20kB of RAM to use, so make sure that your array is not too big.
- You need to figure out the sample rate for sensor data collection. Apparently once per second is too slow, but 100hz maybe too much?
- You can measure time in the device using RTOS function
- If needed, you can filter the sensor data with e.g. moving average. Most likely this is not needed.
- If you don't have/ run out of battery, get a new from the exercise sessions. Initially, of course it does not make sense to start with battery operation, but first make your application to work otherwise.
This could a working order of how to implement your application
- Implement your mode detection algorithm in a workstation. Much easier this way than startight in the device.
- Implement sensor data collection and import your working algorithm to the device.
- Implement supportive messages and wireless transmission/receiving.
- Additional extra features.
Advice on data collection¶
You could use a laptop to collect your own real-world data or just visualize the data in the device display and observe the values by yourself. Just implement a test program that reads the sensor data and outputs it to debug console in CCS (Cloud) development. You can then copy&paste the data txt editor / M$ Excel or to such application.
When starting to use the MPU9250, give the sensor time to perform internal calibratio and leave the device in a solid flat surface.
When collecting data, try to always perform the collection exatcly the same way. Otherwise your data may not actually be comparable with your other data.
You can visualize the data with e.g. Python library, gnuplot, Excelillä or such program.
Ijn the exercise sessions, we have a laptop that you can use for data collection.
As an obligatory part of the course project, you need to provide short (max one page) design documentation of your ideas. This is your private document that helps you to understand what exactly is needed to do in the course project.
Your design can be high level, no need to dig deep into the details. Here is a simple example of a design document.
Contents of the document:
- Outline of what is shown in the device display and what UI components, will be used, e.g. buttons and leds.
- Short description of the functionality of your program,
- Tass, own functions, ...
- Data structures, constants, global variables, ...
- Just a picture needed
Returning design documentation¶
The deadline for the design documentation is 14th October. If you miss the deadline without justified cause, your course project score is reduced three points (see below). It is enough that either student of the group returns the document, but it must have the names of all group members.
note! You can of course start working on your project, before returning the document.
Note! We may use the documentation as a source material for academic research. If you want to prevent using your documentation, mark this into the document.
Returning your project for grading¶
The course project deadline is Monday 19th Novemberat 23:59 2018.
You need to return the graded code into a upload box below before the deadline expires. This code is the graded code.
Your project will be graded in a grading session, starting Tuesday 20th November. The calendar to reserve time for your project grading is in the Lovelace course frontpage -> contents.
- It takes about 15 minutes per group.
- All members of group MUST be present.
- Missing students don't get grades until they demonstrate their contribution to the project.
- You need to present your code to the teacher, who will ask questions ab out your solution.
- In the end, your score is presented.
The maximum score of your project is max 30 points that is 50% of the overall course grade. The other 50% comes from the C programming exercise. You must have points from both exercises and projects to pass the course.
- Design document: 0 / -3p
- Program follows requirements: 10p
- Bugs or missing feature: -2p / each
- If you explain how to fix the bug: -1p
- The program implementation follows a finite state machine: 2p
- the structure of code is modular and uses functions: 1p
- Variable and function names are reasonable: 1p
- Code has commented and indentation is used: 1p
- Each feature 1-3p
- Can I do the project alone?
- Yes, however your workload is then more than with a peer.
- Yes, but you have to implement additional extra features worth 5 points into your project.
- Yes of course, but you still have to implement your own code. If you copy the code, you may be guilty of plagiarism, which may lead you to very serious trouble. Therefore, please write into the code comments the names of students you co-operated with.
- It's not worth it, we will reduce your total grade by -1. This is the actual grade, not points!
- If you have a justified cause to return the project late, please inform the course teacher beforehand. Typically justified causes are well-known early.
- Sure, but you must inform the source (e.g. www page) in your code comments. Othwerise you may be guilty of plagiarism.
- The university has strict rules regarding plagiarism. We follow those rules, where students can find themselves in serious trouble, if found guilty of plagiarism.
Give feedback on this content
Comments about the task?