This is the original project description that was posted when the project was first started a couple weeks ago. I want to rework the description but figured to keep the original as a log entry.

---------------- log entry 09/27/2019------------------

This is an esp-idf project with an ESP32 acting as a flight controller and receiver for F450 quadcoptor drone and an esp8266 D1 mini as radio control transmitter.

I did a project recently with an mcp6050 gyroscope and accelerometer, impressed with the capabilities and ability to keep a reasonable integral of inexpensive mems sensors I decided to find something to control. Some ebay searches pretty quickly lead me to consider building a quad coptor. I soon found 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.

I've been hobbying around with esp devices for a few months now and have decided to use an esp8266 D1 mini as my transmitter base station and an esp32 as my receiver and flight controller. At first the flight controller aspects will be shared with the CC3D flight controller that I got with my kit package. I hope to integrate the CC3D  functionality into the esp32 as we go along, but there is a lot of learning to do here that I can reverse engineer with the CC3D and cleanflight.
      Transmitter requirements : 
          Two way comms to at least 200 feet
           be able to sustain packet rate of at least 10/sec (hopefully 50/sec)
           collect data from a couple joysticks, switches and a display
           return blackbox data from flight controller at packet rate to serial port

Using a webpage as input and a TCP connection between transmitter did not work out, I have familiarity with the IP and was able to test it out in a few hours. Packets started getting backed up at a 300msec launch rate, maybe this could be improved but probably not by a order of magnitude. A couple of browser joysticks on a cell phone might have been nice. The project is now heading in a transmitter to flight controller receiver interface using espnow framed wi-fi station/access point connectivity and i2c interface to ground station hardware (physical joysticks, switches and display). Tests showed a 3x range improvement over my router without the connection and  tethering hassles, and much much better packet rates. The espnow protocol is directly between the esp devices to their mac addresses with crc checks and limited handshaking.

The joysticks being, temporarily, used are pretty horrible. They have a huge dead spot at the center where the output resistance doesn't change for about 15 degrees each side of center and the rest of the range is used up well before coming  to limit of travel, so the whole usable range is about 15-40 degrees each side of center. The joysticks center position resistance varies considerably and needs to be calibrated and they return to center.

A data acquire task loop is run in the transmitter to read voltage values from an ads1015 every 20msec. The readings are used to update local values for throttle, yaw, pitch and roll. The yaw, pitch and roll are 10bit values coming from the adc, the center rest position value is subtracted, the result adjusted by a chosen gain and added or subtracted (depending on orientation of joystick) to 1500. The throttle does not return to center so its reading (after calibration offset) is accumulated  (and multiplied by chosen gain) and added to 1000.

Events are scheduled to run espnow_send every 20msec and a callback for espnow packets received. The espnow_send transmits a string congaing the throttle, yaw, pitch, yaw and other parameters. The callback string received from the flight controller contains telemetry (blackbox) data which is forwarded to the console serial port for collection by attached pc for analysis.
Flight Controller and receiver requirements :
     Acquire gyro/accel data and transmitter inputs to control motor speeds
     Return telemetry data to transmitter ground station        

The current goal of the project is use the CC3D flight controller with an esp32 receiver interface. The CC3D has a nice interface to simulators such as cleanflight that allow easy setup of ESPs, mems and motor calibration, pids and filtering and telemetry data collection as long as connected (these features will help get started a lot quicker and provide a great debug assistance). The esp32 receiver will need to talk to the CC3D flight controller to supply transmitter data and to obtain telemetry data and write pid, filter and status registers.

When the CC3D flight controller is attached to cleanflight and you snoop on the  port with an intermediary (interceppty worked for me - or using three usb dongles) you can see binary data being transferred which turns out to be MultiWii Serial Protocol (MSP), full documentation is hard to find but can be pieced together and checked against snoop data to come up with a good msp.h file. The actual motor control path parameters (throttle, yaw, pitch, roll, motor speeds) all seem to be blocked read only with the MSP interface, at least with my version of CC3D (the version didn't work with later  versions of software so I used cleanflight to download firmware backwards until the CC3D booted up). I have gotten one of the CC3D serial ports hooked up to my esp32 to read mcp parameters from the CC3D, and even to negotiate an esp32 hookup directly to cleanflight.

The motor control path variable can not be written with MSP with my version of CC3D and I do not want to use servo pulses to import my throttle, yaw, etc.. values to the flight controller. Decided to use the SBUS semi-digital protocol for this purpose, my version of CC3D also does not support the sbus_invert cli command so an inverter had to be built from an 2N2222 and two resitors. To help debug the development of the SBUS interface I wrote two C programs on my desktop to write SBUS protocol packets for 16+2 channels and another to monitor and decode SBUS packets. The esp32 program has demonstrated SBUS packet transmission to the CC3D flight controller as monitored by the cleanflight transmitter tab and flight simulator. 

So, at this point, I can have my CC3D flight controller on my desk hooked up to my desktop and walk 150 feet down the street with my ground station sending throttle, yaw, pitch and roll information. Still need to verify that the other CC3D port can also be used so that the esp32 can have SBUS and MSP running at the same time with the flight controller - just sending a dummy packet right now.

My F450 drone kit has literally just arrived from it's slow trip across the pacific, actually it took exactly two weeks - about half of the estimated delay (I still don't have any batteries so I just ordered some 3s's from amazon - things cost 60% of what the whole drone cost - find it amazing that a small battery like that can put out  80Amps!). Got a lot of work to do building this thing and not make it look like a kludge, but just got a new soldering iron and plan to look at some youtube F450 builds before smashing the thing in uncontrolled ascent to ceiling (considering  various mechanical tethering options). Having the cleanflight interface for initial setup will save a lot of time.