One of my favorite things about being a student at Olin College of Engineering is the freedom we're allowed in our projects. The design depth/creativity the curriculum and teaching team foster is unparalleled. Unfortunately, my projects are quite paralleled, but I still love going over what I learned and how I'd do it again, just in case someone else enjoys the process too.

FlyGloveFly

My team's vision for this project was to design a system that converts intuitive human behavior into a vehicular control scheme. We accomplished this by designing a glove incorporating flex sensors and an IMU to determine the user's hand position, contortion, and orientation which them radios these control signals to the vehicle of our choice.The minimum viable product (MVP) for FlyGloveFly was an RC car with a controllable throttle and steering using the glove controller. When the user bends their finger, the car drives forwards and when they straighten it, the car stops. This MVP creates many avenues for expanding the project once the basic system is in place. We chose to explore the avenue of flight, utilizing the glove to control a drone that we also built, thus incorporating more of a challenge relating to mechanical and software design. Although seemingly simple, designing a drone and frame proved to be quite difficult. We ran into many issues along the way, ranging from poorly designed frames to small electrical fires. I'll go over the subsystems of each component of our design to give a comprehensive view of how it all interacts.

Drone Design - Mechanical

[First drone image]

Above is the first frame prototype. At the time, we planned our electronics around a full-sized Arduino R3 which explains the choice for a larger frame. One of the main design flaws in this frame was poor screw access and some misoriented motor mount screw holes. Even though the CoM was well tuned, these oversights cost us time when debugging electrical problems on the drone.

[second frame]

The frame pictured above led us to our final frame design followed by some minor tweaks further down the line. The smaller frame design came from the plan to use an Arduino Nano instead of an Arduino R3. Mechanically, the smaller frame yielded some benefits, such as weighing less, having a reduced footprint, and more rigid skeletonization. In the end, we ended up using the full-sized R3 as pictured below due to some electrical additions which the Arduino Nano couldn’t support.

[battery stack]

We designed a strong but minimal battery cradle. It adds minimal weight while securing the battery and the Arduino. Since we originally designed our frame for the Arduino Nano, we resorted to velcro strapping the Arduino R3 on top the battery mount. Although it's visually cluttered and gives little access to the components, it holds the Arduino firmly.

Drone Electrical

The 16 volt LiPo battery is connected directly to the speed controller, providing a 16-volt source to power other peripherals. With a 12-volt regulator in place, we are able to step down that 16 volts to power the Arduino. Using the 5 volt pin from the Arduino, we are able to power the inertial measurement unit (IMU) and radio receiver. Each motor has a dedicated pin on the motor controller that allows for speed control by sending a pwm signal with a duty cycle of 1100 microseconds to 1900 microseconds. This signal is outputted from the Arduino’s digital pins; we use pins 3-6. The IMU communicates with the Arduino via I2C, so the respective clock and data pins are connected with the Arduino’s clock and data pins along with 5 volts and ground.

All of the wiring that connects to the Arduino is soldered to a protoboard that connects to all of the pins on the Arduino. The protoboard provided easy connections for all the wires, but, with each wire added, our drone became more messy and susceptible to electrical shorts. A PCB would make the electrical debugging process much easier, but creating one before testing our entire system was not in scope with our project.

The motors are RS2205 2300KVs, producing just under a kilogram of thrust each at maximum power: they provided plenty of power for our frame. They are controlled by a Diatone Mamba Four-in-One Electronic Speed Controller. This controller allows us to control the inputs to each motor through the Arduino. Unfortunately, while probing for voltage, we accidentally jumped a voltage output with a ground pin, creating a small electric fire and ruining one of our speed controllers.

Drone Software

For drone control, we implemented a PID controller to make the drone adjust to any position we desired. To accomplish this, the drone most establish a flat orientation to create the necessary offsets. When this offset is subtracted from the raw data from the IMU, and the drone flat, the readings for pitch and roll should both read zero. Our PID control only took into account the proportion and derivative. The proportion takes the difference in angle of the drone’s pitch and roll relative to the flat orientation and changes the speed of the necessary motors to orient the drone back into the flat orientation. This is called a closed loop control system and also takes into account the rate of change of the drone’s pitch and roll over time, which is the derivative part of the equation. With only P, the drone will correct its orientation but will always overshoot, causing an oscillitory motion; however, when D is added the drone acts very similarly to a critically-damped spring system, so that once the drone levels out, it won’t oscillate back and forth. Receiving data from the glove works in exactly the same way as the car, except the control signals are interpreted differently. The user can control the yaw, pitch, and roll of the drone by the yaw, pitch, and roll of their hand.

We quickly realized that it was completely out of scope to create a full flight computer, yet, by keeping the drone tethered, we managed to demonstrate some glove control and PID functionality like you can see in the video below.

Drone Improvements

Despite the many iterations on the drone there are still improvements that could be made given more time. The biggest improvement would be adding a solid mount for the Arduino on top of the drone. This would render the drone more symmetric and balanced, and allow for easier wire management. Second, adding a better propeller guard and landing gear would be critical for untethered testing. Currently, we are comfortable flying the drone with its current guard system, but only while tethered. Finally, making a custom printed circuit board, or at minimum, a re-wired protoboard, would improve the looks and safety of the drone by reducing the amount of wiring and therefore possibility of accidental shorting.

Although we got the drone to a ready state by the time our project deliverables were due, we also fully developed our MVP vehicle: the car.

Car Design - Mechanical

