The last month has been spent largely on the downlink software development and tuning the Sky Eye. It actually wasn’t as much work as I thought it would be and in the end only took about 5-6 hours. It’s also still far from perfect, but it does like quite pretty. Here is a set of loiter loops recorded this morning under 10-15MPH winds:
The biggest remaining variance left is altitude. When the plane banks sharply on the downwind turn, it loses altitude. This results in a pretty sinewave of altitude errors. I’m tuning this now but I doubt I will be able to get rid of all of it without reducing the possible bank angles. At the weight it is flying at and it’s relatively low speed, the Sky Eye drops precipitously in a 45 degree bank.
The big problem is a lack of thrust I think. It will not accept a bigger prop due to it’s design and just doesn’t turn the small thing enough to generate a ton of thrust. I am actually currently looking at a Sky Hunter for future projects, but for the time being I will finish this project. I am very near the point where I can start running the 30 mile course. I am planning on running a 30 mile set of autonomous circuits this weekend. If that goes well, I will plan on doing a followed 30 mile route next week.
I have to say, that was much much easier than I thought it would be. A few points about APM 2.5 that I could not find ANYWHERE online but made this whole project drastically easier:
APM 2.5 uses a FTDI chip for USB/Serial connections. This is fully supported natively with Android.
When Android is plugged into the FTDI port, APM will still fly the plane just fine.
APM has long had the capability to “Continue” it’s mission when it loses radio contact. This means it is not going to be necessary for me to modify the APM code to allow functionality without a radio.
Anyhow, I will discuss my Android-based telemetry in the near future; but here is the innovation:
I am now able to communicate directly with my plane while it is flying from a standard Mission Planner ground station using a HSPA cellular link controlled by an Android smartphone onboard the plane. No 3DR or Zigbee telemetry, no range concerns, it just works.
At fully loaded weight, the Sky Eye has a low margin between cruising speed and stall speed. After some time playing with the autopilot onboard in stabilization mode, I’ve seen the autopilot drive the airframe into a stall twice now, and both times it was not pretty.
It does not help that at this weight, the Sky Eye has developed a vicious spin. I have not yet been able to get it to recover in under 1.5 revolutions after a power on stall, and the altitude loss during those spins is dramatic.
So knowing this, I opted to get an airspeed sensor to augment ArduPilots total energy control system (TECS) loop such that a stall is much less likely. I originally opted to install it in the nose, but realized shortly after that I am fond of laying the aircraft on the ground mounted on its nose and one wing tip. The small airspeed center does NOT like carrying the airplanes mass. I have thus opted for a wing installation. Here it is:
I have to say, I am immensely impressed with the accuracy of this unit given that the whole setup was only $30. If you are thinking about an airspeed sensor for you plane – DO IT. It is absolutely worth the money. It looks pretty darned cool, to boot.
Also pictured here is my new GPS location. I was having reception trouble when it was mounted underneath the wooden board so I was forced to move it up on the top of the fuselage. Here the GPS works great but the magnetometer has intermittent problems due to close proximity to the canopy magnets. It works much better nonetheless though.
So now that I have the power system ready to go, I opted to go out and do a 45 minute test flight this weekend. When I landed and saw
that I had made it to about 24 miles, I opted to throw the airplane back in the air and finish the last 6 miles. The result, as you can see, is that the model traveled it’s full goal distance of 30 miles and change. This was in heavy winds, gusting up to 25 knots, so I expect to see the total time down to 50 minutes under more reasonable conditions.
Battery consumption was about 7200mAh, leaving a healthy margin for further flight if it is needed. Near the end of the flight, the cells were lagging a bit on their output, but they managed to keep the plane in the air well enough.
During the test, the unsecured wing that was low in my pattern slowly slid out of its containment within the wing root. Since there are no screws or clips retaining these wings, they can just slide out freely if the friction retaining them is not enough. When the wing slid out (it was stopped from further motion by friction from the spar) it caused a significant roll I needed to trim against. This is a problem I will be fixing before doing any further testing.
I also tried out the autopilot I have onboard but the heavy wind on an un-tuned plane combined with a non-functional GPS (don’t know why) meant it didn’t really do anything for me.
My original intent with this project was to just use 3 3000mAh 3S LiPo batteries from HobbyKing. After coming across a post regarding a special set of high energy density Lithium Ion cells on diydrones though, I thought “why not” and opted to buy these cells – Panasonic NCR18650B’s to be exact. They cost me $10 apeice on eBay, spec at 3250mAh of capacity and weigh only 47.5g per cell. This is almost half of the weight of equivalent LiPo cells that I was looking at.
While my tests thus far have verified that the SkyEye will be capable of carrying the 9000mAh load of LiPos required for the 30 mile flight, nearly halving the weight is an interesting proposition that opens up extending the flight range even further.
The cells I purchased on eBay don’t have the charge protection nor did they have battery tabs. Luckily there is a retail chain called “Batteries Plus” that will weld battery tabs onto raw cells for you. Cost me an additional $2 per cell, so the 3 packs will end up costing me a little more than $100, a bit more expensive then their LiPo equivalents. Here is a picture of 6 of the cells with the tabs welded on, ready for assembly:
This was my first time assembling a battery pack with a lithium-type cell. No big surprises but I was a tad nervous. Here is a picture of the three packs once they were assembled – they are also attached to the wiring harness and placed on the plane where they will ultimately end up.
All of the packs and the wiring harness weighs in at 555g, much less than the 720g I was anticipating.
After building the packs, I did some tests on their discharge behavior and real capacity. Pictured to the side is my test set-up. Not very professional but it got the job done. I discharged a total of 7600mAh from the 3 packs in my last test with no problem. One problem with these 18650 cells is they do not have a high discharge potential. Each pack is rated at a max output of 2c or about 6Amps. This gives me only 18Amps total to work with between the packs. Since cruise rests at around 10Amps this should be fine. Near the end of the discharge, the packs are not capable of giving much more than 3Amps apeice. I will need to verify this is sufficient for level flight.
Next up is some real flight testing on these packs. Should be really boring!
I received a new APM 2.6 to replace my fried v1 on Monday. After doing some quick tests, I got to work installing the autopilot in the SkyEye. By removing a hunk of foam from the bottom (see the picture below) – you can place the autopilot and associated wiring and electronics below the wooden mounting board inside of the canopy. This gives the APM basically no overhead in terms of space. You can see in the picture to the left that the APM module, receiver, and USB cable are captured almost entirely below the wooden panel. The GPS/Compass sits above it in an attempt to get a “clear view” of the sky. We’ll see how that works. I’m a little worried about the magnet right above the compass.
Anyhow with the installation complete, I’m about ready to do some testing with the autopilot and parameter tuning.
Note the wear and tear on the nose where the SkyEye comes to a stop. It’s basically a big brake, no matter how good you land. Really needs some tape there.
So I’m posting about a neat little trick I am using to hook up to my APM without having to make a physical connection to a computer. What I’m doing is hooking up the APM to an Android phone using an OTG cable and then using a nifty little app to forward the Serial Port connection over the smartphones Wifi radio. Here is the app I am using:
If you hook it up to your APM’s USB port, you will want to select 115200 baud. You can then open up mission planner, select the “TCP” connection option, and enter the IP address and port from the app when prompted.
Using this trick you basically have telemetry control over your APM whenever the smartphone is within wifi range. And an OTG cable is a lot cheaper than a 3DR radio.
This trick most likely wont work on your cell network. The reason is most cell carriers have what is essentially a firewall between your phone and the rest of the internet. You have no control of this firewall so you are basically prevented from hosting any network servers over your cell connection. What you would need to do this is some sort of middleman. I may put something like this together, although I am not sure if it is practical to offer it to the public. I’ll let you guys know.
As I was setting up my reliable old APM 1 to get it installed in the Sky Eye, I must have shorted one of the PWM inputs. As a result, it no longer receives Radio Control inputs. Fortunately, the rest of the board works so I can still use it for testing.
As a result, I started looking for alternatives. 3DR has recently released their Pixhawk board. While it looks really interesting (I absolutely love how the code is documented and how it runs on a UNIX platform), I can’t really find any documented, successful use of it on planes. Their site claims it works fine but I cant find anyone else who has tried it. That makes me nervous. It doesn’t help that 3DR basically has a “no returns” policy. Oh well.
So, while I would have loved to have gone Pixhawk, I think I am going to stick with classic APM for now. I went ahead and ordered an APM 2.6 board with one of the new external GPS+Compasses to go along with it. Honestly, a pretty sweet deal at ~$260.
The one positive thing about this development is that I can use my old APM as a permanent development/test unit for my interfacing software. This means when I receive my 2.6 board, I can put it permanently in the plane, as opposed to constantly installing/removing it.
Now that the plane has been tested and I have a good idea of the components that I am going to need for this project, I’m moving on to development of the Android app that will sit on the plane and interface with the ArduPilot.
Early on, I realized one of the tasks for this project was going to be coding a better MAVLink library for Java. The existing libraries are simple message decoders – useful for taking in a binary stream of data and translating it into something somewhat meaningful, but otherwise just asking for messy spaghetti code to make use of them.
I’ve jumped on this in the past few days. I started with some baseline code that I “borrowed” from the open source Android app droidplanner and have since been tweaking it to create an event-driven, object oriented Java library that can be used to interface with my ArduPilot while maintaining some semblance of good coding practices.
The library will be made open source. Here is the Github:
This will be consuming most of my time for this project for the next few weeks.
The cruise tests were done in a closed loop at 4000ft with winds speeds up to 9MPH. Due to the nature of a closed, fixed loop over a ground point, they reflect the reduced efficiency I will see due to wind - more time is spent traveling against the wind than with the wind, resulting in a net efficiency loss.
An interesting observation was made during the climb tests, where I climbed at constant rate and then did a steep dive to climb again. Control of the airplane, especially aileron control, decreases substantially as airspeed increases. My guess is that the cheap pushrods that came with the kit are bending when the ailerons are deflected at these speeds. I saw this when I exceeded about 55mph groundspeed, but there was probably a significant vertical speed component to that as well. I am sure that while the tail surfaces remain controllable at this speed, their failure is not far behind the ailerons. Lesson: don’t do dives.
My mission plan is to carry a 9Ah battery load, use a maximum of 8Ah of that and cruise at 1000ft AGL. The fixed 30 mile round trip course should, according to these figures, consume 6.5Ah@12V of energy from the flight systems. This leaves some extra for stronger winds, autopilot power, and loitering time. The full mission should take approximately 65 minutes with no winds.
Up next is integrating an ArduPilot mount into the system and starting to tune the PID controllers. Stay tuned.
A design log for an ArduPilot UAV designed to use an onboard Android smartphone for command & control.