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.
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.
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.
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.
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.