October - Combining Software and Hardware

Continuing my UI from last month, I created a new label that shows when a joystick’s button is pressed or released. After creating two functions, one for pressed and one for released, I used Window.bind() to make sure that these functions would continuously check the button status when the correlating screen was activated. For the next task, I needed to use Kivy’s Clock to schedule a function that would move a label based on the joystick’s position (figure 1). Using Clock.schedule_interval() to do this was intuitive, but referencing the joystick’s position wasn’t. I collaborated with my neighbor who had already completed the task, taking the time to learn how he had solved the problem and why he approached it the way he did. This gave me a better understanding of how to use Kivy and other libraries to interact with hardware.

Next, I learned the basics of controlling stepper, servo, and DC motors with libraries (figure 2), and the code used to do this was uploaded onto GitHub using what I learned last month. These new skills allowed me to begin working on a mini exhibit called the Perpetual Motion Machine (figure 3). Operating the gate, controlled by a servo motor, and the staircase, controlled by a DC motor, came easily to me, and I didn’t need any outside help. However, running one continuous loop of the machine gave me some trouble. Some of the functions were trying to run at the same time, leading to operations happening out of order. I solved this problem by creating a separate function to interact with the hardware, but scheduling the final operation using my knowledge of Kivy’s Clock (figure 4).

The final project I worked on to complete my software training was the Robotic Arm (figure 5). This involved more programming with stepper, servo, and DC motors. However, the Robotic Arm required the use of an air tank in order to move the air piston connected to its up and down movement. While programming, I found that the components responded to signals via small LEDs lighting up, but the air piston still would not move. After collaborating with Mr. PZ, we figured out that the Talon DC motor required 24 volts, but was only given 12 volts. Fixing this problem allowed me to successfully complete the rest of the tasks. The only problem I ended up with was requiring the Robotic Arm to be to the right of the homing sensor when the moveToHome() function was executed (figure 6).

DELTAs:
Structured problem-solving: When approaching bugs or errors, I had to look at my program as a whole and use my knowledge of Python and Kivy to understand why my code wasn't being interpreted the way I wanted. Because I learned that Kivy prioritizes most commands over updating labels, I would look through my code as if I was Kivy, trying to determine why certain lines or functions were being run before others. This helped me narrow down spots of error before tackling them on my own or asking for outside help.

Synthesizing messages: I had a friend from outside of the DPEA come into the computer lab to see my Perpetual Motion program in action. Instead of just showing her the machine, I explained the logic behind the program as best as I could. When she pressed buttons on the interface, I explained how they influenced the physical result. I did this while understanding that complex terms and ideas wouldn't have as much of an impact as digestible ideas.