 | ||
| We'll feel bad if Gregory is A.I. enough to feel this way |
Did I forget to mention that we named our robot Gregory? Ah yes, Gregory. He's coming along quite well.
Following the Alpha demos
We were fairly satisfied with the results of our presentation of our robot. We got to display our app, showcase the state of our robot's movement, and show how easily the robot can't understand what I'm telling it (okay, blame Google for that, though I tend to do poorly enunciate sometimes). It's all baby steps, but we're getting there. We definitely got to complete a lot more than what we thought we would have ready come alpha presentation day.
Though we definitely had a hiccup though during the presentation. There was a point in our presentation where our robot has failed to respond to our controller, prompting us to halt the presentation for a bit to restart ol Greg, for which the robot worked the following attempt.
So what exactly happened?
One of our biggest fear, that's what happened. A dreaded race condition from multiple active threads. A race condition occurs in multi-threading when two or more threads can access data (our robot) and change it. The way our robot works is for every time a button command is pressed, a thread is started for the corresponding movement. Upon release of the button, a stop command is sent, killing the aforementioned thread. Somehow a stop command was reaching our robot before we even start a command, causing the robot to be stuck within a stop command thread.
It was soon thanks to Professor Mueller that we were able to find out the root of our cause (she turned out to be an excellent client after all). She broke our program within seconds of handing her the Android device, resulting our heads spinning in utter confusion. We soon realized that if you quickly tapped a movement command, the intended move command was never sent but the release command (the stop command) registers, forcing the robot to be stuck in the stop threads and never able to start a new thread. This called for us to change the way our movement works.
And thus a fix
To combat clashing threads, we decided to change the way our robot moved. Previously, it moves in short stutters, listening for another command during the pauses. This was due to the robot moving a set short distance, being sent through a loop to stutter as a movement command was held. A new approached we used is to avoid using the LeJos's move commands, we synchronized both motors and directly powered them to turn on. This eliminates all of our pesky race conditions and lets us tap movement commands without fear of breaking. As an added bonus, we get smooth sailing movement (yay).
And... for the future??
So as we all know, we have pretty important individual projects due Friday. We decided to implement some short goals. I'll make it short since I've been rambling on for long enough:
- We plan to do a UI overhaul on our app. It's just bland with just 2 edit fields and 4 buttons. We want to implement fragments, or just a better way of organizing our options
- Joysticks. Currently we use four arrow images for the controller. We want to make a more dynamic joystick that allows us more freely control the robot, with better accuracy and fluidity
- Saving preferences. We plan on having a way to have "default" settings without manually entering the IP address and port number every time. We're aware that this could be done using Android's Shared Preferences or just store the settings on read-only file
And to close:
another Rick and Morty gif. enjoy (:
No comments:
Post a Comment