The mechanical design was used from a previous project which consisted of two bigger front wheels that are each controlled by a DC motor as well as one smaller unpowered back wheel for balance. The body of the car consists of a piece of acrylic with holes to screw in the wheels and motors. The Arduino R3 is attached to the top of the car body and taped on the bottom to prevent accidental shorting due to the metal bottom and metal screws in the car. The battery is attached to the bottom of the car via a velcro strap which also secures the Arduino R3. 

Car Electrical

The car wheels are driven by one DC motor per wheel. These motors plug into an Adafruit Motor Shield with one wire in Vdd and the other in ground. The Adafruit Motor Shield attaches to each pin of the Arduino R3 pin connectors.

The radio communicates with the Arduino via SPI, so the respective MOS and MISO pins are connected with the Arduino’s MOSI and MISO pins along with 3.3 volts and ground.

All of the wiring that connects to the Arduino is soldered to a protoboard that connects to all of the pins on the Arduino. The protoboard provided easy connections for all the wires but it became quite messy and susceptible to electrical shorts with each wire added. A PCB would make the electrical debugging process much easier, yet creating one during this MVP testing stage was deemed not worth the time.

Car Software

We want to be able to wirelessly control our vehicle from the glove, so we opt to use radio control between the two. Control signals are received from the transmitting radio on the glove by the receiver radio on the car, and then outputted to the serial bus to the Arduino R3 on the car. The Arduino R3 can then access the serial data and interpret it as a control signal, driving the motors appropriately. The most time consuming issue we encountered with this implementation was that the radios were not sending control data at a high enough frequency which resulted in latency and frequnt radio shutoffs. To overcome these difficulties, we ran extensive testing and eventually had to approach the problem from a very low level. After decompiling the radio libraries in arduino, and hand decoding the config options from the memory address given for its controller, we eventually found some solutions: By increasing the base clock speed we were able to smooth out the latency from the glove control, and disabling auto-ack payloads and some other more obscure options stopped the radio disconnects. We also implemented automatic failure detection and reconnection states in our radio controllers.

The software for this vehicle used the output signal from the flex sensors and converted that signal to an input signal for the motors. When the flex senses high the wheels move forward and when it is low the car comes to a stop. The glove also includes a gyroscope, which allows the user to steer the car left and right by turning their wrist in those repsective directions.

Car Improvements

If we were to improve the car functionality instead of moving onto the drone for our stretch goal we would have added a reverse mode for the wheels using another flex sensor that, when it reads high, the wheels spin backward. There were a lot of debugging features we could have added (LED’s, speakers) which would have made testing much more streamlined, even for the drone since our glove can work with any vehicle we want to control. However, for the car, it would feel more complete if we added some preprogrammed “dances” or maneuvers that could be activated by certain hand gestures like vigorously shaking your hand. Speaking of those hand gestures, I'll detail how the glove systems as well.

Glove Design - Mechanical

The glove was designed to look simple and not become unwieldy with batteries and peripheral devices. There are two flex sensors (one in each finger) that are glued to the middle layer of fabric so they are not seen on the outside of the glove or felt on the inside. There are holes in the fabric at the bottom of the fingers so that the wires can be attached to the sensors in the fingers and the arduino that is on the back of the user's hand. The Arduino R3 is attached to the glove using velcro, therefore in case the Arduino R3 breaks, we can easily swap a new one in. In order to be an untethered system, the glove also comes with an armband that is adjustable using velcro and holds the battery to power the Arduino R3.

Electrical

The glove uses two flex sensors and one 3 axis gyroscope to capture the hand movements of the wearer along with an Arduino R3 to capture and process the sensor’s outputs. The flex sensor changes its resistance when bent, so wiring it in series with a 100k resistor, a signal depending on the flex angle of the sensor can be captured between the two components. The gyroscope communicates with the Arduino via I2C, so the respective clock and data pins are connected along with 3.3V and ground. When testing, we found that it would be desirable to reset the gyroscope’s default position when the wearer moved their hand to a resting position. To solve this problem, we added a button with a simple pull down resistor which pulls up the voltage on one of the Arduino’s digital pins, resetting the orientation of the gyroscope to 0, 0, 0. The glove also includes a radio transmitter to send control signals to a radio receiver on either the car or drone. The radio communicates with the Arduino via SPI, so the respective mosi and miso pins are connected along with 3.3V and ground. The battery that powers the glove’s electrical system is a simple charging bank that connects to the Arduino via USB.

Software:

The beauty of not designing for one system (the drone or the car) is that it grants us great flexibility that results in very brief code on the Glove’s end. The glove has a few simple tasks, normalize the sensor values to a user’s resting hand position, collect sensor data, and transmit that sensor data to the vehicle.

Normalizing the sensors to the user’s resting hand position works by creating an offsets for each sensor value when the RST button is pressed. From then on out, each respective offset is subtracted from the raw sensor input, allowing the user to essentially redefine the default position of the hand to what they are most comfortable with.

Collecting the IMU data works by simply using the libraries provided for the IMU and interfacing with it through SPI. The flex sensor data is simply read as a voltage through an analog pin which works due to the voltage divider setup of the flex sensors.

These control signals from the flex sensor and IMU are transmitted via 2.4GHz radio to a transceiver on the vehicle. We ran a suite of tests over varying distances and with different objects in the way to determine the correct radio position, power levels, and configuration options. It is then the vehicles job to interpret these sensor values by the glove in an appropriate manner to allow the user to control it.

Improvements:

One of our main design goals for the glove was to prevent extra peripherals making the wearable unwieldy. Unfortunately, the battery holder became an afterthought during the glove’s design which ended with a functional, yet less than comfortable solution. Electrically, a PCB would have made testing easier and mitigated the possibility of electrical shorts, but since there weren’t too many wires, this would have been a low priority goal.