Blogs

All Posts (14056)

Sort by
3D Robotics

Update and guidance on ArduPilot Mega

Posted by Chris Anderson on October 27, 2009 at 4:30pm
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

T3 Contest, Round 3

Posted by Chris Anderson on October 27, 2009 at 4:22pm

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…

My email to SPARC regarding Sparkfun cease and desist....

Posted by Mike on October 27, 2009 at 3:36pm
Dear Sirs,I am writing to express my disbelief and disappointment that you have issued a cease and desist notice to Sparkfun in respect of their tradename. I am a customer of Sparkfun and have bought their products in relatively large numbers in recent time. I have never at anytime confused their products with yours and...Out of interest I went to my search engine (Yahoo UK & Ireland) and searched for 'SPARC'. The first result was "SPARC - Strategic Promotion of Ageing Research Capacity". Hmmm,I hope I have not inadvertently created a problem for that erstwhile organisation by pointing out their potentially alleged breach of your trademark. Further down the first page of the search were a number of organisations going by the name SPARC. And of course the SPARC they are using is an acronym, just as is the name of your company (derived I believe from Scalable Processor Architecture). That is interesting. So the only similarity between your tradename and that of SparkFun is that the first syllable is sounds the same? Because of course the origins are different. SparkFun is derived from the 'real' word 'spark' and your word 'SPARC' is an acronym - not a 'real' word - of something that does not have anything like the same meaning. A quick search on Yell.com for Spark gave me the following: http://www.yell.com/ucs/UcsSearchAction.do;jsessionid=B9775C9A5B29D4E8835460CFEADA240E?startAt=30&companyName=spark&M=0&searchType=advance&ssm=0&startOoaAt=0&ppcStartAt=45&lastKeyword=Plumbers&pageNum=4I wonder if SparkFun should go after a few of those at some stage? Maybe you might like to consider it yourself.It is interesting that you claim that your SPARC sounds like spark - yes it does, amazing that you are effectively trying to restrict the use of the English language in favour of an acronym....I further notice that your legal representatives have stated categorically that SparkFun supply 'identical goods.' Now here is where you got my attention! I would be so grateful if you could supply me with a list of those goods as I am always on the look out for better priced goods. I have to admit that I did have some problems finding the following goods on your website and I would particulary be interested in your links to the following popular items (do you accept Visa Electron?):VTI SCP1000 pressure sensor breakout board (the Sprakfun is SPI but I would be REALLY interested if you did a TWI version - I think it uses the SCP1000-D11);short lengths of breakaway female headers because SparkFun only do them in strips of 40 and the problem is that when you break apart the section that you need you lose one pin and the end looks pretty grim - especially if you are trying to develop a commercial product (I hope yours are not too identical if you know wnat I mean);ArduPliot - they only supply it in red which to me is a bit aggressive;this one is a bit off the wall I know but do you sell hoodies? I really wanted to get a SparkFun one but as you supply identical products I may be shifting my brand loyalty and of course I am always ready to help promote and identify myself with a worthy product. My problem with SparkFun is that I am XXXL and their tees only go up to a XXL and while I really fancy the wrist belt I am a big guy and am not really sure that it will fit. Maybe your own calalogue will have a greater variety of sizes - or maybe they are identical too? Do your hoodies have SparkFun written on them if they are identical?Anyway, I am really look forward to receiving your list of identical goods so that I can compare, contrast and hopefully get a better deal.Oh yeah, before I forget - your legal advisors are trashing your reputation and that of your holding company - well it's alleged anyway.Regards (allegedly),Mike(PS, don't forget the links and the thing about the tee-shirts - thanks)
Read more…
Developer

ArduIMU code tests/improvements

Posted by Jose Julio on October 27, 2009 at 10:50am
Hi all, hola Jordi!. I have made some test flights with a modified arduIMU code in stabilization assist mode with good results. Mi test platform is a small swift II wing (this is not an easy plane for an IMU...). See telemetry video

