Progress Update

WARNING!

Graphic content ahead. Proceed at your own discretion.

February 9, 2020

Created project website, and updated it with sections taken directly from the proposal.

February 27, 2020

We soldered the quadcopter's motors to the corresponding connections on the ESC, and we were ready to see the motors spin.

Our thought process was that if we send a waveform with a large enough pulse width, it would turn the motors on, and the motors would simply spin at a speed proportional to the width of the pulse width. However, we quickly found that wasn't working.

We dug around online and found that there exists a software called BLHeliSuite which allows for calibrating the flight controller, as well as controlling and changing the motors' settings. We used it to test whether the motors and the ESC were working properly, because we were afraid we fried the connections on the ESC. Luckily, everything was still working. It was exhilarating to see the motors spin.

We used the BLHeliSuite to configure the correct spin direction of the 4 motors, as shown in the figure. This allows the quadcopter to fly straight.

The time being close to 10 p.m. we decided to attach the propellers and watch the quadcopter take flight with delusional excitement (as we were nowhere near our goal). It was an uplifting moment of hope.

Motor Spin Directions

February 29, 2020

Saturday. 12 p.m. We should be sleeping.

We found out that in order for the motors to spin, an arming sequence needs to be sent to all 4 motors. We connected the flight controller (HobbyWing Xrotor Micro F4 G3 ) to the ESC. The flight controller automatically sends an arming sequence to the motors, and they are ready to spin.

Our process was to connect the flight controller to the ESC, arm it, and then with the STM32 microcontroller also connected, load the program onto it, and run it. It was working properly, and we were able to use the on-board joystick to increase and decrease the rotation speed of all 4 motors. However, once the RESET button was pressed on the STM32, the arming sequence had to be resent. So we disconnected and re-connected the flight controller in order to do just that.

We had also soldered wires into the appropriate contacts on the ESC that control the 4 motors. These 4 wires would connect to 4 different pins on the STM32, each of which would transmit a waveform to determine the speed at which the motor would spin. One contact on the ESC was proving particularly difficult, accumulating a lot of burnt solder. Unfortunately, the soldering contacts are very weak, and one of them ripped off, disabling our ability to use one of the motors, so a new ESC needed to be purchased.

Additionally, at some point the flight controller stopped working and was very clearly fried. We had no idea why.

To be continued...

March 4, 2020

We have fried ANOTHER flight controller. And we figured out that this time it was by sending a signal that was way too big in amplitude. Double the amount the flight controller can tolerate, to be precise. Later that night, a third flight controller would lose its life due to accidental short circuiting. We posit that the first flight controller went down in the same manner.

We decided that we have to figure out the arming sequence because we cannot rely on the flight controller, and it would be a cleaner way to implement the entire project. After multiple tries of following the instructions in the manual that arrived with the ESC, we were having no luck.

Eventually, we figured out how to send the arming sequence using the STM32 by accident. Daniel was randomly pressing buttons on the STM32, when all of a sudden one of the motors came alive. A few more trials to figure out the arming sequence, and we officially knew how to turn the board on using the correct PWM signals.

One of the pins that allows access to connect to the ESC has been bent, and would make it impossible to run the motors any longer. Chris took the drone home, and gently straightened the pin back out. The connector that fits onto these pins is now permanently there so as to not accidentally damage any pins, because we cannot afford to buy another ESC.

We are now using solder boards in order to make sure that if we burn off any connections it will be on an easily replaceable part. Additionally, we are now electrical-taping EVERYTHING to ensure there is no more short circuiting because we have had enough.

Electrical Taping
The Carnage

March 5, 2020

Late at night, Chris was working with the drone and decided to attach the propellers and test it out. The motors turned out to be a lot more powerful– and the propellers sharper– than we had previously thought.

The propellers had cut through the XT60 pigtails, so another pair was needed. Photo provided.

On top of that, Chris was badly wounded. The propellers went for the kill.

The Bloodshed

March 12—14, 2020

For 3 days Daniel has worked on trying to establish communication between the two nRF24L01 transceivers using SPI. Attempts have been unsuccessful. However, a big chunk of time was also spent on trying to properly display information on the LCD screen of the STM32 microcontroller.

Chris successfully communicated with a voltage sensor using I2C in order to read out the battery voltage of the quadcopter.

March 17-18, 2020

Chris has joined the SPI-transceiver efforts. Combing through the datasheet of the transceiver has offered little helpful information. At the end of both days, no progress has been made.

However, later on March 18, Chris has figured out what may have been responsible for the transceivers not functioning properly. It turns out that in order to enable automatic acknowledgements with the Enhanced Shockburst mode that is offered by the nRF25L01, the corresponding bit has to be set to 0, instead of 1. Which of course makes no sense, but it was finally working and transmitting.

We were now officially able to use the transceivers to communicate between the two STM32 Discovery boards, and could successfully send throttle commands.

March 19, 2020

The transceivers now successfully communicate between the two STM32 Discovery boards. The voltage sensor code, transceiver code, and motor signal code have been successfully integrated, and the quadcopter is ready to be fully assembled and tested.

Tragically, during assembly, the battery cable that provides a measurement source for the voltage sensor came loose and shorted with the SPI pins on the transceiver. This short damaged the "receiving" STM32 Discovery board, and the wireless RF transceiver module connected to it.

We salvaged what we could with the short timeframe we had (tomorrow's submission deadline), and the project has been relegated to showing the following:

  • Successful SPI communication has been established by reading the status register of the one working nRF24L01 transceiver
  • Successful I2C communication has been established by reading voltage measurements from the INA260 voltage sensor
  • Correct PWM signals were generated and sent to the motors to control their rotation speeds

Project requirements have been fulfilled, but this sure is an anticlimactic ending. We did not find the end result worthy of a demonstration with the propellers, as demonstrated in the demo video.