End of Quarter 1

It feels like time has passed by fast as we’ve reached the end of the first quarter and prepare to head into the next! The team has been working diligently on the E-Hawk since returning to in-person learning. Here are some updates of what we’ve accomplished so far and what each member is working on!

EHawkTeamPic.jpg

Dylan - Pressure and Airspeed Sensor

Since returning to in person learning, I’ve started experimenting with differential pressure sensors via I2C communication.

Initially, I experimented with a MS5611 differential sensor using an Arduino Nano as our microprocessor. I was able to receive binary readings from the sensor and interpret them into pressure readings. However, when I tested the sensor’s ability to pick up changes in pressure using a air compressor, the values did not change. After debugging using println’s, we determined that the sensor itself was not picking up the change in air pressure.

We proceeded to order a DLVR L05D Differential Sensor and replaced the MS5611 with it. After adjusting the bit shifting, I was able to get proper binary readings from the sensor. Using equations provided by the sensor’s data sheet, I converted these binary readings into proper pressure readings that displayed to the Serial monitor. The sensor was also able to detect changes in the pressure readings. The code I created includes functions that translate the pressure from inches of water into pascals. Using these converted readings, I calculated “airspeed” readings in meters per second. I added a function that would then translate this into the more standard miles per hour and printed both values to the Serial monitor.

I am now working on displaying these values I’ve calculated to a TFT monitor. I replaced the Nano board with a ESP 8266 and am using the TFT_ESPI external library to communicate with the TFT. My current work is shown in the video below! The current issue I am facing is getting the TFT to display the changes in data smoothly without jumping. I am trying methods such as taking an average of the readings from the sensor over a period of time. I hope to solve this problem soon and test this sensor on a real vehicle!


Mariko - Oratex Covering and Instrument Panel

With the school’s campus reopening and return to in-person learning, we were finally able to resume physical work on the plane. One of the biggest tasks that we had to tackle was the covering of the ailerons, horizontal and vertical stabilizers, horizontal elevators, and the rudder with Oratex fabric. 

Before getting started on any of the actual plane structures, I experimented with the Oratex application process on a test piece. This helped me to get familiar with the process and gave me the opportunity to ask questions to Lars Gleitsmann, owner of BetterAircraftFabric. 

After I was able to work out any mistakes in the process through the test piece, I got started on applying Oratex to one of the horizontal elevators. After preparing and priming the aluminum, I applied heat-activated Oratex glue to the fabric and the structure and used a heat gun to adhere the fabric to the surface. Next quarter, I will continue the Oratex application on the remaining structures. 

In addition to the Oratex covering, I worked on designing the instrument panel. Currently the instrument panel will include the 5” TFT display, two 2.8” TFT displays, four switches, two circuit breakers, and a rotary encoder. In the second quarter, I will likely prototype this instrument panel design out of laser cut wood, and test/mount it on the plane.


Jonah - Motor and Electrical Monitoring and Display

Since the previous blog post on motor and battery instrumentation, we have made enough progress to be able to read, store, and display live data on the 5” TFT display. The first step to doing so was learning CAN protocol and the format in which our motor controller CAN transceiver would be sending its data. The motor controller is programmed to send out four packets of data with seven or eight bytes per packet. Raw data like main battery voltage, current, motor controller, battery, and motor temperatures, and expected/actual RPM percentage can be parsed from the bytes in each of these packets. 

After successfully reading raw data, we calculated power from P=IV to display on the power dial and divided the main battery voltage by the number of cells in our test pack to find cell voltage. From there, we added a voltage divider, with sufficient total resistance, to measure auxiliary voltage through one of the Teensy 4.0’s analog pins. The voltage divider initially spanned a ~12V-rated lipo battery, but after having connected a switch-based voltage step-down from the main battery, the divider could span the two ends of the 12V step-down output. The step-down also includes a separate 12-5V chip to power the Teensy 4.0 externally via its Vin and GND pins. Although the current reading from the motor controller was messy, we were able to calculate energy consumed in both kWh and Ah by integrating kW and A over time in our program loop. Knowing that the main test battery consists of 4 packs rated at 6.6Ah each, we then were able to calculate the main battery capacity percentage by subtracting charge consumed. 

After receiving and calculating all necessary data from the motor controller’s sensors, we focused on writing necessary data to the Teensy 4.0’s onboard EEPROM so that battery %, kWh, and Ah consumed would be saved even if power to the display was lost (all other information is recoverable after shutdown). The existing capacitance on the motor controller provided ample time to complete an EEPROM write. 

Some minor adjustments were made to formatting, such as reducing main and auxiliary battery readings from bars into values (which may change color in the future depending on their magnitude). By the next post, we hope to have polished up the display readout, which may include an E-Hawk bitmap logo or a red cross through data when CAN data is not being read. Moreover, we hope to have made some progress with storing data to an external microSD card so that it can be graphically interpreted on an external device.

Previous
Previous

End of Quarter 2

Next
Next

Motor/Battery Instrumentation Display