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.

Posted on

Xiao’s Weekly Status Update 04/01/2023

The first half of the week I was focusing on getting a test bench style hardware setup.

The above test bench was what I ended up with. It can be connected to any wifi network for our team members to use anywhere for development. At this point, hardware setup for the preliminary demo is all complete. IMU is able to output raw data (acceleration, gyroscopic, magnetic, each with 3 dof). ADC reads raw voltage input from the potentiometer. All 16 buttons work.

On Monday I transferred this setup to my team mate Qiaoan for coding and testing of gyro algorithm. Over the course of this weekend I will coordinate with him to get the hardware control part all working as a whole.

As the preliminary demo is imminent, I think my part is right on schedule, but could have gone a little bit faster.

Posted on

Team Status Report for 03/25/2023

Last week all the team members are continue designing and implementing both hardware and software. Our team members also gathered together to discuss what we have learned from the ethics assignment and considered worst-case scenarios when our product is used badly.

The hardware system part has made progress in wiring and is expected to be finalized by this weekend. The gyroscope system has generated the design on processing raw data from angular velocity and accelerations to degree output. For now the workflow of geroscope system is finished with design part, the next step will be start testing once the hardware system is ready. The program on RPi works well for now but there are still some issues with the packages on the PC that needs to be resolved. We are all working on our pieces so a reasonable prototype can be put on during the interim demo.

Our team is still a bit behind schedule as the interim demo is approaching. We need to have more meetings next week to synchronize our progress and discuss in what way we should present our progress during the interim demo.

Posted on

Yuxuan’s Status Report for 03/25/2023

This week I’ve successfully installed and tested the Bluetooth module on Raspberry Pi. It’s able to act as a Bluetooth client or a server. However, I’m still struggling to get the Bluetooth module to work on windows PC. The program will have OS errors only when calling certain functions. I’ve spent a significant amount of time following the solutions online, including installing Windows 10 SDK and installing build tools from Visual Studio to compile C++ code, but the error still exists for now. Some progress is made when testing with the controller emulator as the Xbox tester program can accurately detect the emulator’s input from the tester program as shown below.

https://drive.google.com/file/d/1a4xpNfXjKo9RPMEPMMTBzyBwYentaU0O/view?usp=share_link (Couldn’t upload images for some reason)

Next week, the primary focus will still be making sure the Bluetooth connection can be established. I’ve just found another solution that simply uses the socket library with Python 3.9+ on Windows 10 to establish a Bluetooth connection. There are only a few discussions about it online but still worth a try. The next step will be talking with Xiao and Qiaoan so we can agree on the data format to be sent between RPi and PC. My initial plan is to use json. I’m still a little behind the schedule due to the problems with bluetooth package on PC. I will catch up as much as possible to make sure the Pi can control the game on PC before interim demo.

 

 

 

 

Posted on

Qiaoan’s Status Report for 03/25/2023

This week:

For unknown reason wordpress is stopping me from uploading images. It says The uploaded file could not be moved to wp-content/uploads/sites/230/2023/03. I’ m sorry about this and will try to add pictures back once this gets fixed.

The gyroscope system is still waiting for hardware to be ready for testing. This week let’s discuss how we can use the gyroscope readings to generate the degree output we want to feed in our functions from last week’s report.

The gyro section of data from the gyroscope should be the point we want to focus on. The reading is based on angular velocity in degrees per second. The key point is to transform this velocity data into the angular position.

The pseudo code solution could be like this: (I want to upload image for this but wordpress does not allow me to do it)

# We keep running the degree calculation in a loop
while True:
  curTime = time.time()
  deltaTime = curTime – prevTime # Get the time difference from the last reading
  deltaDegree = dX * deltaTime
  degree += deltaDegree
  if degree > 360:
    degree -= 360
  if degree < 0:
    degree += 360
This seems to be a working example to calculate the angular position. However, such method will be affected by errors and will get more and more inaccurate as time passes. Without testing I cannot determine how severe the problem could be, but we can use accelerators to calculate the current angles to calibrate the degree output.
I have a picture to explain this, I will add it with explanation after the bug gets fixed.
Assume we read accX, accY, accZ from our raw data. If we plot the direction R shown by acclerometer on the x, y, z space, and we want to map the vector on to xy, xz, yz plane as accX, accY, accZ (maybe normalize them). In our case, suppose the degree on yz plane is what we want (aka we want the reading of x’s degree), then we can easily know that cos(x) = accX/R, which means we can get x’s angle by arccos(accX/R). Then we can know the exact degree reading at the time we want.
Both two cases stated above can be used. The way based on gyro data seems to be easier, but the accelration based method is much more accurate. I will test both methods then the hardware is available.
Posted on

Xiao’s Weekly Status Update 03/25/2023

This week I have been working on completing the hardware wiring of our project. I set out planning to connect every breakout board on a piece of breadboard, and attach everything to a temporary 3D printed back plate for easy transportation.

I encountered some problems with I2C buses on the RPi at first. As our power management, gyro, and ADC all use I2C (4 addresses in total), It presents a heavy load on one single bus. What happened was that one of the addresses for power management would keep disappearing, leaving the power management board inoperable. I later solved it by creating a second I2C bus using two extra pins on the RPi, and connecting the power management board to that new bus separate from the gyro and ADC. ADC is now wired up with the potentiometer.

On Sunday hardware operation code will be finalized, and pushed to GitHub. Then I will give the completed hardware system to my team mates for  the software side of things.

Posted on

Team Status Report for 03/18/2023

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.

Posted on

Yuxuan’s Status Report for 03/18/2023

This week I spent some time reading the ethics papers and finishing the ethics assignments. I received the Windows PC this weekend and was trying to run the demo programs using the packages specified in the design. I also ordered a second RPi for pure sensor and software testing purposes. The PC also matched the minimum requirement to power up the game. I’m a bit behind the schedule this week as projects in other classes due this week took an unexpected amount of time. For next week, I will spend more time catching up on running and developing the programs based on the demo program on PC so that it can establish the Bluetooth connection and read data from the game.

Posted on

Qiaoan’s Status Report for 03/18/2023

This week:

For the function to migitate the handshaking of users, based on the Gaussian filter model I mentioned last time that help generate a diffused image by getting weighted average value around a certain point, I would like to generate the ouput by a weighted average of a series of x, y, z readings from gyroscope.

Suppose we use x_n, y_n, z_n for note the x, y, z reading from the gyroscope at a certain time, and a_n, b_n, c_n for their weight. Then the output degree should be a result of combination of x, y, z reading from several previous readings that doesn’t differ very much as follows:

The target of tunning should be determining the value of n that indicates the number of previous readings that we want to use, and the a, b, c values to determine the weight of readings from x, y, z and based on the time of the reading (which means newer readings will have higher weight).

 

We will then talk about the logistic growth function that maps the gyroscope reading to output to the game, I have tried several possible combination of parameters. The function can be written as:

L means the range of our data, here since our degree output should be 0-180 degrees in each direction, so for the f(x) of each direction we define L=180.

k means the logistic growth rate, or we say the steepness of the curve, finding the correct value of k should be our target when tunning the steering wheel.

x_0 means the x value of the sigmoid midpoint. Here $x_0$ = 90 since we want the range to be 0 to 180.

I have tried several k values for this function to generate the mock output graph. Determining which k value to choose will depend on our testing result after the hardware is built. The graph is shown below:

The workflow of the gyroscope system should be defined as first reading the raw data from gyroscope and store them in a first in first out list of n readings. Then use the n readings to generate the weighted output and send the result to the logistic function to map the reading to the final output.