Category: Team Weekly Status Reports

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.

 

 

 

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.

Last week all the team members are focusing on our primary goals to build or design the components of our tasks. We also spent time individually completing the ethics assignment.

The hardware system has built some successful demos of wiring and buttons. More progress on gyroscope and potentiometers will come soon by this weekend. The gyroscope system has detailed the function designs for the tunning and mapping of gyroscope readings. As the Windows laptop is received this weekend, there will be more developments on software by this weekend, though now it’s a little behind the schedule. Based on the discussion last Monday, I hope the current design of functions should provide a clearer view and explain the reason behind better. We can start running tests on this once the hardware is ready.

The team is a little bit behind the schedule considering the interim demo will be on the beginning of April. We are not sure about if the tunning design is a possible approach to solve the problems we have and only testing on hardware can answer this question. We should start testing as soon as possible.

The past 2 weeks, including the Spring Break, had mainly two focuses. First one is to reorganize work assignments to our team members and get the design report written and submitted, and the second one is to order the parts and start building hardware and testing software.

The design report was a big challenge for us. We stupidly ignored everyone’s advice on starting early, and left ourselves with barely enough time to finish the report. We did try our best to gather every piece of information we could on the parts chosen, and documented every step in coming up with our design. The truth is, we messed up because we were all too busy with the sudden workload increase from multiple midterms, and we were focusing perhaps a little bit too much on actually building the device, rather than writing the report.

Schedule updates:

Hardware is on schedule. We expected delays during the spring break, but it turns out the parts did arrive very quickly. Building and testing has begun ahead of schedule.

The software is mostly on schedule. We are beginning to try installing and running demo programs using the Python packages we have identified in our design review. During the process, we went through challenges in installing as some packages are not maintained and stable. Alternative solutions have been experimented and we aim to run demo programs successfully next week.

The gyroscope system is mostly on schedule. We have came up with initial designs to implement the system. We have started writing the python code based on our design for the tuning functions. Though we cannot start testing the design without the hardware, we can draw graphs with mock data to see the output of the function.

This week’s focus has been mainly getting the design review presentation done, and reflect on the feedback from faculty members.

We have made preliminary design choices based on use case requirements, as outlined in our presentation. However, it was after receiving the feedback from faculty members, that we realized we’ve ignored a  very important step in the process. We directly based our design choices on use case requirements, because they were already quantitative metrics we were able to use when designing. However, it is very important to first translate these use case requirements to design requirements. It is a subtle difference, and in our case it probably wouldn’t have made an impact on our design choices, but nonetheless we should have done it as part of the product design process.

Our team is more or less on schedule. We have now passed another major milestone in the course, and with the spring break coming, time really is starting to look scarce. We originally planned to start ordering parts right after our design review presentation, but with the feedback we’ve gotten, we have decided to take some time and re-evaluate our choices. We’d like to document about each component as much as possible before the actual purchases are made, to be absolutely sure of the compatibility between components and the capability of them. Thus, we are going to meet next week, before the spring break, and finalize our component choices. Purchase orders are expected to go our before spring break.

The most important risk now is not certain whether a task can be finished or not by each team member since everything is pretty abstract now. We are actively communicating ideas in our chat group and after each class, following the Gantt chart we created during the proposal.

After the proposal presentation, we realized certain things our team lacked. In our design, we agreed to include more details including diagrams and hardware specifications in our presentations. We also realized that our solution approach section in the presentation should be more related to how the entire system is structured rather than solutions to a few technical challenges. In the use case explanations, we realized that we focused too much on an engineer’s perspective rather than a real user’s perspective. In the next discussion on creating design presentations, we are going to modify our use case requirements.

We also need to figure out how those components we mentioned there will interact with each other, speficially, what kind of data should be transmitted from one part to another part, and what should each part act in different scenarios.  The team is discussing a flow chart to clarify this and we think we will present a flow chart for design presentation.

Since the team is still working on the initial design, we don’t have much update available. We believe our progress are on schedule and no update is needed.