I recently started a project with a kit containing f450 frame, brushless motors, electronic speed controllers and props for a little over $50. They even threw in a CC3D flight controller module, which while not part of the original plan helped firm up a development strategy. My plan is to develop stable platform that will hover (and return) to one spot before trying to focus on 'flight' concerns. The logs contain a story of several implementation attempts that did not pan out. This description is of the current status and direction.

Components :

F450 frame, motors and ESCs
ESP8266 with resistive joysticks and analog to digital converter
ESP32 with MPU9250

Transmitter :
The transmitter gathers voltage reading from the joysticks every 10 msec, they are encoded into a string as throttle, yaw, pitch and roll state. This string is transmitted as an ESPNOW packet. For ease of use, the espnow link between transmitter and receiver are hard-coded with each-other's  MAC address, discovery and turn on sequence are not an issue. The espnow between the two devices works reliably up to maybe 200 feet with the two devices tested - planning to probably replace these with a couple nrf24l01 (pa+lna) recently ordered. The joysticks that I currently have are barely usable  - plan to replace these with a couple jh-d202x recently ordered. A display was originally included bit interrupted some of the espnow packets being sent at 10 msec intervals (access later). Blackbox logging will be looked into later.

Receiver :
Hardware development is  proceeding  using a CC3D flight controller contained in the f450 kit, my daughter has taken lead on mechanical/soldering and test flights (pic included). Currently, the ESP32 on the quadcopter is receiving espnow packets from the transmitter and converting these to SBUS format to communicate with the CC3D flight controller. We used cleanflight to setup the CC3D and then to program the ESC's and make sure the motors were turning the correct direction, allowing us to proceed with mechanical build and soldering. We have armed the quadcopter and had several test flights out in the yard and everything is working pretty well.

note : Getting ESP32 to SBUS communications up to the CC3D was not trivial - couldn't really find any starting point except SBUS specs and CC3D/cleanflight does not really support diagnostics. A linux program was written that writes and also monitors SBUS traffic that helped a lot in the development of this code.

ESP32 Flight Controller and Receiver :

The real goal of this project is to write the flight control software from scratch and host it one the ESP32 with a view toward maybe adding a barometer, gps, magnetometer, tof altitude monitor or camera to the platform to keep me busy this winter (and keeping to $100 budget). Progress on the IMU software has been good so far and I'm hoping the high resolution led timers will handle the ESC servo commands at a 10 msec update rate.

Status of IMU software :
- MPU9250 (not using magnetometer)
- ESP32 module SPI interface 
- reading 8K gyroscope samples per second
- reading 1K accelerometer samples per second
- simple one-pole low pass on accelerometer x, y and z axes
- simple one-pole high pass filter on gyroscope z axis (yaw)
- trig functions to convert accelerometer data into pitch
  and roll data in degrees
- Complementary filter fusion of gyroscope and accelerometer
  x and y axes (pitch and roll) (output is angle in degrees)
- start-up calibration
- Inner control loop error estimaters and PID controllers
  (pitch, roll and yaw)
Currently the program is working to the point where it outputs to the console the speed commands to each of the four motors as a result of changing the attitude of the board or commands from the transmitter joysticks.

Plans :
- more test flights with CC3D
- finding out what can be found out about PID gains prior to first flight, a basic simulation?
- replace those damn joysticks and build a nice transmitter enclosure
- hook up ESP32 to ESC's
- upgrade transmitter with ESP32 - use built-in ADCs and support telemetry display
- add nrf24l01 to receiver and transmitter

- explore whether 32K samples per second on gyro would improve stability

Hooked up a test bed (pic) where a stuck a metal rod through the center of gravity along the motor 2-4 axis and suspended it in a box.  So far the 1 and 3 motors have been spun up with the motors tab command on cleanflight. While sitting on one of the up/down arrow keys to control one of the motors speed it is hard to keep the drone relatively level, even holding on to the metal rod and doing flight control ops yourself just isn't very stable - I guess my reaction time just isn't fast enough. Once the motors are spun up around half way it feels like it takes some real force on the metal rod axis to tilt the platform - lot of angular momentum.

This platform will help debug and tune the PID controllers nicely.

10-19-19 -- Been doing some testing with only one motor active in my testing rig, found out my esp required a 5 volt input servo signal so I put a level converter between my esp32 and the drone escs - also moved battery to bottom of drone. Added some weight on one of the arms (picture included in gallery) so that the motor had to be spun up to about a 1250 servo command to levitate the drone arm. The arm stays level and moves up and down slightly keeping the drone level to +/- 1 degree. The servo command to the drone varied between 1256 and 1258. Played around with PID gains with a program that I wrote to interactively change setting while drone is running - looking forward to getting the opposing motor hooked up and spinning next. Looks like adjusting gains to minimize PID loop integral is a good way to start in tuning process. 

10-21-19 -- Got rid of CC3D flight controller and controlling all four motors with esp32 board now (I can reset the escs and spin up all four motors now)! Did a quick test on my testbed with two motors active and the esp32 leveling the drone. A graph is included of the attitude that the esp32 calculates from the mpu9250 gyroscope and accelerometer data being processed with a complimentary filter  - the output is in degrees. The PID output is the sum of the P, I and D terms on the graph and added to one of the motors base throttle speed and subtracted from the other. The graph shows and oscillation of about one hertz in the +/- tilt of the axis with the two active motors of about 1 degree. I believe that it may have been a mistake to build the testbed in a box with closed sides. I'm going to try a new testbed not in a box so the propwash of the propellers can flow away from the test setup - it is possible that part of the 1hz oscillation is in part due to avoidable aerodynamic affects - the flow in the box seems very turbulent and unsteady.

10-22-19 -- The box was a bad idea, thought it would be a little bit safer but concentrating the propwash into a resonate cavity was not good - now there are two uprights supporting axis rod and propwash blows over table. The new graph shows the tilt being much better controlled. Got more tuning to do looks like maybe the Igain is a little high.