Searching for Stability Weekly Log
2/13/16
This week we successfully scaled down our initial project idea for a quadcopter to a more feasible product idea of an Arduino controlled 2-axis gimbal on a bike-mounted platform. As opposed to using an IMU, we decided to use two magnetic rotary encoders to challenge ourselves in the realm of electrical and systems engineering. Additionally, we finalized a project proposal after making some intensive revisions and created a detailed budget.
We have conducted initial research concerning the connection of the rotary magnetic encoders to the Arduino.
2/20/16
We completed a first design rendering for our stabilization platform; it is in the very early stages of development.
Components
Assembled Design 1
This was the second version we designed later in the week. It illustrates how the iPhone would sit in the gimbal and where our two motors would be located.
.jpg)
We were concerned that this mounting design would be impractical for a bike-rider as the gimbal would take up the entirety of one handle. However, after some research, we found that the majority of bike mounted devices sit on the handlebar and thus plan to model a revised design after pre-existing handlebar bike mounts. Additionally, we are including more specific compartments within the back slot housing the four 9V batteries and the Arduino to eliminate unnecessary confusion and jumbling of components.
In addition to these designs, we ordered our magnetic rotary encoders and vibration dampening pads and plan to order the batteries and motors once the budget is approved.
2/27/16
Our budget was approved! We ordered two Turnigy brushless gimbal motors and four rechargeable 9V batteries. Our encoders and vibration dampening pads arrived on Wednesday, however we got two extra relay boards while the two rotary encoder shafts were omitted from the shipment. We called the vendor and the missing components were expedited to us and arrived on Saturday.
We continued to update the 3D design of our mounting platform, altering the housing of the Arduino so that it would sit under the gimbal but above the dampening pads and adding a tray for the batteries instead of a back pocket. We began test printing on Friday. We printed the two basic components that attach directly to the bike handle and tested to make sure the dimensions were correct and that they fit together snuggly. While the first print failed due to the presence of internal faces, we re-printed after fixing the file and the dimensions appeared correct when tested for fit on a bike handle. The first print of the outer support component also failed due internal faces that confused the printer. From this failed print, however, we realized that some of the proportions were off as the Arduino could not fit in its designated compartment. Thus, we altered the design to make the compartment sufficiently tall and added some structural support to the two arms of the outer frame. After printing a miniature version to ensure that there were no more internal edges, we initiated a full-sized print of the outer frame. Below are images of the mounting device with the revised frame structure, the miniature print of the outer frame, and the two basic components for direct mounting on the bike.
Updated Design
3D Print of Direct Bike Mount
Miniature Print of Outer Support
With regards to programming the Arduino, progress has been relatively slow as we both are unfamiliar with the coding language. Natalie successfully downloaded the Arduino software (IDE) to her computer and uploaded and ran the "Blink Example". We are working hard to research how to go about writing code that will receive input from the encoders regarding the position of the motors and output corrections to the motor. Additionally, we are in the process of devising test cases so that we can test our code or portions of code without having to have a fully functional mechanical model.
3/5/16
This week we printed a preliminary phone case and the attachment mechanism for the case to the gimbal. We received our two gimbal motors in the mail but have yet to plug them into anything to see what they do our what kind of output they give. We had a productive first evaluation with Deko and Professor Humberto and determined where we need to direct our focus. Figuring out how to secure wires on moving parts will be a challenge, as will be designing the control program for the Arduino. I (Natalie) need to learn how to write interrupts.
Professor Humberto also told us that he did not expect us to be able to pull off our entire goal by the end of the semester. We need to focus on being able to get any corrective motion, no matter what speed, from the gimbal.
3/26/16
After struggling to make progress with writing Arduino code and not having had time to mess around with our ordered parts, we were finally able to get into lab for a substantial period of time. We had a meeting with Deko and we were able to control a motor (fan) with an Arduino Uno and a motor shield. However, we were unable to do the same for our gimbal motors and believe we might need a motor driver in order to do so.
After some research, we determined that we probably do not need the Hall sensors that came with our magnetic rotary encoders to generate the output we want, though they might give us better data once we have everything set up correctly. Using a tutorial and a schematic we found on hobbytronics.com, we built a circuit using an Arduino Uno and a motor shield to attempt to control the encoders. The code was meant to change the brightness of an LED according to the angle of the rotary encoder. While we got the LED to light up, we ran into trouble because no matter which way we turned the encoder, the brightness value either continued to increase or, if we changed the code, continued to decrease. Therefore the position of the rotary encoder was unable to dictate brightness according to clockwise v. counter-clockwise direction... a significant problem considering the objective of our project. The circuit we used is pictured below:
While we ran out of time to continue trouble-shooting, we have set aside time in the upcoming week to continue figuring out both components: the encoders and the motors. Our to-do list is as follows:
- Research driver for our BLDC gimbal motor
- Figure out encoder code that will account for clockwise v. counter-clockwise motion
- Find detailed schematics concerning the mounting of the rotary encoder
In addition to the circuitry/coding work that we did, we also assembled the base of our gimbal mount.
4/2/16
On Wednesday we successfully gained control over both a gimbal motor and a rotary encoder. Previously we had struggled to get the encoder to register the difference between clockwise and counter-clockwise rotation. I (Natalie) focused on finding out how to address this issue. At first, I thought it would possible to treat the rotary encoder as a potentiometer. However, while both have three pins, they serve different purposes. The potentiometer has one for ground, one for signal, and one for power. On the other hand, the rotary encoder has two for signal/code and one for ground. Based on this information, the circuit including just the rotary encoder was simple. Wires led from the encoder to pins 2 and 3 on the Arduino Uno and one wire led to ground on the Arduino.
The key to operating the encoder is the fact that there are four possible output states (00, 01, 10, 11). Depending on the order of these states, the encoder is either rotating clockwise or counterclockwise. We need to keep track of these states at all times so that we can discern rotation and whether the order/direction of rotation changes. This requires the use of interrupts. I was able to find a sample sketch on bildr.org and, by serial printing the encoder value, I was able to get the value to increase when the encoder was rotated clockwise and decrease when rotated counterclockwise. This code generates integer values that correspond to the position of the encoder. They can be negative or positive depending on whether the encoder is going clockwise or counterclockwise past zero and they have no max or min values unless they are explicitly set. The next step with the encoders is to try and get communication between an encoder and a motor.
Nathan focused on the motor. Previously, we had been unable to get the motor respond to the Arduino. Using code derived from a YouTube video (Arduino simple 3-phase brushless (tarot GoPro gimbal) without ESC/MotorDrive), Nathan was able to get our motor to spin. After some modification, he was able to change the direction of spin. Given that we do not have ESCs (Electronic Speed Controllers) to control the 3-phase brushless motors, the code provides three pulsing voltages to the three different phases of the motor respectively. The offset times of these three pulses had to be tuned so that each pulse propelled the motor into the next phase. Making small changes in the offset times corresponded to changes in the revolution speed of the motor. Finally, reversing the order of the pulses caused a reverse in the direction of the rotation of the motor.
The setup for the motor is as depicted:
On Friday, I (Natalie) was able to get some communication between our rotary encoder and Deko's DC motor fan. This required creating an long array of length two that would hold the previous value of the encoder and the present value of the encoder so that the two values could be compared outside of the interrupt. This was done in the loop so that the values in the array were shifted every time the loop ran. First, I created a boolean didChange and printed to see whether the program could register when the encoder value changed. Once this worked, I wrote code to incorporate the motor so that if didChange was true, the motor would turn on. Using this code I managed to establish communication between the motor and encoder. The next step was to get the motor to turn one way if the previous encoder value was larger than the present and the other way if the opposite was true. Unfortunately, we realized that Deko's motor could only turn in one direction so I would need to continue programming with our gimbal motors, whose code was complex and still in the works.
Nathan completed a second print of the main frame of the phone mount with some alterations meant to take into account the wiring. After examining the print, we decided that there were a number of changes that needed to be made to give the mount the functionality it needed.
- The attached tube meant to hold wires needed to be eliminated and replaced with half-rings to give easier access and visibility
- The lip holding in the Arduino needed to be lowered so that there would be easier accessibility to the housing
- The battery trough needed to be widened so that we could fit all four batteries without having them slide around
- The roofing on the Arduino housing needed to be removed so that we would have easier access when wiring and could see if any disconnects were to occur during movement of the gimbal. We also decided to add a removable cap to the housing instead of a permanent roof so that we could close off the chamber once the wiring was secure.
The design was fixed and prepared for printing, though we would have to do a miniature print to make sure all the changes would work out without wasting both time and material.
After assembling a motor to the second version of the main frame, Nathan had to adjust the motor code in order to account for the weight that the motor was now responsible for turning. This required increasing the minimum speed in between each pulse from 7 milliseconds to 13 milliseconds. He was then able to get the rotating bar to "tick" using the motor, however we noticed the ticks were uneven based on the weight distribution of the bar and how it was positioned in the rotation. He was also able to smooth out the rotation of the bar, however the code was becoming cumbersome and Deko encouraged him to try a different way of coding the three pulses using a cosine wave and phasors to clean up the code.
On Saturday...
