I've been working on-and-off on a cross-platform GUI for mavproxy, which I've been calling "mavgui". it's written in QT, and so will run natively anywhere where Qt will ( Mac, Android, Windows, etc ) ... and I've just started to add support in it for a "browser" window ( http://diydrones.com/profiles/blogs/browser-based-map-module-for-mavproxy) , that app would fill perfectly!
I think I'm going to integrate these three into a GCS solution. :-)
The great thing about the mavgui I'm working on is that it's GUI is put together with a tool called "Qt Designer", and is 100% python, so it's trivial to change/tweak the layout for different use-cases like phone etc. The Designer outputs XML, and the rest of the application is 100% python. Here's a quick look at the XML loaded into the "Designer"....
It's not really "one giant GCS" in any sense of the word.. for a start it uses mavproxy and mavproxy modules for most of the underlying comms stuff, and everything else is just easy-to-read python. :-) maybe we should start a new thread for mavgui. ?
There are a couple of parts to my experiment:
(1) completely separate the GUI from mavproxy, so if the GUI crashes, the mavproxy does not.
(2) integrate with a standard mavproxy, with no changes required other than adding a "module".
"netconsole" - an underlying part of mavgui
Sending commands from the GUI "TO* mavproxy ( and hence your UAV) occurs over a tcp/ip connection to the MAV> console, by using a new mavproxy module called "netconsole". As a bonus, you can now also use netcat, telnet, or any other language to instruct MAVProxy. :-)
want to put your UAV into AUTO mode from the command line? try this: echo "AUTO" | nc localhost 45678
want to communicate with a Mavproxy on another machine on the LAN? try this: telnet otherhostip 45678 ( and you'll see a MAV> prompt, just like it was local!
using pymavlink...... another undelying part.....
There's only so much you can do with a tool like "netconsole", as I cant ( yet ) use it to communicate information about the current state of the UAV.... so I've additionally additionally got mavproxy sending a stream of UDP packets ( --out=127.0.0.1:xxxx ) to mavgui, and using pymavlink I am displaying the latest HUD style information in the GUI. ( like altitude, speed, gps details, etc etc ) ... most of the work here has gone into making the underlying communications system operate well, so the mavgui GUI's not yet "perfect" by any stretch of the imagination.... but it's a start.....
I started a new approach in measuring current, voltage and power sensing in UAV devices.
In common, voltage and current measurements are not galvanicaly isolated, read by analog inputs and thus they can cause many headaches to the developers.
I found sone nice current/voltage/power -> I2C ICs, which could perfectly fit the design.
The two examples placed here are with Linear Technology ICs, but you could also use INA219/220/226 or 230 the same manner.....just add a digital optocouplers and...have fun!
The measured voltages with LT ICs could reach 80VDC, while with the TI ICs - up to 30VDC. Measured currents could be higher than 200 and even 300A and depend only on schunts used.
I am taking a break with the familly Startign July 22. Shipping will resume on August 6th.
There is high probabilities that I will be around and shipping in the middle of it (we are not really going away) but there is no guaranties that I will ship orders. On the list of things to do on vacation there is way to many things to say that we will really relax... The list includes redoing the kitchen, getting a new car (lease is over) camping with the kids, beach time, COPTER time with video (even if I crash I will publish the best of moments!) and of course lots of beer! :)
So hurry up if you plan to need something or want a full kit, only 11-12 days to go before we close for 2 weeks!
Oh while at it... let's give you a quick update on the latest improvement on the Original Arducopter frames.
All kits now comes with thicker arms (for the same price).
We listen to your comment and although it was nice to have the lightest frame possible the bent arms were too frequent. So we only ship the new thicker arms from now on.
They weight just 27 grams instead of 14 for the old ones so not a major trade off. The 3DR arms are still at the top of the scale at 50 grams,
Enjoy the summer!
and thanks to all for the amazing ride so far! you all blew my expectation, stay tune to see what the next months have in reserve... lots of new thing brewing....
Hobbyking today added this camera to their catalogue and it seems the perfect camera for FPV, an uncased version of the famous RD32 II. Do a search for it on youtube and you will find nothing then good videos. With a AV out for connecting it to the video transmitter or HDMI to connect it to your HDTV this camera is very complete.
Some of the heighlights of this camera are a 120 degree viewing angle and a 5 megapixel 1/2.5" CMOS sensor and a weight of about 89 grams. It accepts micro sd cards from 2 up to 32GB in size. It supports 720P @ 60fps and 1080p @ 30fps.
This video shows exactly what the camera is capable of:
Some of the specifications: Lens: 5 Mega pixel 1/2.5” CMOS sensor Photo Resolution: 12M 4000*3000 JPG Approx. 900pcs/4GB 8M 3200*2400 JPG Approx. 1200pcs/4GB 5M 2592*1944 JPG Approx. 1700pcs/4GB Audio recording: ADPCM WAV format 48Khz ,Mono approx. 22h/4GB Lens type: F/2.8 f=3mm 120°wide angle Min. Illumination: 1LUX Scanning Frequency: Auto, 60Hz, 50Hz Signal system: NTSC, PAL Vibration Support: Yes Battery Capacity: 3.7V/ 1000mAh
AUVSI has released the very first issues of their magazine, Unmanned Systems, from 1982 (!!) for reading online or on your iPad. The tone was much more military in those days but otherwise it's interesting how little has changed (see below). It's free. Read it here.
Hi Guys It has been a while .My plane is probably 1/2 built I has been "modified and is now a EDF. I covered one of the wings with ultra cote I have to re iron it a couple of more times to get it smooth You think you got it leave it for a while come back and you find spots you missed I started covering the ailerons and flaps also. Then I have to put on the hinges and rigging to the servos in the center of the wing . I found out just recently the word Lypo and Lead start with the same letter and are not much off as far as weight goes ! In the picture of the batteries on your left is the 6s 22.2v 5000mah 30 c lipo that weighs as much as the plane beside it the little green thing is the lipo out of my radian pro to give it some scale and on your right is the 100amp phoenix ice ESC by castle They are going to be suspended in front of the EDF for cooling. The fuselage still weighs under a pound I added air scoops on each side and drilled many more holes to take the added weight back off . The EDF is mounted on "U" shaped nylon rails I have to make a thrust tube behind the EDF and re cut the foam I already made for the fuselage I am going to cover the Exoskeleton and fuselage foam with Rip stop nylon Sail repair tape. I have to build a elevator and I am going to laminate a over sized partially balanced rudder . I might make it a tail dagger with "Tundra tires" ( I still have the landing gear out of the "Somthin Extra and a 26 cc gas engine if this doesn't work) also is a picture of one of the full size metal gear servos for the rudder and elevator at the back of the plane. You guys have a good day!
Nothing is ever perfect. Or even as right as we might like. But I've been holding out on you, my friends, focused as I was until lately on moderating, I haven't been taking the final steps to share my code, photos and images of my aircraft, and other files I've been working on, such as this X-Plane model of an ArduPlane based on the Bixler.
Well, I hung up that moderator hat to focus on contributing in other ways. I wish I could say that gave me the free time to polish this model to the point that it is where I'd like it to be for a general release, but the truth is that I simply added more projects to my plate. I'm not going to let it slide anymore, so this is getting released as it is, and as condemnation and criticism shames me sufficiently, I'll fix it up and release more often.
The model originally came with a 1.5MB, 20 page "developers" guide that spelled out in painful detail the scaling and specific characteristics of the plane. I haven't updated it, it is even more boring than this post, and it isn't required to get flying, so please allow me to bring your attention to the most important aspects of using this model first. Then I'll add some details for those of you who are interested afterwards (and if you really like to slog through overlong explanations, ask me and I'll send you the documentation, in all its outdated gorry...err ... glory.)
Installing
Simply unzip the model files in your "X-Plane/Aircraft" directory. Make sure you are using X-Plane 9.70 or higher.
Before You Fly
Assuming you plan to fly Hardware-in-the-Loop, follow the instructions in the manual, but use the following adjustments.
Increase the number of flight models per frame. In X-plane, find the menu item for "Operations & Warnings", and increase the flight model per frame to at least 3.
In APM Planner, Simulation, change the throttle gain to "5000."
In APM Planner, load the attached Parameter file, then recalibrate your radio and setup your modes according to your preferences.
That is all you really need, but here are some more details for those of you who are interested.
Runways, Grass, and Landing Gear
As you can tell from the video, in keeping with the physical model, there is no landing gear on the plane. A Bixler is typically hand launched, but X-Plane does not include a virtual hand to throw the plane. In reality, there are hidden, invisible skids on this model, to allow the plane to "sit" on the ground properly. Just give the plane full throttle and get it off the ground before it heads for the rough grass, and it should lift off fine. If you get off course, go off the runway, or get turned too severely, it will get "stuck" (as it would in real life.) I've reduced the friction of the "skids" just enough that it will take off from the belly, which is more than it will usually do in real life, but I did not think you'd mind if, on this point, I departed from reality. Most of the time I perform full automatic missions, from take off to landing. If the wind is too strong, or if the mission script is not right, the plane will sometimes go astray and get stuck in the grass. As with after a landing, you simply re-open the plane (or re-open the airport) and you are set for another run.
A Brief Note on Scale
The X-Plane simulator does a fantastic job approximating flight in fantastic detail, and this model was prepared to leverage quite a few features, including drag of the onboard gear, Reynolds numbers, realistic weight, center of gravity, motor and propeller performance, and at one time (now disabled) I even added battery life into the model. However, with models under 5 lbs / 2.2 Kg, the simulator tends to crash. Well, sometimes the plane crashes and sometimes the entire simulator crashes. There are two things done here to address this issue, and it has been very reliable for myself and for everyone who has so far reported back to me. The first is to increase the flight modes per frame (see above) and the second is to scale the airplane such that it is at least 5 lbs. I have adjusted every aspect of the plane to balance a realistic simulation with this scaling requirement. Thus the plane is scaled at 1.7x (size) and about 3x in terms of weight to maintain the correct relationship between wing area and weight in scaling. Proportional changes to Reynolds, motor power, propeller dimensions were all adjusted in concert in an attempt to be as authentic as possible. If you want the specific numbers you can mine the model or ask me and I'll send you more details.
Trimmed, Level Flight
I hope the pilots here will forgive me, this is a note for folks with less hands on experience. Planes are designed and trimmed for specific flight speeds. Many planes flown with more throttle will tend to pitch up and climb, and if the forward airspeed is below the designed speed, they will tend to pitch down slightly and lose altitude. Pilots correct this by trimming the plane, and the APM could do this with the P_to_T parameter (which I have not explored, and which I have also not set in my real life Bixler parameter files... nor have I seen any real life parameter files yet that have this set.)
So it is helpful to know that I designed this plane to fly level at about .480 throttle. If you find it pitches up or down and does not fly exactly level in the simulator, take a peek at your throttle setting. I normally display the throttle data on the screen during flight, and you can do this easily as well. Look at items #25 and #26 in your X-Plane Data Input & Output. The circled items below are essential for HiL, but the items I did not circle are recommended for onscreen feedback.
A Big Thank You
I want to say thank you to a few people who either directly contributed or cannot be left out of any list of thanks related to ArduPlane (and, sadly, I will leave people out, my apologies.) A big thank you to:
Chris Anderson, Doug Weibel, Jose Julio, Jordi Munoz, Jason Short, Andrew Tridgell, Michael Oborne, Paul Mather, Bill Premerlani, and everyone else who shaped ArduPlane and, without whom, this work would neither be possible nor of any value. And a special thanks to Knut Lagies, Didier, Robert Elgin, Yury, David Buzz, Thomas Berndt, Justin Beech, Colin Bouriquet, Michael Brown, George Dimitoglou, Kevin Finisterre, David Jones, Mike, Carlos Moreira, Linux Penzlien, Pavel Skotak, Eric aka Eagle, Dusan Trenic, and Stephen Wong for flying a previous version of this model and providing feedback.
A Note on Reproducibility and PID Tuning
These PIDs work well for me. However, since each HiL computing environment is different, variations in the resources of the OS, running processes, and especially background tasks such as an Antivirus scan can dramatically affect the latency of control and sensor data to/from the APM. If these PIDs do not work for you, check that you don't have resource hogs tying up your memory or CPU, and please do share your PIDs as you get them dialed in better for your environment.
Here is a previous video (very cheezy; I was having fun with an iMovie template) announcing the plane, provided for your amusement.
What about X-Plane 10? Flexible Wings?
Yes, I have produced a variety of different models, including an X-Plane 10 model leveraging the nifty bendy wing features (and in real life, the Bixler's wings flex like crazy.) However, as X-Plane 10 was brand-spanking new at the time, there were issues in using it for HiL that, combined with the additional cost and lack of backward compatibility, caused me to give up this sexy feature and restrict myself to an X-Plane 9 model. You can open and fly this in X-Plane 10, and you can also open and upgrade it to a native X-Plane 10 model using Plane-Maker yourself. If there is enough demand, I'll explore flexible wings and X-Plane 10 again. I have also made 3 channel planes and other variations. If you are really that excited about a variation, please let me know.
I have the TH 9X channel transmitter, and the biggest problem I have with this remote is the most accurate way to change flight modes is by flicking one switch so whenever I want to change a flight mode I have to change flight mode 6 because flight mode 1 is always stabilize and simple mode, now this gets a bit irritating so one day someone posted a blog here of a potentiometer with 6 clicks and some variable resistors to each click on the potentiometer so you can define the PWM. I bought this for about $15hereand it was at my door in about 4 days, it was crazy. I bought the unsoldered version so I had to do some fine soldering.
Now the variable resistors has 3 legs (+) (Feedback) (-) it does not matter which way is the plus and minus. I took an old parallel cable from an old hard drive mounting and cut 6 strips from it about 10cm long and cleaned the plastic from it and soldered the two most outer wires from the bunch to the (+) and (-) and then Is soldered to all of the pins a piece of wire.
Once all that was done, I soldered the 4 inner wires to a number on the potentiometer, and the previous potentiometers brown wire where it said brown and the black to the black and red to the red. I then soldered the 2 most outer wires to the black and the red.
I then broke of the previous potentiometers plastic housing and drilled a bigger hole in the cover so that the new potentiometer can fit. Please note the extra smaller hole on the left hand side of the big one that I made, it is so that the new potentiometer fits snug into the hole.
I then fitted the nozzle thru the whole tightened it with a nut on the outside.
I then found a nice place to hot glue the variable resistors to the back of the cover so it is easy to come by with a screw driver because you have to adjust the variable resistors so that the signal is set to the correct PWM for the specific flight mode.
And then I started tuning the inner flight modes because the most outer two knob settings is always flight mode 1 and six and knob area 4 is also always flight mode 1. First set your aux-ch option to the following. Please note channel 5 is set to Pit trim.
I opened flight planner and started turning the variable resistors on each unit until the green on the dropdowns showed on the correct place.
An now I have 5 accurate flight modes to choose from without any hassle.
The new design calls for 1.8-meter, 0.5-kilogram carbon-fiber blades, each paired with a motor. They are arrayed around a hub in two concentric circles over a boxy one- or two-person cockpit.
After awarding the volocopter concept a Lindbergh Prize for Innovation in April, Yolanka Wulff, executive director of The Charles A. and Anne Morrow Lindbergh Foundation, admitted the idea of the multi-blade chopper at first seems "nutty." Looking beyond the novel appearance, however, she says, e-volo's concept excels in safety, energy efficiency and simplicity, which were the bases of the prize.
All three attributes arrive thanks largely to evolo’s removal of classic helicopter elements. First, the energy-robbing high-mass main rotor, transmission, tail boom and tail rotor are gone. The enormous blades over a normal chopper's cabin create lift, but their mass creates a high degree of stress and wear on the craft. And the small tail rotor, perched vertically out on a boom behind the cabin, keeps the helicopter's body from spinning in the opposite direction as the main blades, but it also eats up about 30 percent of a helicopter's power.
The volocopter's multiple rotor blades individually would not create the torque that a single large rotor produces, and they offer redundancy for safety. Hypothetically, the volocopter could fly with a few as 12 functioning rotors, as long as those rotors were not all clustered together on one side, says Senkel, the aircraft's co-inventor and e-volo's lead construction engineer.
Without the iconic two-prop configuration, the craft would be lighter, making it more fuel efficient and reducing the physical complexity of delivering power to the top and rear blades from a single engine. Nor would the volocopter need an energy-hungry transmission. In fact, "there will be no mechanical connection between the gas engine and the blades," Senkel says. That means fewer points of energy loss and more redundancy for safety.
E-volo's design eliminates the dependence on a single source of power to the blades. As a serial-hybrid vehicle, the volocopter would have a gas-fueled engine, in this case an engine capable of generating 50- to 75 kilowatts, typical of ultralight aircraft. Rather than mechanically drive the rotors, the engine would generate power for electric motors as well as charge onboard lithium batteries. Should it fail, the batteries are expected to provide enough backup power so the craft could make a controlled landing.
More details and render videos at the E-Volo site.
Recently Ars Technica did a piece on software defined radio, using the Phi product as a centre piece, it got me thinking about its applications for drones.
Software defined radio basically allows people to write programs which interact with radio waves on a host of different frequencies (100 kHz to 4 Ghz), what this means is instead of having a chip dedicated to GPS you could have this card in your computer and instead run a GPS program. While this may not sound like much, something that has always bothered me about my drones is my use of a third party datalink that I have limited control over, and I believe this kind of thinking is the answer. I would certainly love the ability to apply my own compression methods to my data packets and video and choose my own method to send them (i.e. on which frequencies).
I also like the ability to have different protocols opened up by simply developing the software to them rather than developing or reverse engineering the hardware. Good examples of this might be giving people the option of receiving aviation communications through UHF/VHF and interfacing to GLONASS.
Currently I see the major disadvantage to this technology is its PCIe requirement (Raspberry Pi does not support this, so a traditional motherboard with a traditionally large surface area would have to be used), and no doubt the processing power required might not be trivial.
The current issue of online/iPad magazine The New Inquiry is all about drones. It's a bit arty/academic/political, but pretty interesting all the same. The content is subscriber-only, but it's just $2/mo to get and you'll have instant access. Yes, DIY Drones is mentioned.
Some of the articles are a bit of a reach ;-)
But others are very solid. Here's the complete table of contents:
RC Arduino is a cool site that documents how to add an Arduino with gyro sensor to a RC car to make it more more controllable, basically "driving by wire", rather than directly, with the Arduino making sure it doesn't spin out.
They explain:
"All of the throttle and steering commands in the car in the video are coming from an onboard Arduino. The Arduino is reading the incoming signals from an (drivers) RC Receiver and also a gyroscope within the car. It is using this information to assist the driver by controlling the yaw of the car under acceleration, braking and cornering."
There are some other cool Arduino-based RC car project there, too, so check it out.
Further progress requires starting to desolder the Heroine 2200 boards. That was the 1st robot. The ages from 25-30 were spent purely devoted to that 1 thing, while everyone else was clubbing & getting married.
Heroine 2200 would still be a working robot, with new electronics. She was very unreliable with the old electronics, but modern vision systems & high bandwidth I/O could give her the accuracy to do the job.
There isn't a rationale for an automated method of organizing media. A human can get up & change it much faster than a machine.
So the equatorial mount naturally avoided gimbal lock without any crazy rules. The mane question is if it's fast enough. The takeoff move is so fast, it's not likely to keep up. The alt/az was far enough away to not need to be fast.
So the solution to the equatorial to spherical transformation was once again a quaternion rotation, just like the inertial navigation. You can invest a lot of effort into a discrete cosine transform, but the quaternion is intuitive. Then, the position calculation was the same as the alt/az mount rotated on its side.
After another round of bug tracking, the USB ports on the laptop's right side turned out to not support the webcam, while the USB port on the left side was the only one that worked. It was full blown lack of packets, even in isochronous mode. Yet another fine point to remember.
Webcam failure Vision could always be counted on to hit another failure point. So the problem is the ND filter makes everything look red. It could handle old 100W CFL's, but the new 100W CFL's pointed at the camera showed up as red & the 150W CFL's flooded it red. More tweeking or abandonment is required. A full range search with a known red marker might be required. Vision is an absolutely horrid, complete bodge.
So Marcy 2 would capture video, but only fly in a dark room or a room with only lights pointed away, which defeats the purpose of capturing video. It would be as practical as a vicon copter capturing IR video.
Board cam. The board cam with maximum shutter speed does a better job, but won't get the required smearing without its own ND filter, turning everything red.
There are more techniques, like requiring the blob to be a square or rectangle. Marcy 2 will require certain conditions, like not pointing lights at the camera & only flying indoors, away from windows or vicon cameras.
it was really solid. Its only problems of note were related to Marcy 1 being too unstable to stay in the sonar's limited range & no way of pointing the transmitter straight down.
Modern Marcy aircraft are so stable, they may work. Modern, centrifugal mounting may get it pointed straight down. It would be a lot cheaper than vision. A dedicated sonar system, with dedicated radios & micros might do it. The servos & fabrication make vision real expensive.
The PIC wasn't fast enough to do the required sampling rate, so it had a lot of aliasing & crosstalk. The op-amps didn't have a high enough frequency range. Doing the processing on a PC added a lot of latency.
Sonar using high quality, discrete preamps, a dedicated radio with no latency, all the processing done in microcontrollers & a fast ARM on the ground might outdo vision in cost & range. It would solve the problem of takeoff being out of vision range.
In the sonar department, the STM32F4 is so expensive, a completely analog solution with PIC for purely timing is more attractive. It was using a comb filter, integral, smoothing & short term maximum in software.
A reasonably priced analog circuit could only do a threshold & rely on the transducer's narrow band rejection. The blog posts showed a lot of aliasing & background noise. The PIC would have to set the threshold based on the false positives between pulses & time the threshold crossings, but it couldn't sample the waveform.
It might work, because the low sample rate & crosstalk were the mane problems. The comb filter made it more directional.
For another sonar recap, built up a send & receive test jig. The transducers do 24.5khz.
The sampling rate was a killer in the original. The original did 74khz. The oscilloscope does 130khz with 2 channels & 266 khz with 1 channel, still getting a lot of aliasing. The oscilloscope has a lot of quantization when using 2 channels & aliasing, even at 130khz.
There's no obvious problem with the LM324 preamp. The problem with sonar is the transducer doesn't start up instantly. The background noise is manely echos. A cheap ARM doing the full signal processing at a high sampling rate will be cheaper than an analog system.
