The thumbstick is one of the final components that need to be tested before fully assembling the glove. There was already a ring for mounting the thumbstick, so it was only a matter of time before we had to start testing it. This thumbstick will be mounted on the user's index finger, on top of the glove, and can easily be operated with the user's thumb.
The Thumbstick
The thumbstick is smaller than most joysticks, almost the same size as a Nintendo Switch joystick. The thumbstick can operate on 3.3 V logic and is self-centering, so it can easily return to the center position. It also has 6 pinouts instead of the usual 5 pins as seen below in the technical diagram. There is a separate pin for GROUND that connects to the tactile button or switch on the joystick. The user can press on the thumbstick to feel the button click.
How This Thumbstick Works
The thumbstick is a fairly simple sensor; 2 potentiometers are acting on different axes. One potentiometer accounts for the left and right movements while the other accounts for up and down movements. The 2 analog pins are connected to the analog input pins on the microcontroller and their values can be read from the serial monitor in the IDE. The button is connected to a digital pin on the microcontroller and the state of the button can be read as either 0 for pressed or 1 for released. The button debouncing can also be adjusted in the code. Libraries can also be installed to get the button state.
Initial Challenges
Initially, the joystick readings were all 0 due to soldering issues, so new joysticks needed to be soldered to get proper readings that would start at approximately 300 when the joystick is not being moved and then change to around 120 to 500 depending on how far the joystick is moved from the center position. The joystick also has a button as mentioned earlier, so a library called "ezButton.h" was installed in the IDE to help with button debouncing.
Thumbstick Readings
During the process of testing, I noticed that the neutral position of the thumbstick did not yield equivalent analog readings. The potentiometers were outputting different values despite being connected to the same Vcc and GRD. The first analog signal was outputting a value of about 310 while the second analog signal was outputting a value of about 350. This is most likely due to the fabrication process that the resistors in the potentiometers underwent, causing this slight difference. Thus, they had to be scaled in some way.
C Coding
After ensuring the components are functional, code needed to be developed for the thumbsticks. Specifically, there needed to be a way to calibrate the thumbstick and also configure the directions.
Thought Process
The calibration has to begin when the user holds down the button on the thumbstick for 3 seconds. Rather than have a software program that starts the calibration, it would be easier to start a calibration with the hardware that is already available on the thumbstick. Then, the process would wait for the user to push the thumbstick in a direction to start collecting readings. This is required since every user that will put on the glove has different-sized hands, so one user's forward direction will be slightly misaligned with another user's forward direction. Thus, the code needs to calibrate the directions accordingly and be able to do it repetitively during the symposium.
Calibration Calculation Approaches
There were some challenges to this calibration process as there were multiple approaches to creating this process, but it was a matter of finding which one worked best. Initially, I decided to use the raw potentiometer values for calculating the regions of the directions. The user would be prompted to push the thumbstick in the forward, right, down, and left directions to get the average values of the potentiometer readings for each direction. Then, based on these average values with the thumbsticks, arbitrary thresholds would be generated for each direction including the neutral and then the calibration would be complete.
This was a simple but longer process, as it required having to find every direction's threshold and using for loops to repeat the calculation in each direction. However, not only was this approach inaccurate but it also led to non-orthogonal thumbstick operation. Specifically, the thumbstick would not act like a modern joystick, where all the directions are exactly 90 degrees from one another. This initial approach would make users generate their regions for each direction on the thumbstick but it would also inadvertently change the angles between the directions, which would easily lead to missed inputs. Thus, this approach had to be scraped for a new one.
With help from a colleague, a new approach using normalization and polar coordinates came to fruition. First, the readings had to be normalized to follow something similar to a Cartesian coordinate grid. Then, a radius and angle can be generated based on each reading. This would only require the user to input their forward direction, and based on those polar coordinates, the orthogonality can be maintained when determining the next direction as every new reading would generate a new polar coordinate relative to the forward direction.
In essence, after holding down the button for 3 seconds, the user enters calibration mode Then, the user would be prompted to release the thumbstick and it will self-center. That will allow the code to normalize the thumbstick's raw data readings to find the neutral position. Next. the user will push the thumbstick forward for 3 seconds to generate a polar coordinate with an angle that is scaled and used to compare against specific angles to maintain orthogonality and appropriately determine the direction of the thumbstick with respect to the user's calibrated forward position. As seen in my demo below, the forward position is calibrated in 2 different directions and its angle gets scaled to 45 degrees so that it can create the appropriate orthogonal boundaries for the other directions.
Next Steps
Overall, the thumbstick code works with the component and can be used for moving the player in the virtual environment. The next steps include making the code output ordinal directions such as northwest which would be forward-right. There is also some slight drift that rarely occurs so finding a way to filter those values would be ideal.
Updates
An edge case that should be accounted for is if, during the start of the calibration process, the user is holding down the button of the thumbstick while they are pushing it in a certain direction rather than keeping it centered; when they are prompted to release the button, they can either fully let go of the button and let it self-center or they might slightly lift their thumb off the button until they feel the click but will keep pushing it in a certain direction, which can skew the neutral position.
As a result, another while loop in the code was added that uses the raw analog readings and raw neutral position thresholds that were determined experimentally to check whether the user is in a certain direction after letting go of the button in the thumbstick. If this is true, they are prompted to let go of the thumbstick and let it self-center so that the code can normalize the thumbstick's raw data readings to find the neutral position. The raw data is used here since normalization always takes place after collecting raw data.
References
[1] K-silver.com, 2024. http://k-silver.com/ueditor/php/upload/image/20230927/1695795678134550.jpg (accessed Mar. 01, 2024).
Bình luận