04/04/2018 at 15:20 •
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.
02/08/2018 at 06:30 •
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.
01/18/2018 at 06:00 •
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.
12/06/2017 at 05:24 •
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.
11/25/2017 at 19:35 •
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.
11/10/2017 at 05:21 •
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.
10/29/2017 at 21:37 •
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!
10/21/2017 at 00:56 •
Last week, the first test of the EVPR prototype working in concert with the flight controller was conducted. It was found while the previous servos had sufficient torque, but that the internal servo gears were not suitable for the vibration and shock environments. New servos with steel gears were Additionally the retaining rings needed to be upgraded to heavy-duty versions.
On Tuesday the new rings arrived and the axles were modified for them. Yesterday, the new servos arrived. The new brushless servos are really cool. The are super quick and have none of the singing that the brushed servos had. Late last night the new servos were installed and testing began last night and continued into today.
Unfortunately this afternoon, the blades on the prototype came loose. On startup the engine revved up quickly to a high RPM and the rivets holding the blades in placed sheared, sending the blades flying.
Unfortunately there's only 14 hrs left until the deadline for the Hackaday Prize and there isn't a working prototype to meet the contest requirements. The prototype IS close to working. Stay tuned!
10/14/2017 at 17:36 •
After completing the flight controller setup, it was time to test the rotor with the Pixhawk actively controlling the rotor surfaces. The rotor was activated, check-out and then the gas engine was turned on. Everything appeared to work well, but when the engine was turned off, it was found that one of the rotor blades had partially slipped out of place.
Fortunately, there was an extra groove in the axle shaft that caught the retaining ring when it slipped out, keeping the rotor blade from flying out. The grooves were found to be a little shallow, so they were machined slightly deeper. Additionally the retaining rings did seem to close as tight as they should, so new retaining rings were used. There was also some stripped internal servo gears, so the servo was replaced as well. At the time I was thinking that the blade slipping might have jammed the axle gear in place and that caused the gears to stripped.
A second test was conducted and the other rotor blade popped partially out and the brand new servo on the side that stayed in place had stripped internal gears. So it doesn't seem to be the rotor blade failures that are causing the stripped gears, but the normal environments.
The rotor blades popping out, should be relatively easy to the fix. There are heavy duty retaining rings that have a higher holding force and I've already ordered those. The servos required a bit more thinking. The gears for the current servos are listed as "Metal", but they are made from aluminum and brass. It's obvious that either steel or titanium gears would be a better choice. However, servos with steel gears have higher torque, which isn't a bad thing, but draw more power.
The solution is to use brushless servos. The servos I selected are the Hitec 9475SH. It's got steel gears, 50% more torque, is almost twice as fast and draws 900 mA at stall torque vs. 2700 mA that the current servos require, which should push the battery life almost up to 30 mins. The downside of course is money. The new servos cost $99 instead of $40.
I thought that this failure was going to mean that I wouldn't have a working prototype in time for the Hackaday Prize deadline. However, the retaining rings will get here on the 17th and the servos will get here on the 19th. I should have the new retaining rings installed by the time the servos show up, and it should only take 20 mins to install the new servos. That'll give me about 36 hrs to test and update my video showing the working prototype.
10/06/2017 at 01:26 •
Initial testing of the Pixhawk drivers and the EVPR Firmware was a success as shown in the video below. Next step is re-configuring the control mixer and setting the correct servo ranges for the rotor blades.