Creating my own quadcopter control with ESP32 TX/RX
I’ve managed to fix my printer again. My lack of journal entries were caused by a failed 3D printer. The Z limit switch was failing, so I switched to an official BL Touch. After some configuration confusion (z probe - means closer to the bed, + means further from the bed, go + if you’re scared and - if you’re far), some filament woes (so wet that it wouldn’t stick unless 0.08~ from the bed), and some other woes I checked in on this project again.
I’ve purchased some replacement thumbsticks for a console controller as they are cheap and would seem to give 3D input. I’ll wire these up to my ESP32 since it’ll only cost 4 analog pins for yaw/pitch/roll/etc.
I started another Arduino project and started writing code to send connectionless commands bettween the nodes. I started with ESPNOW because it required nearly no configuration - only a few lines of code to enable the system. You’re forced to accept that the channel will be 1 but you do get reasonable security.
My initial bench testing was very promising. I set up a receiver to do nothing other than receive ESP NOW Packets. I got around 480-580 packets per second when sending 16 analog channels and 2 digital channels. At the high end, that’s 1.7ms between packets. At the low end, that’s 2ms. I walked to the other end of the house and got 270-370. That’s 2.7-3.7, with occasional drops down to 6.6ms. That’s a fairly high refresh rate for a fully confirmed protocol.
There are jitters caused by waiting for a response to a packet that wasn’t sent, but this means you can avoid buffering, and simply wait for a packet to time out before sending another.
With 1-6ms latency, that would seem quite sufficient to control a drone, given a human’s reaction time is more in the order of 15-30ms. The packet send timeout seems to be 33.3ms, which is reasonable for this application. You can get a rate of around 30 fails a second.
Next, the receiver. What was it going to do with this data at the other end? Well, it seems that the spare hardware UART will come in handy. We’ll need to connect to the Flight Controller using SBUS. This digital protocol is pretty straightforward, and the baudrate is 100,000 with 8E2 serial. This means that our maximum transmission rate is around 3ms. So at the lowest range of 1.7ms per update leading all the way up to 6ms per update, we’re only looking at a maximum of one lost frame, as the flight controller cannot possibly receive data faster or slower than 3ms.
I think this is acceptable when I may be cautious flying it at any range. I also think that if the real world performance is too poor, I’ll switch to an ACK-less protocol, like UDP.
Really, at this point, I could have investigated adding a gyroscope and working on my own flight control software, but learning all the ins and outs of ESC, scheduling tasks on time and executing physical calculations didn’t seem appealing. TX/RX is relatively simple, and by focusing on only doing telemetry and control, I can avoid the performance complexities of such a craft.
I would have avoided making my own flight controller too, if the controllers themselves weren’t 80 bucks a pop. When I have a little LCD screen and a few wireless devices, it only seems logical to do the cheap bit myself.
My next steps:
- Acquire my 2D potentiometers and wire them up to some channels
- Determine what other parts are commonly on a controller
- Add two digital channel switches for various signals that betaflight may offer
- Determine how many full channels you’ll actually need and reconfigure the wire payload appropriately
- Design a controller housing to hold the ESP32-TTGO and the 2x 2D potentiometers.
- Design a nice antenna for both ends
- Assemble, test, assemble, test, run!
A few of these depend on parts arriving, but the initial R&D still has a few spots left.