Posted on

Xiao’s Weekly Status Update 03/11/2023

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

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. For the hardware part, I realize that we are missing information on the design trade-off studies. We are aware of that and we will not miss this critical part in our final report. 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.

All the major components (components that cannot be sourced at a generic parts store or be found in my personal parts bin) have been sourced and have arrived during the spring break. Assembly has begun and hardware assembly is expected to be done by the end of this weekend, latest by the end of next week (Friday). I do expect little hiccups but so far so good. Currently RPi is setup with an OS running, and the UPS power source for the RPi is up and running (charging function still needs to be tested and API integration still needs to be done).

Posted on

Yuxuan’s Status Report for 03/11/2023

This week I’ve been mostly working on creating a demo on Bluetooth communication and writing part of the design review document. The package initially used for Bluetooth communication is Pybluez. However, the package is not stable on Mac OS. I tried to install and import the bluetooth package and it already says it’s missing other packages. After installing the missing packages, it then says it cannot find the method inside the package. I’ve looked at many issue threads related to it on the repo and still cannot fix the bug. I believe that the code is importing packages that have conflicting versions that require manual fixes on the code after installation.  I’ve also tried a well-maintained package called Bleak but it’s mostly acting as a Bluetooth client and it provides little documentation for creating a Bluetooth server.
An alternative way to establish communication between two devices is using a TCP connection via a socket. I’ve tested the round-trip communication time between Mac running as an echo server and iPhone running as client but the result is not optimal. Sometimes the round trip time is more than 200ms which won’t meet our design requirements. The TCP solution and USB serial connection should be put as our backup plan in case the Bluetooth connection solution fails.

The work is mostly on schedule. I’m going to focus on installing the Bluetooth packages on a Windows PC once it’s available next week. Once the Windows PC is received, I will also try to test the Xbox emulator package and codes that read data from the game. If all the packages can be successfully installed and tested, the latter implementation for the game controller can be much smoother.

Posted on

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.

Posted on

Yuxuan’s Weekly Status Report for 02/25/2023

This week I’m mostly looking into the details of how the program on the PC side can simultaneously handle data from the Pi client via Bluetooth and interact with the game. I’ve thought about using multithreading as I read into the tutorial, but I realized that multithreading is unnecessary since we only have one client and one server, so only a single connection is needed. A feasible way of implementing the program is by binding a socket to a port where the program can read game data. In addition, another socket will be created and bind another port for Bluetooth communication. Then, all the communication and actions can be done in a while loop. The initial file structure is created and some skeleton codes on the PC side are pushed to this repository on GitHub.
One block I realize is that the PYXinput Xbox emulator is used for windows only but I’m using a Mac for development. Also, only a powerful game laptop can power the BeamNG game for further testing. Therefore, I need to look for a way to borrow a game laptop next week.

The progress is mostly on schedule. The priority for next week is obtaining a gaming laptop. Both of my teammates use Windows and are pro gamers so I will ask them about this issue. Meanwhile, I’m planning to implement the program mentioned above on the PC side.

To fill in the gap for team members, I can talk with Xiao about the exact functionalities of the buttons and hardware so we can have a better understanding of what signals will be read and interpreted by the program. I can also talk with Qiaoan and assist him with tuning the gyro sensor by writing program that reads the outputs.

 

Posted on

Team Status Report for 02/25/2023

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.

Posted on

Xiao’s Weekly Status Update 02/25/2023

This week I have been mainly focused on getting our  design choices right, and presenting for our design review.

During the searching for components for our design, I was amazed at the vast selection the Internet has to offer. Following advice from Professor Mukherjee, and after taking a closer look at some of the products, I realized that for a formal project, I cannot just go on Amazon and buy from the cheapest vendor. We need data sheets for the components. That’s what prompted me to eventually find all the electronic components on Adafruit. They have data sheets, and also some tutorials listed under every product we’ve chosen.

Preparing for the presentation was something I should have spent more time on. We kind of rushed through making the slides, leading to a couple of typos which I am not very proud of. The first time I actually went through all the slides and practiced was an hour before the presentation. Gladly, I think it went OK.

It is a fact, however, that we are still not that familiar with some of the quirks of the components we have chosen, but we are making progress. I think from this point on, us three as a team should most importantly be more proactive about deadlines. Sometimes I am busy because I am taking too many classes this semester, and I am glad my team mates could help out. However, in the end we are trying to avoid this sort of rushing before the deadline situation.

Posted on

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

Team Status Report for 02/18/2023

We focus on preparing for the design presentation this week. We plan to come up with a design draft by Monday’s presentation with the components we want to use and the connection between them. We also want to present a control flow graph to show the stages of our project when it’s running.

One of the risks we might face is that our division of work is highly dependent on each other. The software systems on Pi rely on the specific version of Raspberry Pi we are using. The control systems can only be tested thoroughly only after the PCB board is produced. To handle the risk, we plan to talk more about our design ideas with each other and address how different components interact with each other in the design presentation.

We are still trying to make an initial design for our design presentation, so currently, we haven’t suggested any major changes to our design ideas demonstrated in the proposal.

One engineering principle involved in our design is modularity. As we divide a challenging project into three subsections for three team members, we know which area we should focus on and learn about. For each subsection, we tend to divide that into sub-components so that we can propose a specific solution for this component. The modular design allows us to not worry so much about what others are doing during the initial development and testings.

Posted on

Yuxuan’s Status Report for 02/18/2023

This week I’ve been designing software systems that allow Raspberry Pi and Windows PC to communicate game data. I’ve created a diagram as shown below showing how and what kind of data is flowed between different hardware and software as well as devices. 

The diagram uses blocks to identify major software components I need to implement in order to achieve communication between two devices. For each component, I identified certain libraries that can be used to accomplish the task in a document called Module Details in our shared folder on Google drive. It contains links to the library repo, discussions, and video demos.

I’m currently mostly on schedule as we are finalizing our designs this week.

Next week I’m planning to try implementing the process of retrieving data from the game using the Outgauge protocol as well as emulating the Xbox controller using the PYXInput library to establish a basic interaction with the game using codes.

The courses covered in this process are 18-213 and 18-349. Both involve creating software systems transmitting data from one device to the other via different protocols.