Qiaoan’s Status Report for 04/29/2023

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.

Qiaoan’s Status Report for 04/22/2023

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.

Qiaoan’s Status Report for 04/08/2023

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.

Qiaoan’s Status Report for 04/01/2023

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.

 

 

Qiaoan’s Status Report for 03/25/2023

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)

# We keep running the degree calculation in a loop
while True:
  curTime = time.time()
  deltaTime = curTime – prevTime # Get the time difference from the last reading
  deltaDegree = dX * deltaTime
  degree += deltaDegree
  if degree > 360:
    degree -= 360
  if degree < 0:
    degree += 360
This seems to be a working example to calculate the angular position. However, such method will be affected by errors and will get more and more inaccurate as time passes. Without testing I cannot determine how severe the problem could be, but we can use accelerators to calculate the current angles to calibrate the degree output.
I have a picture to explain this, I will add it with explanation after the bug gets fixed.
Assume we read accX, accY, accZ from our raw data. If we plot the direction R shown by acclerometer on the x, y, z space, and we want to map the vector on to xy, xz, yz plane as accX, accY, accZ (maybe normalize them). In our case, suppose the degree on yz plane is what we want (aka we want the reading of x’s degree), then we can easily know that cos(x) = accX/R, which means we can get x’s angle by arccos(accX/R). Then we can know the exact degree reading at the time we want.
Both two cases stated above can be used. The way based on gyro data seems to be easier, but the accelration based method is much more accurate. I will test both methods then the hardware is available.

Qiaoan’s Status Report for 03/18/2023

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.

 

Qiaoan’s Status Report for 03/11/2023

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.

Qiaoan’s Status Report for 02/25/2023

This week:

  1. Working on the design of the steering wheel’s shell. I plan to make it in two parts: one is a container that hold all the components inside and has handles to let users use it, the other one is a cover that defines the position of buttons, joysticks and the screen. One small issue is that we still need to create pedals behind the steering wheel. I havn’t figured out how to install them on our product but I think some holes behind it should work. The picture below shows the base I planned to hold every components inside.

    It takes me some time to recap knowledge about Fusion360 to build 3D models. Then I generated the design above with around 280mm width, 200mm height, and 22mm depth. Those numbers can be changed easily in modern CAD software so it won’t take much time to modify them.
    The next step will be 3D printing to test the feasibility of the inital design sketch. It will take some time to print the design during the weekend and I will keep testing and revise the design.
  2. The team has decided to use Adafruit’s TDK InvenSense ICM-20948 9-DoF IMU (link: https://www.adafruit.com/product/4554). Using product from adafruit should be a reliable choice. I read its document and I think it’s feasible to implement our product based on it. If there is no feedback against this I think I will place order on this. While waiting the order to be shipped I will keep working on the 3D modeling.
  3. I reviewed the feedback from the design presentation and I realized some problems we have for the design and test procesures. I would like to answer them and discuss about solutions during meetings next week.
  4. For team work assignments change and team shortfalls, I think my knowledge background can help me deal with some work of two other members. I have CS minor so the software part of Yuxuan should not be a big challenge for me and as an ECE student my hardware knowledge should be enough to do some simple tasks of Xiao like wiring. If they get into problems I can help them with less difficult tasks to give them more time to focus on critical ones. For those critical tasks of my teammates that might go beyond my knowledge, I can discuss with them to see if my suggestion can be a hint to them. We havn’t decided to make big design changes yet so the team work assignments are not changed much, though we need to change something during testing and verification part but I think many of those tasks require us to work together to accodinate different parts.

Qiaoan’s Status Report for 02/18/2023

  1. Prepare for the design presentation. Talk about the presentation detail and the design content we need  to show during the presentation, especially the content about the control flow of our project and how we can connect them together.
  2. Look into the possible ways to make the shell of our product. In last week’s report we have several designs we can download from the internet. Since the 3D printing part is not part of the ECE field, I’m thinking if we still need to create the 3D model on draft. However buttom layout and display screen may need us to come up with a customized frame.
  3. Keep searching gyroscope for design. Based on the previous conversation on Monday’s class, I think we need a better gyroscope for our project. I think https://www.amazon.com/%E3%80%90WT901C-232-Inclinometer%E3%80%91High-Stability-Acceleration-Sensor%E3%80%90Kalman-Filtering%E3%80%91/dp/B07YYTD9GR/ref=sr_1_5?crid=2UVVQ2ZH50JXH&keywords=easy+gyroscope+sensor&qid=1676779998&sprefix=easy+gyroscope+sensor%2Caps%2C72&sr=8-5 may satisfy our design spec. I will discuss this with my team when finishing the design.

Generally speaking, I think I have choices for my design, but I still need to talk with my team.

I think ECE courses that will cover my design is 18-290 Signal & Systems and 18-370 Fundamentals of Control. 18-794 Pattern Recognition may also help me recognize the accurate steering motions.

 

Qiaoan’s Status Report for 02/11/2023

Week 2/5 – 2/11:

  1. Prepare for the proposal presentation.
  2. Build my 3D printer for future prototyping. Learn how to use Fusion360 to create 3D models and Ultimaker Cura to control the 3D printer. Successfully print a test file to make sure the printer is ready for future prototyping.
  3. Search about possible gyroscope options available for purchase. One possible option is LSM6DSR from ST Microelectronics. It fits our requirements based on the info I find. There are many other gyro modules for sale on Internet, and I think gyros around $10 should be good enough for our project if we want to use cheap as an advantage for our solution.
  4. When designing the steering wheel, I prefer to set around 11 inches wide and 6 inches height. Also about less than 2 inches wide thickness if that’s enough for microcontrollers and battery.
  5. I think I’m on schedule. Next week will be focusing on the design of the steering wheel. I think I will come up with a draft for it together with Xiao. I will also order a gyroscope and look into its manual to see how it works.