This week I mainly worked with Xiao to do the testing. My main focus is on latency. Previously the testing method is inserting time.time() before sending and after receiving the request and find the time difference divided by 2. However, this method seems to have some flaws since it isn’t necessary that send and receive times are equal. Therefore, we again used the slow motion camera to measure the time the button is pressed and the time input changes on the screen. The result hovers around 116-125ms which is around 6 times worse than our design requirement of 20ms. A few improvements we later discussed can be reducing the response message length to minimum and removing all the prints on the screen. We also make sure that the latency should be tested at different distances.
Next week, we will refine our testing and start working on the poster and final report. I will also try to invite 3 users to test our product.
Xiao’s Weekly Status Update (04/29)
My task this week is the testing of all the metrics of our design. Since I am responsible for the integration, and I have the device, I am mostly responsible for actually doing the testing and gathering the data, while my team mates are responsible for designing the tests. We have met our design goals in some areas, such as gyro drift limit and battery life. However, some metrics such as weight and gyro oscillation are not as fine-tuned as we would like.
Videos and pictures of testing results are in the Team’s Status Report.
We are on track. Test data is ready to be incorporated into the final report.
Team Status Report for 04/29/2023
The team focus on performing tests this week. Generally speaking, the results we get are not satisfying, as we find some outputs are different from what we expect. We are keep trying to migitate those problem, and this could be a risk for us to finish the project. However, the user experience looks good as we keep using the mobile steering wheel to play the game.
Weight test:
Our project has a weight of 666g and our design goal is 400g. It seems we underestimate the weight of our components, and probably made a mistake when define the use case requirement: the joysticks we refer to do not have a big screen and a battery as large as ours, so we may want to change our use case requirement.
Battery life test:
Our project has a battery life for approximatly 4.5 hours, and our initial design aims to have 8 hours of battery life. The test results is generated from our measurement for the power consumption of our project for an average of 4W, and we have a rechargable 18.5Wh battery. The screen drains a lot of energy and we cannot add larger battery due to our trade-off between weight and battery life. I think we need to change our use case requirement for this, since 4.5 hours should be enough for normal players.
Latency test:
We plan to have around 30ms latency for the bluetooth connection. We use a slow motion to record the frames passed between the time we press a button and the time the computer receives it. In our camera has 240fps, our project takes around 28 frames to make response, which gives us a latency around 116-125ms. This differs a lot from our expection, and we are thinking if we should change our design requirement, as the experience of latency is not that large when playing with it.
Gyroscope drift test:
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 degree. The result shows that the gyroscope output has some noises, but its avearge’s change is with in the 1 degree limit, as the data shown below gives us an average change within 0.8 degrees for 8 consecutive readings, and it’s not drifting away.
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.
Final Presentation
Team Status Report for 04/22/2023
This week we’ve been integrating hardware, gyro algorithm, and software pieces together into a runnable game controller. Xiao has 3D printed a steering wheel case that encloses all the hardware components and wirings of the controller. Qiaoan has been working on the gyro tuning and refining the algorithm. There were some subtle bugs in our implementation of the Magwick algorithm which Qiaoan fixed this week. Yuxuan has been working on the lagging game data issue and was able to fix it by writing the data first into a file and reading them separately.
So far, we have a running mobile steering controller that controls the car via Bluetooth when buttons are pressed and when the steering wheels are rotated. The short demo video can be found at https://www.youtube.com/watch?v=I0n3i1ka-VY.
Since we are still working on our final presentation so we haven’t done any quantitative tests yet, but the details of the test procedure will be included in the presentation. Next week’s focus will be following the test procedure and gathering quantitative test results. We also need to start working on the final report early to ensure its quality.
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.
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.
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.
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.