Sigh....I am going to give Peter Hollands an award for finding the "juiciest bug" in the released waypoint firmware for the UAV DevBoard. The bug has been fixed, and the firmware has been re-released as version 1.8b.The bug was in the yaw drift gyro compensation calculation. It would only show up for waypoint legs with a heading between 327 degrees and 360 degrees. The result was that the actual heading would slowly vary between 327 and 360 degrees. The symptoms were barely noticeable.The way that Peter discovered the bug was with a combination of ground testing and telemetry, while he was testing out some really nice programs that he wrote for processing telemetry. Peter noticed an anomoly during ground testing for headings between 327 and 360 degrees.Waypoint firmware for the UAV DevBoard is available in both MatrixNav version 1.8 and AileronAssist version 1.8 from the UAV DevBoard home page, with the following features:• Waypoints are 3D.• Location of the points is specified relative to the initialization location of the board.• You have the option of using either cross-track error navigation, or using navigation toward target waypoints.• Arrival at a waypoint is based on the concept of a "finish line". This produces a reliable assessment of arrival, without any chance of loitering.• The primary source of steering is the direction cosine matrix, so steering continues reliably and smoothly even when the GPS loses lock during banked turns.• Rudder-elevator mixing in MatrixNav, based on the values of the direction cosines, prevents loss of altitude during turns.• You can specify more than 1000 waypoints.Just to be clear, the X and Y coordinates of each waypoint are specified with respect to the power up point. It is not specified with respect to the previous waypoint in the list. The X coordinate is the distance, in meters, along the east direction, from the power up point. The Y coordinate is the distance, in meters, along the north direction, from the power up point.Best regards,Bill Premerlani
Read more…Developer
Posted by Jason Short on October 28, 2009 at 1:30pm
I was wondering if anyone had done any work on orbiting or managing turns? I prototyped an idea I had last night about orbiting waypoints and realized the same algorithm works for turn prediction.On my autopilot I have running a drift compensation routine that maps the desired location of the plane onto a line connecting the old waypoint and the next waypoint. I simply look ahead 10% farther on that line and steer toward that point instead of the actual waypoint. This helps me regain course when I'm blown off or miss it entirely.In my simulator I added a check to see which side the next WP is -right or left- and I use a vector rotated 90° to the plane bearing to offset the WP to the left or right. This vector also allows me to orbit the target.Here are some diagrams and a shot from the simulator showing the orbit. If anyone has done this before I'd love to hear about how it went. I hope to fly it this weekend if my replacement ESC ships by Friday.
Posted by Faisal Shah on October 28, 2009 at 11:02am
http://www.chrobotics.com/CHR6d.phpFEATURES* IMU weighs less than 1.5 grams* .8" x .7" footprint* Customizable FIR digital filter* TTL UART communication interface* 16-bit ADC resolution* +/- 400 deg/s gyro dynamic range* +/- 3 g accelerometer dynamic rangeSophisticated onboard filtering, simple user-interfaceThe CHR-6d Inertial Measurement Unit includes a customizeable Parks-McClellan windowed FIR filter to process sensor data. The filter is easily customized by sending commands over the TTL UART.Open-source firmware makes the CHR-6d fully customizableWhile the CHR-6d comes ready to use, it can also be reprogrammed for specialized applications. In addition to the UART, four extra GPIO pins are routed out for additional flexibility. At 64 Mhz, the onboard ARM Cortex™ processor is fast enough to handle a wide variety of sensing and control tasks.On their products page (http://chrobotics.com/products.php), they also make mention of this :CHR-9d Inertial Measurement UnitComing soon - the CHR-9 line incorporates rate gyro, accelerometer, and magnetometer data to create a self-contained attitude estimation system.No news yet on pricing, but they said it should be available in Oct 2009.
Read more…
Link to "report" [PDF]:http://www.auvsi.org/unmannedscience/newsletter/attachments/140/Barnhard_D.pdfQuote:"In the near future we will see unmanned aircraft systems (UAS) operating in the National Airspace System (NAS) seamlessly with manned aircraft in all classes of airspace. To achieve this airspace integration issues must be solved in a safe expeditious manner. There is much to do by all Stakeholders in the coming dec-ade to realize this end. Approaches to Airspace Integration for UAS are herein discussed with potential solutions and the way forward set forth."Interesting read...desired steps but nothing really concrete yet (but I guess it has to start somewgere)
Read more…3D Robotics
We've wanted to be transparent with the community on our plans for ArduPilot Mega to get feedback, but I fear we've also introduced uncertainty and confusion. Here are some tips and pointers that may help you plan your ArduPilot path.
First, don't expect ArduPilot Mega until well into the new year. Second, it will be considerably more expensive than ArduPilot. Third, it won't necessarily work any better than the current ArduPilot for basic autopilot functions--it's just for people who want two-way telemetry and a more compact installation. Fourth, we'll continue to support the current ArduPilot. These are two different products, for two different customer classes.
We'll also be releasing a product that's for a lower end of the market, an even simpler, cheaper autopilot for inherently stable aircraft (this is a turn-rate limiter autopilot that will outperform the PicoPilot at less than 1/4 the cost). Also Q1.
So think of ArduPilot as a family of products: Entry, General and Pro.
ArduIMU is not part of the ArduPilot line. It's for people who want to integrate an IMU/AHRS into their own project.The IMU in ArduPilot Mega will be custom for that product.
Unless you're really trying to save money, I suggest most people start with the current ArduPilot. It's mature, stable and will be supported as long as we can see. ArduPilot Mega will someday get there, but unless you're willing to deal with our teething pains for the next year, you'll be a lot happier with the current product.
Read more…3D Robotics
First, congratualulations to Brian Wolfe, the winner of the second round of the T3 Contest. Now it's time for Round 3.
This round's objective is to break the Stanford team's UAV altitude record of 7,142 feet by doing at least 24 circles with a 300ft climb and descent in each, as shown above. (This won't really beat his official record, because there won't be an official judge there. But you'll get bragging rights, at least).
The winner will have the highest cumulative altitude, but anyone who exceeds 7,142 feet will win a prize.
As usual, you must submit a KML track and video in the comments below. Evidence that fun was had is welcome (and may influence Gary's point assignment blackmagic equation), but is not required.
Deadline is Midnight PST on November 29th.
Read more…
$3 in mass volume, so that has to mean under $20 single quantity.16bit digital output using I2C Interface is nice, 16bit is a good start.Sadly if it's anything like the IDG range it will never compare to "serious" gyros like the AXDRS range. It's a start though.
Read more…3D Robotics
I still remember how thrilled I was when we passed 100.... Sometime over the weekend, we passed 6,000 members. We're now doing an average of 15,000 page views a day! We have an average of twice as many visitors at any given time as the #2 UAV community, RC Groups.
Read more…3D Robotics
For those on the DIY Drones development teams, you may have noticed a few updates on Huddle. Formatting now works so your paragraphs will break properly in discussions. The >1MB bug in editing documents has also been fixed, so you should be able to edit online without fear of changes not being saved.
Currently, Huddle only supports Firefox and IE7+ on Ning (apols to those using Safari, but not to those using IE6--upgrade!). If you want more powerful and flexible editing and collaboration tools, you can work on huddle.net instead. Just create a free account there and click on "Link existing Huddle.net account" on the top of the Ning workspace.
Read more…3D Robotics
From BotJunkie: "The University of Maryland monocopter can take off from the ground, hover, fly controllably, and land without killing itself. The key was a lot of research into the flight characteristics of the seed pods themselves, which enables the monocopter to autorotate just like the real thing. Obviously, the camera isn’t really useful for surveillance at this stage, but that’s solvable. Researchers suggest that the craft could be airdropped, autorotate for a while, and then be controlled remotely for “defense, fire monitoring and search-and-rescue purposes.”"
And also from BotJunkie, "a prototype of a micro air vehicle called AirBurr that comes from the Laboratory of Intelligent Systems at EPFL. The version in this video is a remote controlled prototype, but the design is intended to be autonomous, with robust collision recovery in indoor environments. AirBurr is a sort of cross between a helicopter and an airplane, with a bunch of airplane style control surfaces and a horizontal plane lifting rotor like a helicopter. "
Read more…Moderator
Hello:I want to use a ublox gps for two item. A paparazzi autopilot, that need a ublox gps, and a osd that need a nmea code gps. And I want to use only one gps. Is there any kind of ublox code to nmea converter? O something like that?ThanksJesús
Read more…
Posted by Faisal Shah on October 25, 2009 at 11:02pm
Figured out how to close the loop!Programs can interface with FlightGear through FlightGear's property tree. Very powerful.http://wiki.flightgear.org/index.php/Property_TreeIf you run FlightGear with the --httpd= option, it will run a webserver on http://localhost: where you can browse the property tree and refresh the current values. Alternatively, in FlightGear you can type "/", and the property tree viewer will pop up and you can view the values changing in real time. I did this to figure out the sign convention for different properties.The property tree can be read from and written to using a "Protocol". The protocol basically defines the format in which data is exchanged. You identify the nodes in the property tree which you want to interact with, the data types, the string formatting, and voila! Attached are the input and output .xml protocol files which I used (copy to FlightGear's data/Protocol directory).The data can be passed through several means, serial port, tcp, udp, etc... I chose UDP for ease.Here is how I ran FlightGear:fgfs --httpd=5500 --generic=socket,out,40,localhost,5000,udp,output_protocol --generic=socket,in,45,localhost,5010,udp,input_protocolI made the input data rate faster than the output data rate, because I would rather have FlightGear waiting for a new input value (when it doesn't get a new input, the last one persists) than the input being buffered.The --generic option allows one to specify a generic protocol, which was defined in the .xml file (attached).--generic=socket,,, ,,,.Attached is a .c program which I wrote to interact with the property tree and provide feedback controls to FlightGear. I've implemented simple proportional control for roll and pitch to stabilize the aircraft. Timing is driven by FlightGear. The code makes a blocking call to read UDP data. It waits until it receives a new packet, processes it, and sends a packet with control inputs back to FlightGear. Then it loops again, waiting for another packet from FlightGear. Currently, everything is hardcoded (port numbers, etc ..), but it should be trivial to make it more general purpose.This should provide a complete framework with which to write an autopilot controller in C.Comments please!udpserver.coutput_protocol.xmlinput_protocol.xmlRead more…Moderator
Posted by Gary Mortimer on October 25, 2009 at 10:24pm
Very lucky last week to get the chance to fly one of these fantastically scfi machines. The chaps were over from Germany on a UK tour and I somehow cracked an invite.
Thats all of us looking very serious, I think an important thing to note is that there were four real helicopter pilots there!
That's the venue.For 18,000 euros you certainly get a capable machine that was very easy to fly in some wind, it was at least 15 knots above the trees and the machine just stayed pinned where you left it in the sky.I took the chance to maiden a slightly different Manta as I think I may have mentioned elsewhere ;-)
Free video streaming by Ustream
Tonight (Sunday) we'll do our regular podcast, which everyone here is welcome to participate in by listening to the chat live above and commenting and asking questions via the DIY Drones chat function. We'll be starting at 10:30 PM PST, to accomodate the time zone differences with out guest, and will probably go about 40 minutes.
This week we'll by joined by Gary Mortimer, talking about the stunning Ascending Technologies Octocopter, his own UAV experience and potential UAV use in Africa. Other themes will include
--Progress on DIY Drones projects
--The VectorNAV IMU
--The winner of the T3-2 contest
--Favorite blogs posts of the week
--And whatever other cool stuff comes up!
Read more…
Finally a UART camera you can multiplex with telemetry. It's a way of getting live preview video without the insane price of 900Mhz video or the bandwidth conflicts of 2.4Ghz video. With 2 Xbees & a computer to control it, it's the cheapest video downlink you're going to get.
For you Xbee fans, the maximum camera packet size is limited by the XBee buffer size to 128 bytes & you have to send an ACK after every packet, thus the XBee latency slows it down by 1/3. Highest performance would take a local microcontroller with full flow control to send the ACKs.It's pure hell to get initialized, but once it starts, it keeps working. Normally just getting it started entails sending init commands, failing, & waiting 10 seconds over & over for several minutes. If it's interrupted in the middle of an image transfer or the serial port glitches, it takes a lot of long waits & init commands to get it to work again.Sleeping around 1/4 second between the snapshot & getpicture commands is required to avoid nasty image corruption, but the JPEG compression is otherwise instantaneous.The lens is really loose, so you'll need to tape it for flight.
Dual radios for autopilot & video.
Ground station for video. Buy a proper XBee breakout board from your sponsors instead of doing this.This is a video of the UART cam in flight. The picture quality is so bad, 160x128 is probably the only resolution you need for preview video.This is a program for getting video off it.video.cNow some benchmarks.JPEG, 128 byte package size, & bare Xbees640x480 (48kb) =15 seconds per frame320x240 (20kb) =7 seconds per frame160x128 (2kb) =1.2 seconds per frameXBees + local microchip generating ACKs640x480=10 seconds per frame320x240=5 seconds per frame160x128=0.7 seconds per frameUSB serial connection & 128 byte packages640x480=11 seconds per frame320x240=5 seconds per frame160x128=1 second per frameUSB serial connection & 512 byte packages640x480=6 seconds per frame320x240=3 seconds per frame160x128=0.7 seconds per frame
Read more…
