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.
10/02/2017 at 05:03 •
The initial code for both the EVPR master and slave nodes is FINALLY ready. Additionally the PX4 driver which passes the servo settings to the EVPR master node is also complete. The servo values are correctly being passed from the flight controller tothe master node via UART and the values are being successfully passed from the master node to a slave node via UDP packets.
The code can be found in the repository at the following locations:
EVPR Master Node
EVPR Slave Node
Now the electronics will be attached to the vehicle and more testing of the code can be conducted. If the servo values with the engine off are successfully received, then the testing can proceed to turning the engine and checking out the code on the running vehicle.
09/21/2017 at 03:47 •
Solid progress is being made on the firmware, particularly for the master node that connects to the flight controller. As the firmware is being developed, it's tested periodically on an ESP32 connected to the Pixhawk 2.1 (shown below).
ESP32 is connected via on of the UARTS to the TELEM2 port on the Pixhawk. The Pixhawk sends out messages via the mavlink format on the TELEM2 port. The data is then parsed using the mavlink c libraries. The firmware is finally correctly parsing the mavlink messages, so the next step is the pass the relevant messages onto the other rotors.
The ESP32 is also running a webserver via Mongoose to provide a status page. Example shown below:
EVPR MASTER NODE STATUS Time since start: 28.942919 secs Connected stations: 1 Station 0 MAC: AC:7B:A1:DE:DB:4F Connected to Flight Controller System ID: 1
Most of the major pieces for the firmware are in place, it's just a matter of tying together all the pieces now. Once it's done, then the next step will be to test a single EVPR on the vehicle and test the ability to change pitch.
09/04/2017 at 18:57 •
Over the last few weeks, the hardware for three more rotors has begun to take shape. Below are some of the parts coming together.
Clockwise from upper left are three clockwise blades (one completed, two almost complete), the cores for all of the counter-clockwise blades, rotor plates for three more rotors, including one with servo mounted, and the latest power module.
The goal is to have a second clockwise rotor ready for testing by the end of the week. The other rotors will be completed in the next few weeks.
The power module has been revised and a diagram was made to show the wiring.
Progress is moving forward on the firmware as well. The data transfer from the master node to the slave nodes (rotors) is working using UDP. Work is now focused on transferring the data from the flight controller to the master node. The initial concept was to use I2C, but it appears that the code for the ESP32 to act as a slave I2C device hasn't been implemented. CAN was my next choice, but the ESP-IDF doesn't have a driver. There is another Hackaday project #ESP32 CAN Driver that looks promising, but between that and having to write a custom driver for the PX4 Firmware, it's proably too much work for the time left. The Pixhawk2 has a wierd note about SPI not being recommended, so that was out.
So that leaves using UART for now. This should be relatively straight forward since 1) There's already a PX4 driver for sending PWM signals through the UART port and 2) The UART is fully implemented in the ESP-IDF and there are examples available. In the long term I hope to have multiple protocols to give the user multiple options.
So if all goes well, the firmware should come together in the next two weeks and then the control scheme with the Pixhawk in the loop can start being tested!