Category: Qiaoan’s Weekly Status Reports

This week I have  two tasks:

The first and primary task is performing tests for the gyroscope part. Please check the team status report for the video about gyroscope tests. The target for the gyroscope tests are checking its stability and accuracy. The stability test requires the gyroscope to keep its drifting with in 1 degrees. The result shows that the gyroscope output has some noises, but the avearge is not drifting. To better generating this output, I want to apply a Gaussian filter (the one for image processing), which produces a result based on a weighted average of recent gyro readings, to the gyroscope results instead of separating the results to steps of 5 degrees as we implemented now to migitate this issue. The accuracy test measures the tilt error of the gyroscope. We expect the error to be smaller than 0.5 degree, due to the noise the raw data should not fit for this requirement. We are trying to generate average degree data that matches the physical degrees as we keep working on modifying the Gaussian filter to generate a more accurate average degree output.

The second task is preparing the poster for the project. I added some images to the poster and subtitute some texts.

Generally speaking, I think I’m a little behind the schedule due to new challenges we find from testing. However, one thing I noticed is that from the user experience perspective, the current version of our project runs well when I was playing with it. Next week I will focus on testing and finishing final poster and report, as well as preparing for the demo session.

This week we have three major focuses, integrate parts together, design tests and prepare for the final presentation. A demo video can be found from the team status report to show the test.

The first test we want to perform on gyroscope is the gyroscope drifting. Our testing method is start the car in the game and put the steering wheel on the table. Then we push on the throttle and move the car forward to see if the direction is changing. Besides the information we can get from the game screen, we can also check the log from the program to see the output data, and the steering wheel angle input to the game from the game’s API. If the car’s movement on the screen, program log, and the game API all show that the angle remains constant for more than 1 min, then we think the project has passed the gyroscope drifting test.

The other test is the angle accuracy test. We want to make sure that our data output matches with the real angle of the steering wheel. We need to do this before adding the dead zone on the steering wheel around +/-180 degrees and 0 degree. To run this test, we need to match our program’s data log of output with the angle of the steering wheel in the real world. We start with placing the steering wheel at 0 degree and rotate the steering wheel until 180 degrees. The test should rotate the steering wheel in two different speeds, the first one is to rotate the steering wheel in a constant speed, and the second one is rapidly place the steering wheel to a target angle and see if the data output changes to the target. We current only test this based on our eyes so this test may have some errors, but for now the result looks good. If the steering wheel performs bad, we can buy a protractor and test it again to see where it goes wrong.

Preparing for the final presentation is another important part of works I did this week. To find a good way to explain the Madgwick filter to the audience, I need to read the paper carefully and check the function from the madgwick filter library to illustrate how we process the raw data to present on the slide. I also need to communicate with my teammates, especially Yuxuan Zhu, to help him prepare for the presentation content of the gyroscope section, since he is not very familiar with the approach of gyroscope section.

This week:

I tired to implement the method provided by the Madgwick paper. However, even though I tried to implement Madgwick’s method as close to the code from the paper and it can give me readings that makes sense, I still find there are many problem exists.

One problem is that the degree changes from rotation changes is not accurate. I’m still very confused about this and probably I made a mistake implementing the Madgwick filter. Based on the information I get I think Madgwick filter is a correct method to solve the problem but I still need to keep working on it.

Another major problem is gyro drift when the device is stable. When I place the gyroscope on a stable surface, the gyroscope data from the filter will still keep changing slightly. I compare the data from Madgwick’s method and the accelerometer readings when the device is placed on a stable surface, and I can see two readings starting at about the same position and Madgwick’s reading will drift from the original position. I’m not sure if I made a mistake implementing Madgwick’s method or I should apply more high-pass filter on gyro data to migitate the drift, but I will keep testing this to try to figure it out before the lab on Monday. I think Madgwick filter should be able to overcome this issue based on my understanding of the paper so it’s more likely I made a mistake.

This is a tough week for me. I wish I can have more progress on Sunday. I find a more about implementation of Madgwick code by Karlsruhe Institute of Technology here https://github.com/morgil/madgwick_py, maybe I can refer to this.

This week:

I keep working on the code for calculating the current angle of X, Y, Z axis. Currently we already have code to calculate the angle output from the accelerometer. However, this works best only if the gyroscope is not shaking too much. The current code aims to allow my partners to use the data for the demo session if possible.

The accelerometer code looks like this:

When the gyro is stable, it can correctly generate angle readings like the following rotation on z axis:

[Wordpress starts blocking me from uploading images now, I tried to remove eariler files, reduce resolution but both methods doesn’t work, I can show it during the demo session next week]

