EVPR: Electric Variable Pitch Rotor

It's finally time to close up this particularly project and it's now been marked as completed. If you've been following, you might have seen the news about creating a newer, updated Mk. II version. With all of the major updates, it made sense start a new Hackaday project #Electric Variable Pitch Rotor Mk. II  and save the old Mk. I info here for future reference.

Thank you to everyone who followed and supported this project. I'm particularly grateful for the prizes the project got during the 2017 Hackaday Prize (Wait, that was almost three years ago?!?). Please follow along at the new project if you're interested.

The full set of four variable pitch rotors is finally ready. Above is the video showing the control system working. The wireless data protocol appears to be working with no issues. There's still some remaining work to be done on the PX4 Firmware, but the rotors are ready to go for powered testing!

Be sure to come out and see the vehicle at OMSI's Robot Weekend!

In the Pacific Northwest and want to see the EVPR protoypes or #Goliath - A Gas Powered Quadcopter  in person? Come out to OMSI's Robot Weekend on June 16th and 17th. This will be the first time Goliath is displayed with all of the controls integrated into the vehicle. The last of the variable pitch rotors has been assembled and is ready to go on the vehicle.

In order to demonstrate to event-goers how the EVPR works, a see-through prototype is being built. A potentionmeter will be added to allow attendees to manually adjust the pitch.

The first two rotors have been fully assembled, painted and now are mounted onto the vehicle. Below is a HD video in 4K showing the movement of the rotor blades during a pre-test checkout.

Since the second prototype is brand new, the goal of the initial tests is simple to check that the new prototype will hold up to the environments. After conducting a short test, a longer 2 minute test was conducted at a moderate RPM and with the blades in a neutral position.

Nothing fell apart, so it was considered a success. One lesson learned from the test is that leaving the rotor blades in a neutral position minimizes the tension on the belts, increasing vibrations and making the throttle much more sensitive. Something to consider for future testing. 

Most of the recent work has focused on the Fiirmware,  particularly the protocol for communicating the servo positions between the master and the slaves. TCP was used for the prior iteration of the firmware, but led to less than satisfactory performance. Spurred on by @Jarrett's suggestion, I wrote a version of the firmware using the ESPNOW protocol. While it using wireless data, it doesn't require a WiFi network, but instead uses  IEEE 802.11 Action Vendor frames (as I don't follow this either, assume *magic*). The idea is that the ESPNOW protocol requires less overhead than sending UDP or TCP packets over a WiFI network that has to be established.

So now the master node reads the servo positions from the flight contoller via UART and broadcasts the servo positions for all of the slave nodes over a single packet. Each slave node receives the packet and only uses the data for the servo it requires. This simplifies the work done on the master node, since using sockets over WiFi required a separate connection for each rotor.

Testing thus far shows that the connections appear reliable. out of 9000 packets sent at a rate of 50 Hz, the slave node missed only three packets (0.03%). The servo movements are visibly improved from before, with none of the jerkiness. I've gone ahead and merged the updated firmware into the master branch.

As always, there's more work to do. The slaves are setup to send out a heartbeat packet every second, and the master node is setup to receive them, but nothing is currently been done with the information. Eventually the idea is to have the master get a status confirmation of the rotors and sharing that information with the flight controller to prevent arming the vehicle with less than the required number of working rotors.  There are a few other error checking tidbits to add to make the system as safe and reliable as possible.

There are now two operating EVPR prototypes. This week I finished assembling the parts for the second rotor. Both are using the new Adafruit Huzzah32 boards. 

While both rotors respond to the controller inputs, there is an unacceptable delay in the responses and a jerkiness to the servo movements. The firmware uses TCP to send the servo positions from the master to the slave. I had chosen this method so that the connection status could be monitored. However, using TCP appears to be having side effects that I don't understand. More work is needed on the firmware.

In the last few weeks, I found that the Sparkfun ESP32 Thing was not working well with the ESP-IDF due to the 26MHz crystal. In particular there was issues sending data packets between two of the boards. Therefore I ordered a batch of Adafruiet Huzzah32 that have 40 MHz crystals and they arrived a few days ago.

The Adafruit board is slightly smaller than the previous Sparkfun board (0.9"x2.0" versus 1.0"x2.25"). Functionally there are almost identical. The Sparkfun board has an extra push button, but the Adafruit board is shielded. The battery connector on the Adafruit board is definatly more solid and has additional attachment points for strength.

The first thing I did was to load the performance examples and runs some tests. Both the UDP and TCP tests worked as expected with the UDP throughput in the Mbits vs. the few Kbits I was getting with the Sparkfun board.

Next I flashed the latest EVPR firmware onto the boards and swapped out the electronics in the EVPR prototype. There were no connection issues and the TCP data packets were sent correctly.

The next step is to design and print new board holders since the Adafruit board is too small for the current ones. The pin layouts are different as well, so I'm going to need to find a different method of attachment. 

Over the past month, a lot of work has gone into testing out various communication methods between the master and slave nodes. Basic UDP, mulicast UDP and TCP have all been tried out, with each having various issues. Digging deeper I went back to some of the ESP-IDF examples that test performance and found that even for the basic examples, something is not right with the Sparkfun ESP32 Thing dev boards I'm using.

Apparantly, the ESP32 Thing has a non-standard crystal frequency of 26 MHz, whereas the vast majority of the other ESP32 products have a 40MHz crystal frequency. The ESP-IDF seems to be tested against products with 40 MHz crystals and there appear to be a lot of bugs when the examples are run on the ESP32 Thing. Like getting very slow UDP speeds (0.4 Mbit vs 130 Mbit) and for TCP, the connection disconnects after a few seconds.

I'm going to contact Sparkfun about getting some tech support about this, but I don't really have any expectations that it'll get resolved. In the meantime. I'm going to order a pair of Adafruit Huzzah32 boards and try those out.

With the basic EVPR hardware working, the firmware needs some work to support multiple rotors and add some redundancy. Right now only the single rotor is supported and if the rotor resets for whatever reason, both the master and slave need to be rebooted to re-establish the connection.

Doing some research on what's available on the ESP32, it seemed like UDP Multicast might be the solution. A single data packet would be sent out to all of the rotors. Using the ESP-IDF example, it was straight forward to create a branch of the firmware to support multicast.

The end result was less than satisfactory. Multiple devices were able to receive data and if a device got disconnected, it was able to pickup the data packets successfully. However, the latency was unacceptable. There was sometimes delays of one to two seconds using multicast. It'd probably be fine for other applications, but for trying to control a quadcopter, the delays are really unacceptable.

Thank goodness for version control and branches. Now it's back to the unicast method to add the required support there.

The prototype is finally working! The video above shows the prototype in action. Changes in the blade pitch correspond to changes in the thrust direction. The rivets were replace with AN470 1/8" diameter rivets (AN470-4). These rivets have 350 lbs of shear strength for a total of 2100 lbs of strength. The new blades have been tested 4 times now without the blades coming loose.

One of change was made to the batteries. It turns out the old batteries didn't have sufficient current capacity and the micro-controller would brown out while the gas engine was started. The new batteries are a similar form factor and have a 20C rating (20x the battery capacity). The capacity is slight smaller now (650 mAh vs. 900 mAh), but no more brownout issues!

More testing needs to be done on the physical hardware to ensure the design is adequate for flight testing. Additionally more work needs to be done to develop the firmware to add reliability. Once that's done the the other rotors can be completed and flight testing can begin!