User:Shatton8111/enes100/my work 2

This is a part of Helicopter Project, Part 2.

Write problem/project Goal
To create an Arduino-based quadcopter that flies itself without a remote control.

My First Task
I'm planning on testing the power supplies and dual-ESC test for reliability, during the engineering club this week. If that goes well, then I'll be putting the gyroscopic sensor and (propeller-less) two motors on the seesaw. I hope to simulate the motors compensating for detected imbalances.

Summary of actual work over first weekend
I worked with Jromanch0088 and Spark93 to test the thrusts of the Zagi 5 Amp ESC's with their motors and the Thunderbird 9 ESC's with the Hacker A10-13L motors.

Week1 Narrative
Testing the Smaller Motors

In class, I worked with Jromanch0088 to test the thrust of the Zagi 5 Amp ESC's and their motors. Initially, the burn-out test wasn't causing the ESC to spin the motor in a controllable way: it would wait for several seconds, increase its speed suddenly, and then stop.

After some experimentation with different servo speeds (which correspond to pulse widths) and millisecond delays in the Arduino code, I remembered that the Zagi 5 Amp ESC's had a limited range of 0 or 60 to less than 160 (for servo speed values). The burn-out test wasn't well suited for this, since it was quickly looping from 0 to 500, 500 to 1,000, then 1,000 to 5,000, and then back to restarting at 0.

So, I changed the test code to gradually (but quickly) increase the motor's speed from 0 to 150, since 160 seemed to put the ESC into its unresponsive fail-safe mode. It would this speed indefinitely, until the program was restarted or the Arduino or ESC lost power.

Using this simple test program, and having the motor mounted on a block of wood with string tethers to keep it from flying far, the motor was able slowly spin the block of wood as if it were producing enough thrust to hover above the table. However, because the block of wood didn't lift itself off of the table, I'm not certain it was producing enough thrust. It's more likely that the block of wood was spinning in response to the angular momentum of the propeller.

Interestingly enough, the test did not last very long. Within seconds, others in the room smelled something like burning grease. The motor quickly stopped, and became unresponsive to further attempts to start it. When moving the propeller manually, it seemed to not spin as freely as it had. However, the ESC still responded to signals with its indicator light. Because of this, it appears that the motor, but not the ESC, had died.

Testing the Larger Motors

The next day in class, I worked with Spark93 to test the thrust of the Thunderbird 9 ESC and Hacker A10-13L motors. After removing the smaller motor from the wooden test mount and replacing it with the larger Hacker motor, the test was started with the Thunderbird 9 ESC burn-out test.

There were some initial problems with wiring, but once they were figured out and the wooden test mount was secured by weighted-down strings, the motor spun rapidly and seemed to move a lot of air. However, the motor didn't appear to raise its platform above the ground.

After comments from another student, the motor was mounted on a narrower platform which would hopefully allow the moving air to push against the floor instead of pushing against the platform. This didn't appear to help though, because the air above the propeller appeared to be moving while the air below it appeared to be mostly still.

At one point before a presentation of the experiment, the motor and ESC were "chirping" and wiggling, but faintly. I'd seen this before with low electrical currents, so I assumed that the power supply wasn't providing enough power to the ESC. Unfortunately, I didn't measure the current. After unplugging the experimental setup, checking the wires, replacing two wires, and plugging it in again, it appeared to work.

However, while the testing platform was able to skid across the floor, it wasn't able to lift off. The direction of the airflow needs to be determined. One possible way of testing this could be to attach two fans on the seesaw. The balance might allow the fans to push in their current directions more easily.

After several tests, the smell of burning grease filled the air. I stopped testing, since I wanted to save the motor, in case it wasn't completely burned-out yet. Both the smaller Zagi 5 Amp motors and the larger Hacker A10-13L motors showed signs of burning-out when they were near their tested maximum speeds and while they had propellers attached.

Conclusions About the Lift and Stress

In previous tests without propellers, the motors never appeared to have this problem. My guess is that without a significant load to stress the motors, they are able to spin for what seems to be indefinitely and without signs of wear or damage. But if the motors are stressed significantly, by using their maximum capacities to attempt to move a volume of slightly viscous air for a duration of time, the motors appear to rapidly accumulate wear, possibly in the form of overheating.

