in order to simulate it over a vast terrain we know and use.
The range plot was made from 4km2 elevation model made by Pix4D and Pteryx UAV.
Treat it as a kind of reminder of what happens when landing using FPV.
We know the results are valid since they match our experience
and measurements of range at several altitude levels.
We don't name the systems but mentioned RC systems are the best hobby grade you can buy off the shelf without law & power restrictions.
Things look perfect at flight altitude of 5m, but even with slightly undulated area the horror starts during touchdown, you get anything from 300m to 2km range. The area pictured is 2x2km.
Atmosferic wave diffraction is accounted for (negligible impact here).
866MHz 100mW modems were tested and have shown similar range as 35MHz range at ground level (but only with huge 35MHz antenna, strictly vertical). The plot really shows where we have 95% modem bandwidth or good RC control, when overall low control latency is required: during the landing.
Posted by Chris Anderson on December 27, 2011 at 10:07am
From IEEE Spectrum, a report on the latest EPFL research on bio-inspired flying robots:
Gliding is a very efficient way for getting from getting from point A to point B. Jumping is a very efficient way of getting into the air at point A, especially if there are a bunch of obstacles between point A and point B that it would be a good idea to be airborne to make it over. Grasshoppers have been doing this for, I dunno, probably like a hundred million years, and roboticists at EPFL are starting to design their robots with the same kind of jumping talents and expandable wings as our orthopteran friends.
The jumping part, and the crawling around on the ground part, is somewhat impaired by the bot's giant wings, which is why getting this whole folding thing figured out would be pretty cool. Here's the locust-inspired folding mechanism in action:
Video of ROFL Tuning Session with spectacular crash when we deliberately detune one of the PID values! No quadcopters harmed (much) in the making of this video. Video of stable flight below.
The video shows our tuning set up, this is the setup we use to test and tune new control schemes for our ROFL kits, and you can see part of our debug console running on a laptop - it's an app that contains logging functionality, displays raw hex values from the quad, and also sends various parameters with plenty of input boxes and sliders. There are no labels on the sliders and the input boxes because the speed at which we develop the code means we repurpose these inputs for different parameters several times a day. End-users of the quadcopter kit will have a much more streamlined interface that can be used to fine-tune their quads.
The ROFL we use for code development is our ROFL-H variant, which uses Hivebrain instead of Forebrain for the control board. Hivebrain is the same ARM Cortex-M3 powered microcontroller board, but with an integrated surface-mounted XBee module with external antenna. The computer has another Hivebrain module connected over USB (that you can see in the foreground), communicating with the debug console over USB-HID, which we find to be a lot more reliable than USB-Serial that you would normally use with XBees, and a lot easier to implement since Hivebrain/Forebrain has a built-in USB-HID stack in ROM.
At the end, as a quick demonstration, we change one PID component to zero just to see what happens. Turns out this is a bad idea and leads to fast growing oscillations!
Here is another video taken in the same session, testing the current codes response to external disturbances, I use my right hand on the cyclic, so when I am using it to push the quadcopter around I only have throttle and yaw command available. The clutter and confines of the garage are a bit limiting, and we need to add finer throttle control. We are moving to some larger testing grounds soon!
As an engineer of rapidly growing experience, one of the hardest lessons I have learnt is how much time testing and tuning can take.
In an ideal engineering world, no testing is required, and no design modifications are needed during the build. The closest we come to this ideal is in the design and manufacture of very high cost structures such as civil turbofan engines and bridges. However, because these structures are so critical we have to use 99% previously proven theory and design methods, which in turn means changes are incremental, it is not economical to make wild guesses and risk significant differences from one version to another.
Micro UAV design is much the opposite, making exciting new designs into uncharted territory can be very rewarding, discovering new operating regions and performance gains, importantly it is also feasible to do this as mistakes are not economically self destructive.
ROFL, shown flying in the video above, is what I'd class as a structural design tangent, it differs from already available UAVs not in concept, as it uses a conventional quadcopter layout, but in structural design.
The vertical plate design makes the construction extremely simple, the frame very cheap, highly modifiable, at no sacrifice to weight or stiffness. Yet it is very much still a quadcopter.
Converging on a successful mechanical design and writing the initial flight code was a small part of the challenge however, the BIGGEST CHALLENGE then became streamlining the code modifications and tuning!
If each time you make major changes to the code, you have to retune, it's easy to see where a lot of your time is going to be spent over a few months!
Posted by Daniel Hibben on December 27, 2011 at 1:17am
I fly FPV as do most of you Here at DIY Drones, and I will admit that I have flown at times without the use of a Spotter. Yes I know it’s a bad Idea to do so, however I also know I’m not alone. Lots of you do This I know I have seen The videos, But I don’t want to talk about this other than to raise the point that a spotter is not always available at times or necessary, If you are way out in the sticks, and under 400 feet no Biggie in my book. Others will I am sure disagree but that is a discussion for another Blog.
The big problem is that the requirement for a spotter comes from aviation law / rules / advisories that define a remote-controlled aircraft to be a vehicle flown via unaided visual contact. In order to meet this requirement, a spotter that has visual contact to the aircraft and possibility to take over control is needed. The visual line of sight rule comes from another section of aviation law, which dictates that people participating in the airspace must be able to "see and avoid" at all times.
My question or idea is why not have a Collision Avoidance System in conjunction with an autopilot?
It seems simple to me, and yes I know The FAA is not fond of autopilots on our aircraft, however we fly in a very artificial environment to say the least. And we use all manner of electronic devices to give us Air Speed, Altitude, Heading, and more, so why not add a collision avoidance system to what we currently use to help be that extra set of eyes we need. Add an auto pilot that could take control in the event of a loss of signal or other mishap, and it would make flying FPV a lot safer for all. No it won’t replace a human but it would help with”see and avoid”, even pilots of full size aircraft have trouble with this in crowded airspace which is why systems like these exists in the first place.
I recently went looking for a small affordable system and I found one, I am sure there are others.
The Zanon flight Systems PCAS MRX is a tiny system that is as small as the radar detector you might have in your Car, yet it can monitor your location, altitude, and heading, and will let you know if any other aircraft are in your area, that and many other features. Yes those other aircraft need to be broadcasting a transponder signal, however the FAA requires most all small aircraft to do so, except for ultra lights, para gliders, and the like, and I think they would like even them to do so. I would think this should be very valuable information to those of us flying FPV. Some of the units ability's are: Digital range, scalable from 5NM to 1NM, Relative altitude, scalable from ±2500 ft to ±500 ft, with ascending/descending indicator, A built-in altimeter for real-time accuracy, Displays the local squawk code and altitude, Audio alerts for threats and advisories. Not bad for its size and price, it sells for about $550.00. Until we can put a radar system on our planes and multi copters this might be the way to go. I think it should be possible to adapt this device, or one like it, to work with our OSD systems and auto pilots and give us that extra bit of real time safety that a spotter allows. The website for this device is here at http://www.zaon.aero/content/view/2/41/
Just food for thought I don’t have any Idea how hard it would be to add this to an OSD/ auto pilot, however I think our hobby is getting to the point where we will need something like this soon. And with all the talk about new regulations for drones coming soon I think it would make pilots of commercial and privet planes feel a lot safer to know we can see them and we are listening to FAA control and advisories for the airspace we are sharing with them. Please Let me know your thoughts about this idea, and thanks for your time reading my ramblings
Posted by Chris Anderson on December 26, 2011 at 10:14pm
Here's a good post by Mark Suster, a VC, on "The amazing power of deflationary economics for startups", which I think neatly explains the economic and innovation model behind 3D Robotics and most other open source hardware companies.
It starts by reminding us of the classic disruptive business model from the Innovator's Dilemma:
In the simplest form, new startups have a product that is INFERIOR to that offered by the competition but at a dramatically lower price with the seller opting for a very thin margin on their product.
Initially their only customers are people who can get by on the reduced functionality or perhaps don’t have the money to spend on the expensive product.
Often it turns out that the market is greatly expanded by having a lower price point new entrant. And over time the new entrant attracts enough business that, as depicted in the graph above, the quality of the product slowly increases over time.
The new entrant keeps margins low but suddenly has a lot of profits due to large volumes of business.
How does the incumbent respond? Not by dropping price & quality – they don’t have an advantage there. Instead they spend more money trying to innovate on product quality and call attention to the weaknesses of the new entrants product quality.
Often major customers defect en masse to the new entrant as they realize that the huge price premium is not justified by the product differentials.
It then provides some questions to ask to see if your product/service fits this bill:
Does your product dramatically reduce costs in an industry with large incumbents and fat margins?
Can you provide a narrowly focused product to a niche of that market who will be attracted to dramatically lower costs?
In the case of UAVs, both these seem true: most companies in this space price their products like military-industrial products, not consumer electronics. They typically have the margins of defense contractors. Meanwhile, the civilian/amateur market for UAVs is much more price sensitive and has been poorly served to date, both because of the high prices and also the regulatory restrictions on closed-source vendors.
The open source entrants in this space have the opportunity to be classic disruptors: faster, cheaper and, eventually, better. Starting with the original open source autopilot, Paparazzi, they were initially dismissed as being buggy, hard to use and poorly supported. But as more teams entered the fray, the open source autopilots got dramatically better, and prices continued to fall. Meanwhile the volumes rose: the ArduPilot project, for example, has shipped nearly 10,000 autopilot boards across all its varieties: that's more than all but a handful of the biggest aerospace companies.
Sure, there's still a lot of work left to do to make the open source autopilots as robust as a milspec one, but the gap is closing fast and the open source ones sell for $200 while the milspec ones go for 20 times that or more.
At 3D Robotics (the hardware company behind the DIY Drones store) we think about open source hardware as a "90/10" opportunity: 90% of the performance of commercial alternatives at 10% of the price.
Of course, we'd like to do even better over time--we think that the open source innovation model is not just cheaper than closed source, but can be better, too (think Linux, Firefox, Apache, etc). So maybe 110/10 is possible, or even more when you include things that open source projects are good at, such as introducing new feature quickly and creating open platforms for user innovation.
These are still early days, but I think the civilian UAV market will someday be even bigger than the military one. If the Innovator's Dilemma holds true, bet on the little guys moving fast and cheap to eventually dominate.
After figuring out that I can remove and modify the motor shafts on my own (read part 2), I also learned that if you tap the bell and shaft of a brushless motor too hard against something, the magnets fall out. I tried my best to glue them back into place, but they were rubbing against the stator. Scrap 1 motor, but thank god I planned for a spare, and still have 3 working ones. Things are coming along. I've tested all my ESCs and balanced the motors. I still haven't got a few key components, like prop adapters. I hear they're pretty important :P
I have limited travel on my yaw assembly. I'd like it if it were able to make a full 45 degree tilt in both directions. I'm also debating if I should be planning to go with one counter rotating forward prop to help out the yaw a little. Right now, I haven't given any of the motors any kind of tilt, but that could easily be altered by adding thin washers under one side of each motor to change the direction of thrust just a little.
Hi, I am still having problems to get my radio controls in order for my hexa.
After a couple days of absence, I tried again today to get my radio calibrated, and it still didn't work. I did receive a message after all from the supplier. I send them a picture of my receiver connections and they said they were right, that is after I changed sides for the cables as was suggested. I also changed receiver and 8CH transmitter (as I have 2, the second one meant for videography later). It is a Walkera 8CH. Still no success. I put on the transmitter in plane mode today, put on lippo after taking out the 4-power-wires, connected the USB to MP, clicked on connect with success (a red LED blinks in the receiver), clicked on APM setup in firmware, clicked on calibrate radio in the radio setup, I see the green bars and small red lines, but when I move the sticks on my transmitter to go to the maximum, these green bars don't move at all. I only have 1500 readings, which mean no connection, no ? What am I doing wrong ?
I did this inside so no GPS lock and no internet connection, as I supposed this was not necessary for radio setup, but maybe I'm wrong.
Can anybody help me out maybe ? It's frustrating I still couldn't fly my hexa after more then two weeks.
Made a program that spun Marcy 1 in a variety of throttle & cyclic settings, to measure the effect of cyclic on period.
Regardless of battery charge & battery weight, period for every throttle & cyclic had roughly the same curves. Subsequent test runs got amazingly similar results. The only thing affecting period was PWM.
That was subtracting cyclic from throttle to flatten the curve, but it did the opposite. What seems to be happening is cyclic subtracting more throttle than it's adding which causes RPM to go down.
Then the throttle hits minimum on the subtracted side, but keeps adding cyclic on the added side, which causes RPM to go up. Then we're hitting the limit on the active side & the inactive side for all greater cyclic, so RPM is constant.
Adding straight cyclic to straight throttle gave more consistent RPM curves.
Another algorithm which just subtracted exactly as much cyclic as it added, with the maximum determined by total throttle got pretty flat curves.
Even if we can't fly anywhere, the test jig did show some usefulness. The next great task is making a test jig for altitude.
Then, there was this thing from many months ago.
Thought it could be used as a super cheap airfoil in a monocopter. It would be limited to the smallest power system. The torque would destroy it. The motor would have to be mounted on it. Extra weight would be required on the balance beam.
Finally decided to move the GUI to C++ from Java. Java is what makes money, but was real clunky & slow. Java required a 188MB development kit on every computer we wanted to compile it on.
Here, the C++ rewrite is on the right & the Java version is on the left. The main difference is how Java uses a proportional font while C++ uses a fixed font, which looks much better.
Lowpass vs averagingnotes
After 3 years involved in the subject, we now think averaging is a better deal than lowpass filtering. Lowpass filtering is supposed to remove aliasing, but for all the talk of aliasing, let's consider the disadvantages.
The lowpass filter doesn't buy anything else except removing aliases. A simple, 1st order lowpass filter is not going to chop off exactly at the nyquist frequency. It needs to remove way below the nyquist frequency before all the aliases are truly gone. Finally, it takes a lot of fixed point spagetti code if you want it to work fast, without an FPU.
The lowpass filtering we've used has probably not been as good as the averaging we used before. It's probably caused more oscillation by increasing lag time than averaging caused by letting aliases pass through.
Having said that, the damping foam & ballast we use has allowed the lowpass filter to pass 1/8 its bandwidth in the roll & pitch direction, while passing 1/4 its bandwidth in the yaw direction. That's just as good as averaging, so we're not inclined to change it.
145Mhz radio notes
Some ideas for a voltage controlled oscillator came to mind. Basically, fabricate a multivibrator which can get in the 145Mhz range. Feed a counter with it & have a microprocessor PWM the input voltage. That might get close enough to use only a 256khz ADC.
Common transistors only get 2:1 gain at 150Mhz. The counter would need a high voltage swing. Just don't have enough instrumentation to test the thing. Something could certainly be built in the 1Mhz range, just to test software radio.
What you want is the AD9552, a frequency up converter. That can generate exactly 145.8Mhz for $14. Nothing is cheap in this business. Anything providing decent reception is going to be comparable to a $100 scanner.
This operation has little point. The ISS broadcasts a repeating morse code beacon. You'd get it for 30 minutes per orbit. There was more point in the trapezoidian equatorial mount. That produced images.
The dev team is delighted to give a Christmas present to ArduPlane users in the form of a new geo-fencing feature!
Geo-fencing allows you to define a GPS fence around your flying area, plus a minimum and maximum altitude. Within the fence you can fly ArduPlane normally in any mode you like. If you go outside the fenced area then the APM will automatically take over and bring the plane back to a pre-defined return point, ready for you to have another go.
We're hoping that this feature will both help beginners learn to fly, and also allow experts to perfect complex aerobatic stunts while minimising the risk of a crash. It is also ideal for ensuring that local club rules on flight boundaries and maximum altitude are followed.
You can read all about how to setup and use the new feature in the ArduPlane wiki, but I thought it might be fun to tell you about a test I did of geo-fencing yesterday at my local flying field.
It was Christmas eve, and I was at CMAC testing the geo-fencing code. A family had turned up to watch the planes flying, including Wilson, a 5 year old who loves aeroplanes
I thought this would be the perfect opportunity to test geo-fencing as a training tool, so I asked Wilson if he'd like to try flying a plane by himself. As you might imagine, he enthusiastically agreed!
I took up my SkyWalker with the APM2 fitted, and then enabled the geo-fence. At first I put it in a loiter at about 70 meters, and showed Wilson how he could control the loiter using the transmitter sticks. After mastering that we put the plane in FBWA mode, and Wilson flew it himself. He was delighted!
The fencing really made a difference, as he made some mistakes and flew outside the defined area or too low a few times, but each time the APM took over and brought the plane back to the return point, where it loitered ready for him to have another go. We then flicked the trainer switch to give him control again, and he took the plane around more than a dozen circuits. Not bad for the first time flying a plane at that age!
I also did some test flights with my SkyFun yesterday, and I was delighted to find it worked very well with geo-fencing. One of the reasons I added the geo-fencing feature was to help me improve my manual flying skills. I've found that flying with the APM stabiliser enabled means that my flying skills don't improve as much as I'd like, so I really wanted to practice flying more in manual mode, but I also found that in manual I tend to crash far too often. With the geo-fence enabled I can fly in manual with a safety net. That allows me to really improve my flying skills without crashing. It means I don't need to remember to change modes when I get in trouble - the APM is constantly monitoring my position and altitude, and if I am about to crash it takes over and brings the plane back ready for another try. Great fun!
Many thanks to Wilson for test flying the new ArduPlane code and happy Christmas to ArduPlane users everywhere!
This week I did some general flight testing of the Nova to confirm it’s CG location and to determine it’s general flight efficiency.
It consumed more amp-hours than the GeekStar did, however after further consideration I believe measuring efficiency “per hour” doesn’t make a whole lot of sense. Instead, a “amp hours per mile” would be more appropriate. In this case, I think the Nova would win out as it’s cruising speed at half throttle is easily 2 or 3 times faster than the GeekStar with the same throttle setting. More testing is indicated.
Posted by Gary Mortimer on December 22, 2011 at 11:46pm
If you are planning on flying commercially in the USA, ie take photos for money from your platforms. You really ought to be a member of RCAPA and follow their very simple guidelines.
We hope to be able to put out some information on proposed standards for airframes shortly.
All the fuss about rule changes by January is based on the NPRM process which was slated to start in January but if you follow sUAS News you will know that has been put back many many times. I abandoned the countdown timer on the top right of the home page as changing it all the time became dull.
sUAS News believes the process will now start April/May then go into 90 days of comments.
This may well change.
Now is the time to get ready. They cannot hold this process back many more times. The big boys are facing reduced sales to the military and they need to start the civil push.