I have been working on an imu and AP code for some months. I have tested it and fly it and works well on normal conditions. When I see the news from Jordi of the arduIMU (Thanks Bill and Jordi...), I downloaded the code and tested it and adapted it to my hardware (Locosys GPS, Sparkfun 5DOF [old model with IDG300] and a LISY300). It works fine in static tests but have some problems: slow response, vibrations from motor and problems in dynamic conditions. I start to look at the code and I implemented some modifications to improve the results.1) The code is using a free running ADC mode but only use the last ADC reading, so the effective sampling rate is only 50Hz. This generates aliasing problems (in vibration enviroment) becuase the sample rate must be 2x the bandwith of the sensor. In your hardware bandwith of gyros is 88Hz and accels 50Hz so we need a minumun sampling rate of 176Hz and 100Hz. The simpliest solution is using all the ADC readings and make and average. In my Atmega328 at 8Mhz I have about 550Hz samplig rate.Code:volatile uint8_t analog_count[8];...ISR(ADC_vect){...analog_buffer[MuxSel] += (high << 8) | low; // cumulate readings...analog_count[MuxSel]++;MuxSel++;...For read:AN[0] = analog_buffer[0]/analog_count[0];AN[1] = analog_buffer[1]/analog_count[1];... 2) We only need to make a low pass filtering on the accelerometers, because we want the high frequency response of the gyros. This improves the response of the system.3) Because the delay effect of low pass filtering, I think is better to correct the centrifugal force effects on the raw accel data and then apply the low pass filtering.Also I am thinking on adding a term for correct plane accelarations/decelerations on x axis (need some tests):// Correct accelerometer x axis for plane accelerations/decelerations based on GPS speed...if (GPS_Error == 0){acceleration = (GPS_speed - GPS_speed_old) * 5; // dV/dt = dV*Hz (in my case GPS runs at 5Hz)Accel_Vector_unfiltered[0] += Accel_Scale(acceleration); // x axis accel}4) For centrifugal force correction. Accel_Scale affects the two terms:Accel_Vector_unfiltered[1]+=Accel_Scale(GPS_speed*Omega[2]); // accy += GPS_speed(m/s)*gyro_yaw(rad/s)//Accel_Vector_unfiltered[2]-=Accel_Scale(GPS_speed*Omega[1]); // accz -= GPS_speed*gyro_pitch* The old code also works because of Accel_Scale definition but I think this is more clear...5) Manage GPS errors: We can only use GPS info (speed and course) when he have a good GPS signal. If we lost GPS signal we must remember the last speed info (we need this for centrifugal force corrections) and make no drift corrections using course.6) To think...: Adaptative Kp and Ki for roll and pitch. We can trust more on accel data when it´s magnitude is near g value.This are the code modifications: ADC.pde DCM.pde (note that my sensor configuration is different than arduIMU hardware)On more thing: The execution time of DCM is only 4.25ms on an arduino pro mini atmega328 at 8Mhz!. So there is room for a lot of things on our little machines...I will continue my test flights with this code and post the results...Coments welcome and thanks to Bill and Jordi for share this code and for the porting to arduino...JJ.
Read more…

"World's First Single Chip 3-Axis Digital Gyroscope"

Posted by Angus Peart on October 27, 2009 at 12:30am
Check it out:http://www.prweb.com/releases/2009/10/prweb3108684.htmhttp://www.invensense.com/products/itg_3200.html

gI_0_InvenSenseITG3200.jpg

$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

Huddle Workspace updates and bug fixes

Posted by Chris Anderson on October 26, 2009 at 8:30am
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

More cool micro UAV platforms--monocopter and VTOL

Posted by Chris Anderson on October 26, 2009 at 7:44am
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…

Ublox to nmea converter

Posted by Jesus on October 26, 2009 at 4:44am
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…

Closed loop autopilot simulation with FlightGear - Part 2

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.xml
Read more…
Moderator

AscTec Falcon 8

Posted by Gary Mortimer on October 25, 2009 at 10:24pm

falcon8_1.jpg

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 ;-)

Read more…
3D Robotics

DIY Drones live chat/podcast tonight at 10:30pm PST

Posted by Chris Anderson on October 25, 2009 at 2:56pm
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…

SECRETS OF THE C328

Posted by Jack Crossfire on October 25, 2009 at 4:00am
C328 product page

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…

Remzibi OSD USB to Serial Cable and FTDI cables are interchangeable!

Posted by Paul Mather on October 24, 2009 at 7:30pm
I did some testing this evening with the FTDI cable from DIYDrones, the FTDI cable from SparkFun, the OTI USB to Serial cable from Remzibi's OSD and the Prolific USB to Serial cable that Remzibi is going to start shipping with the OSD's.Turns out the FTDI's can be used to program the OSD and Remzibi's cables can be used to program the ArduPilot (with a little modification).To use the Remzibi cable on the ArduPilot, you'll need to cut off the shrink wrap where the wires go into the silver braided cable and expose the green, brown and orange wires. The orange isn't used (or soldered to anything internally). Use the wiring diagram below.Remzibi_Cable_To_ArduPilot.gifTo use the FTDI cables to program the OSD, you'll only need 4 wires. Use the diagram below.FTDI_OSD_Cable.gif
Read more…