Posted on

Xiao’s Weekly Status Update (04/22)

I’ve been working through Spring Carnival to get the first prototype working. It is indeed integration hell. The job of designing the 3D models for the enclosure was shifted from being Qiaoan’s to mine, since he was busy working on the Magwick algorithms for the gyroscope. I designed and 3D printed the enclosure, did custom wiring and now the whole thing works. I also integrated Qiaoan’s gyro implementation and Yuxuan’s gauge UI inplementation.

One small problem is that now the power delivery module is not bolted on to the RPi anymore, and the single power and ground wire I used was not enough for the power requirements of the RPi 4. I will try connecting multiple wires to all of the RPi’s power terminals to solve the problem. So far, the problem is not affecting the performance of our controller (other than the ugly low voltage prompt that is on top of everything LOL).

We are on schedule for next week’s presentation.

Posted on

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.

Posted on

Yuxuan’s Status Report for 04/22/2023

This week I’ve been focusing on solving the lagging game data that I encountered last week when I was trying to let PC send car outgauge data to the dashboard connected to the Pi. I fixed the issue by separating the data reading and writing logic on PC side. There is a program that specifically writes game data to a file without blocking. Then, there is another program that reads the data continuously from the file and then sends them back to the Pi.

In addition, I updated the readme file on the github repo that includes the workflows for running the dashboard programs. Though I haven’t gathered quantitative data, from my personal experience in testing, the dashboard on Pi reacts much more quickly to speed changes in the game than last week. 

As shown on the screenshot, when the speed is at 39 km/h, the needle on the dashboard is also pointing at a bit under 40.

Next week, I will work with other team members to debug the system and implement codes for testing.

Posted on

Team Status Report for 04/08/2023

 

This week we’ve been working on the remaining features of our mobile controller after the interim demo. We discussed our remaining tasks to focus on and updated the Gantt chart.

On the hardware part, Xiao has been working on modeling a new case that can fit existing electronic components into it. On the gyroscope system side,  Qiaoan has been making efforts to implement and test the Madgwick filter to make the readings more accurate. On the rest of the software part, Yuxuan has been working on integrating the dashboard GUI onto the display connected to our RPi controller.

Next week we are going to continue working on these pieces which we are going to put together the week before the final presentation. We need also need to discuss the testing and validation requirements for the final presentation.

 

 

Posted on

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.

Posted on

Yuxuan’s Status Report for 04/08/2023

This week I’ve been focusing on reading the data from the game and updating the data on display.  So far, I’ve been successful in reading car data such as speed and rpm from the game through it’s outgauge protocol. On the display side, I’ve found a car dashboard template implemented in HTML, CSS, and Javascript that changes once keys are pressed. I’m working on integrating the template into our own project such that when car data is received from the PC on Pi, a JS function will be triggered to refresh the dashboard page.

I’m currently on schedule as now my focus will be adjusting the GUI for the display on the controller. Next week I will continue to work on the integration and test the display effects on the second screen we bought last week.

Posted on

Xiao’s Weekly Status Update (04/08)

This week for me, my work focus has shifted from electronics to 3D modeling. I have measured all the components and made rough models of them. The next step is to design an enclosure and stuff everything inside. So far on schedule.

For testing, first of all the electronics are on a piece of breadboard and functionalities can be tested. During interim demo this has already been done. Second of all, the 3d printed enclosure will be test fitted and any modifications can be made easily. After the whole assembly is complete, the battery life will be tested by keeping it connected to the computer for a long time and record time. The controls will be tested by seeing raw input values in the game and comparing that to our desired values. If anything is not working as expected, we either have the member responsible to make changes, or declare the design feature a failure.

Posted on

Yuxuan’s Status Report for 04/01/2023

This week I’ve been focusing on integrating the Bluetooth connection module with the emulator mappings. RPi and laptop can now use Python via Bluetooth by sending JSON packets that encode the raw button input format. On the PC side, after receiving the packets, the program can decode the value and maps the keys in JSON to the emulator which presses or releases a button based on the values of the raw button input in the JSON packet.  I also updated the README on Github which details how to pair RPi to the laptop.

The next step for this weekend is to continue to work with my team members to integrate the hardware part, especially the button reading section into the program. Once the real button values are encoded in JSON packets and sent to laptop, we will have a full pipeline for interim demo.

Posted on

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.

 

 

Posted on

Team Status Report for 04/01/2023

This week for our team has been mostly related to integration and collaboration. Hardware setup (wiring and basic hardware interfacing code) has been completed by Xiao, and hardware has been handed over to Qiaoan for further development on IMU algorithms. Yuxuan has acquired another RPi and has been doing development work on Bluetooth transmission and gamepad emulation on Windows. Both Xiao’s and Yuxuan’s parts have been demoed in our weekly meeting to all team members, and development on the gyro algorithm (Qiaoan’s part), as well as integration, is ongoing.

This weekend before our interim demo, we are all focusing on integration. After chatting with faculties on Monday, we decided that our demo should have a complete pipeline working, that is, from hardware key presses, to transferring hardware state over bluetooth, and eventually to reading hardware status on Windows and emulating an XBOX controller.

We are on schedule for now. Integration has its difficulties and quirks, but we have planned for that and have two days working on it. Current expectation for interim demo is unchanged.