However, as I stated above, the algorithm is not very resistant to shaking. We need gyroscope data to help overcome this issue. The Madgwick paper provides a solution to combine two types of readings together. Figure 3 of the Madgwick paper provides a good explanation to its method (I cannot upload it here due to the wordpress issue). It’s clear that the method is quite complex, and I do need more time to look into this and think about how to implement the method. Luckily the paper has code appended to it, but I think I really need to fully understand it first before using it.

Here is the end of the report for this Saturday, I wish I can have more findings this weekend. I still have some questions about the paper and I will ask faculties about them if I cannot figure it out by the weekend.

This week:

For unknown reason wordpress is stopping me from uploading images. It says The uploaded file could not be moved to wp-content/uploads/sites/230/2023/03. I’ m sorry about this and will try to add pictures back once this gets fixed.

The gyroscope system is still waiting for hardware to be ready for testing. This week let’s discuss how we can use the gyroscope readings to generate the degree output we want to feed in our functions from last week’s report.

The gyro section of data from the gyroscope should be the point we want to focus on. The reading is based on angular velocity in degrees per second. The key point is to transform this velocity data into the angular position.

The pseudo code solution could be like this: (I want to upload image for this but wordpress does not allow me to do it)

This week:

For the function to migitate the handshaking of users, based on the Gaussian filter model I mentioned last time that help generate a diffused image by getting weighted average value around a certain point, I would like to generate the ouput by a weighted average of a series of x, y, z readings from gyroscope.

Suppose we use x_n, y_n, z_n for note the x, y, z reading from the gyroscope at a certain time, and a_n, b_n, c_n for their weight. Then the output degree should be a result of combination of x, y, z reading from several previous readings that doesn’t differ very much as follows:

The target of tunning should be determining the value of n that indicates the number of previous readings that we want to use, and the a, b, c values to determine the weight of readings from x, y, z and based on the time of the reading (which means newer readings will have higher weight).

We will then talk about the logistic growth function that maps the gyroscope reading to output to the game, I have tried several possible combination of parameters. The function can be written as:

L means the range of our data, here since our degree output should be 0-180 degrees in each direction, so for the f(x) of each direction we define L=180.

k means the logistic growth rate, or we say the steepness of the curve, finding the correct value of k should be our target when tunning the steering wheel.

x_0 means the x value of the sigmoid midpoint. Here $x_0$ = 90 since we want the range to be 0 to 180.

I have tried several k values for this function to generate the mock output graph. Determining which k value to choose will depend on our testing result after the hardware is built. The graph is shown below:

The workflow of the gyroscope system should be defined as first reading the raw data from gyroscope and store them in a first in first out list of n readings. Then use the n readings to generate the weighted output and send the result to the logistic function to map the reading to the final output.

This week I mainly focus on designing the gyroscope and analog trigger tuning algorithm. Those already existed solutions seems too simple for our design and I think it’s necessary for me to try to generate some methods of our own to map the gyroscope input to the output to the PC.

The first goal is to minimize the effect of shaking. It’s inevitable for a mobile steering wheeling holding by our user. The most straight forward solution is to add a threshold that filter out any changes smaller than 2.5 degrees in 0.1 seconds. In order to improve this, I’m thinking using a Gaussian filter which is usually used to blur images in image processing to generate an average degree output based on the gyroscope reading if the reading doesn’t change much for a while, which means the user is holding the steering wheel steady. By using a Gaussian filter that use time as the factor of proximity, we can make sure the geryscope reading closer to the current time has a higher weight, while the transformed output is not bouncing up and down rapidly since the reading a while ago is also considered. The exact weight for readings by time should be tuned by testing after receiving the component. Generally speaking, I think this can provide the user with a smooth transition rather than obvious change due to shaking. The picture shows a simple example of a Gaussian filter. Here in our case we will assign higher weight to newer reading. I’m looking into how to implement this, I think there are packages related with Gaussian filter and I need to transform my reading into the matrix it takes, or I can write a function of my own and in this way I can tune the filter easily by varing the weights I set.

The second goal is to map the linear reading from the sensor to a tuned non-linear output to better match the user experience. I would like to use logistic curve to represent the mapping from 0 to +/-180 degrees. The S-shaped curve provides less sensitivity when the steering wheel points toward straight forward or turning as much as possible, which allow users to perform these two actions when they are close to 0 or 180 degrees rather than exactly at those positions, and hence avoid cases like find it’s hard to drive a straight line since the user cannot hold the steering wheel exactly at 0. The center part of the curve is relatively linear and this will give users a more familiar feeling while steering normally. The graph below shows the function between reading from sensors and output toward to computer.

The sub-systems I need will be the gyroscope and analog triggers that I need to tune. The tool will be python language to let me write those algorithms. Numpy will be the main package that I will use. For the physical shell part Fusion360 will be used to build the 3D model.