Because of this, the helicopter design might need some fundamental changes. It may have to be very light in order to use the smaller motors. It could to use a number of motors in order to produce enough thrust to lift off the ground. Or, it may require one or more larger motors for a more traditional style of helicopter.

My Second Task
Next, I plan on testing two motors on the seesaw. This should allow me to test the production of thrust by the motors, gyroscopic stabilization, and independent motor/ESC control.

Summary of actual work over second weekend
I worked with my team to set up the seesaw for thrust balancing, and I tested and learned about 5DOF gyro-accelerometer sensors.

Week2 Narrative
Setting up the Seesaw

In class, the team and myself worked on assembling the seesaw apparatus for thrust balancing. I mainly helped by getting parts and giving suggestions. Once finished, several factors, such as the asymmetric tether position and motor distances, were noticed that unbalanced the seesaw or biased its direction.

Videos
 * Finding the Bias of the Seesaw

My Third task
Next, I plan on testing a small-scale version of the seesaw thrust balancing test by using the smaller Zagi 5 amp. ESC's and motors. This will involve gyroscopic balancing.

Summary of actual work over third weekend
This week, I was not yet able to test the gyroscopic sensor with the smaller propellers. Instead, I focused on controlling the Zagi 5 Amp ESC's and their motors with the Arduino Mega 2560. I was able to create a framework in code that allows multiple motors to adjust their speeds in a synchronized way with each other.

Week3 Narrative
At home, I experimented with controlling two Zagi 5 Amp ESC's and their small motors with a single Arduino Mega 2560. At first, I had problems with communication between the ESC's. I would send messages to both ESC's, but they would only chirp and wobble back and forth.

As a sanity test, I ran the burn-out test for the Thunderbird 9 ESC's with only one Zagi ESC. It worked, so I began experimenting with it. I reduced the differences between the new code I had written and burn-out test by removing the speed-ramping code and by making the burn-out test stay within the safe speed/pulsewidth range for the Zagi 5 Amp ESC's.

Eventually, I found that having a delay of at least 15 milliseconds, incrementing or decrementing the pulsewidths (speeds/values for servo.write(speed)), and keeping the pulsewidths within the safe range for the Zagi 5 Amp ESC's (~70 - 158) all appeared to be factors in keeping reliable control over the ESC's, whether a single or multiple ESC was being controlled.

After this, I worked to create a framework of code that would allow multiple ESC's to be controlled easily and simultaneously with the option of either independent or synchronized control. My current code can be seen online. As can be seen in the code, in the "loop" function there is some commented-out code and an uncommented call the the "doStep" function. The commented-out code allows for more direct manipulation of the motors, while the "doStep" function relies on the "steps" array, at the top of the program's code, for synchronized steps.

Videos for Multiple Zagi ESC's:


 * Part 1: Assembling


 * Part 2: Communication Problems


 * Part 3: Still Not Communicating


 * Part 4: Single Motor Works


 * Part 5: Communication Problems Again


 * Part 6: Single Motor Works Again


 * Part 7: Two Servo Objects Controlling One ESC


 * Part 8: Two Synchronized Motors


 * Part 9: Synchronized Steps


 * Part 10: Synchronized Step Feedback

My Fourth task
Next, I plan on working with the gyro-accelerometer sensor to stabilize the system on the seesaw testing apparatus. After that, I would like to also work with the Arduino, motors, and synchronized-stepping code to be able to tell the system to orient itself to given angles, apply specific thrusts, and continue at the setting for a duration of time.

Summary of actual work over fourth weekend
How is what you did different than what you planned?

Week4 Narrative
During class, I edited my code for coordinating multiple Zagi ESC's, and I ended up with something completely different: code for controlling motors with tilt. I'm now able to control two Zagi 5 Amp ESC's and their motors using the tilting of a 5DOF SparkFun gyro-accelerometer.

Here's a video of this: Controlling Motors with Tilt, Part 1

There are a few issues with this currently. For example, it doesn't respond very quickly to the rotation of the sensor, and I haven't accounted for drift in the readings from the sensor. That's why in the video I have to rotate the sensor to a variety of angles, because the sensor's definition of "up" continually rotates along each axis (X and Y).