DC Motor Lab

The added components required to complete this lab are a bit intimidating, so I need to slow down to understand every step along the circuit. I completed a preliminary lab in testing and adjusting the speed in one direction of a DC Motor using a potentiometer (videos here). One reason is that the H-bridge lab doesn't appear to explain everything sequentially, so I need to take a step back. This first lab makes sense and the motor responds well - and my cats reacted to it. I wonder if it's normal for a slight burning smell to occur; I kept it running a while and nothing burned out, but hopefully I'm not hurting the situation.

The real H-bridge lab seems to miss something in the explaining. In fact, in the photos the switches change and the LED is left out. I've set up the board exactly as instructed despite the lack of labeling on the H-bridge, and even after checking for proper component directionality, missing pieces and/or code glitches, the motor still does not turn on. I am setting up a help appointment.

After my help from my savior Jenny, it appears the H-bridge was the culprit. We thought maybe either my Arduino had burned out or something wire-related got caught in the breadboard, but just a faulty bridge and the fact that - for whatever reason (the lab online didn't seem to need this) - my motor needed a 9V external power source because it was drawing too much power off my 12V DC adaptor. She helped me get it running so fast that the only gear that I could use was a snug one that is hard to see changing direction, but you can still hear the result on video.

Simple breakthroughs happened for me on this lab at last too. For one, I'm finally starting to read through schematics with a little more precision and understanding, as well as understanding how this translate to more than one viable layout option on the breadboard. I know that's small potatoes for some, but it's important for me. I also learned which way is "up" on the H-bridge, which wasn't explained in the lab. And, headers, which were touched upon briefly in readings but never stressed online, seem to make the wiring more secure when troubleshooting. Finally, I'm just barely getting into tweaking existing code for my own purposes (I'm still not comfortable writing it out from scratch) - I was able to insert an AnalogWrite function to vary the speed of the motor, similar to the prep lab.

Lab 5 - Serial Output/Processing

So the good news is my camera's new, and even without knowing much about it it still takes better shots. Things kind of go downhill from there.

Unlike in the example, I used a photocell and pot as my two analog ins with my digital in switch. I'm starting to understand more fluidly the reason for scaling/ranging, it sometimes outputs a more stable or controllable range of data. My first send through pin 0 (the pot) emitted DEC values of around 227-228, while the 2nd time I tried a BYTE modifier in the code and my values were more á and "beta".
















I was ready to try sending serial communication using multiple modifiers. My results? In tabbed columns:
Aplha-Beta (BYTE/ASCII) 11100010-11 (BIN) 226-227 (DEC) E2-E3 (HEX) 342-343 (OCT)



Clearly, Arduino and serial i/o are communicating. When I sent BIN values for all 3 sensors, I got my continuous feed of A's until I entered a character, and in the serial monitor I received a 3-ASCII char response. Then I tried it with DEC variables and it spit back 0-255 values in response to the pot, plus values of 100 (off) and 255 (on) when I clicked the digital switch.



So why wouldn't Processing run my program properly when all other communications were verified? I can tell you I checked many factors over and over again, and checked with many people including my professor, students and PhysComp grads on the floor. I could have perhaps used a multimeter to check voltages across the circuit, but other tests ascertained it was not a hardware problem but a code one in nature. Having never seen the Processing environment before (I am not in ITP and haven't taken ICM), I can tell you the code was different enough to make things difficult to debug alone, but I picked up a few tips from others along the way, including writing in println statements at each step to ensure messages were being received. We did deduce that somehow color messages (supposedly controlled by the digital switch) were not being sent - or were sent only as pure black, rendering visibility impossible on a black background - so we changed that part of the code to a constant white value. Good, at least it's on the screen.



And it stayed mostly upper left thereafter, at first with a lot of jostling back and forth which meant control with the pot wasn't smooth and obvious, until some extra tweaks like ridding the code of tabs in the printout, which slowed the ball down considerably. But at least some tangible result was reached. I owe my newest ITP floor buddy Kristen a lot in helping me understand Processing better, so I will take this as a "whatever doesn't kill you makes you stronger" moment. Thanks, Kristen!