Blogs

All Posts (14048)

Sort by

Interfacing MATLAB and Arduino

Posted by Kostas Alexis on December 1, 2009 at 6:56am
Hi friends!I have just found and tested a Blockset that interfaces MATLAB/SIMULINK and Arduino. You may find this at:http://www.mathworks.com/matlabcentral/fileexchange/24675-arduino-targetI highly suggest this program since it offers rapid prototyping capabilities to the famous and cheap arduino. The guys have build a block that interfaces with the Real Time Workshop of MATLAB and have also implemented C functions for all arduino operations (analog in, out, serial read/write etc.). Despite the fact that the code is obviously bigger one can gain advantage from the quick and abstract way of programming that simulink offers. It is a good work!Happy coding!
Read more…
3D Robotics

Does open source undermine innovation?

Posted by Chris Anderson on November 30, 2009 at 5:30pm
Krzysztof "Chris" Bosak made some important and interesting points regarding the effect of open source on the overall health of the industry in a comment on another thread yesterday, and I thought they deserved to be discussed more fully (although there are many good comments in that thread, and I'd encourage you to check out that, too). So I'll give them their own thread, starting with my own thoughts. First, here are some key points from Krzysztof's post: "Marketing that you can make Ardupilot for $25, $50, $100 is like making the others look like the monsters of greed, while declaring the work of software developer is worth NULL, while not necessarily leading to the creation of competitive product in the long term." All this has one effect: creates artificially crafted virtual reference point for price,that is used to dramatically weaken the public perception or the makers of complex electronics, without even making the makers of cheap solutions incredibly rich. At the end there is no progress, as the advance of open source is usually quickly swamped by absence of professional regression testing and all the things nobody would do for free." At the same time, I noticed a New York Times article today that suggest that almost nobody has found a successful business model for open source. Together, these raise the question of whether open source does more harm than good to innovation, and whether it will ultimately lead to a sustainable industrial model for consumers and developers alike. Needless to say, I believe that the open source development model, while not perfect, is the best one for overall innovation. But Krzysztof raises some valid concerns, which I'll tackle one by one: 1) Claims by open source developers about features and pricing tend to be unrealistic and serve to kill demand for higher-priced commercial products. I think there's some truth to this. Because open source development is done, by definition, in public, there is a lot of discussion about the broad ambitions of the project in the early stages, both to attract participation and to define the broad scope of the project. Not everything an open source project sets out to do is ultimately achieved, as the developers get into the hard work of executing. In contrast, commercial projects are usually developed in private and only revealed when the feature set is pretty much confirmed. The consequence of this is that the entry of an ambitious open source project can "freeze the market" while people wait to see if they can deliver. This is not good for the more cautious commercial players in that space. As for pricing, open source hardware projects tend to be on the far low end, due to a general philosophy (which I share) not to charge for intellectual property. Our own policy is to charge 2.6 times the cost of the hardware (this allows one 40% margin for us and another 40% margin for our retail partners), but some other open source hardware companies charge just 1.5x cost. It's very hard for those who charge for intellectual property to compete with these prices. 2) Open source tends to "de-monitize" a market, eliminating the potential for anyone to make money. In the short term, this can certainly seem to be the case. But if you believe in demand elasticity, as I do, you would expect the lower price to vastly increase demand, growing the market for all. So it's a tradeoff between high margins and high volume. In the case of ArduPilot, where the core board costs just $25 (something Krzysztof objects to, because it sets a consumer expectation that autopilots should be very cheap), we have sold about 2,000 boards this year, which makes it the best-selling amateur-level autopilot in the world by a wide margin. Although nobody make much money from those boards, the economic value around all the other parts you need to create an functioning autopilot is significant. Say there are now 500 complete ArduPilot systems out there now. That's about $800,000 in total spending (between us and our partners). Assume total margins (between wholesale and retail) are around 50%, that means $400,000 of profit in the first year. I suspect that's more than any of the commercial autopilot companies in this space can claim. Because you're charging for "atoms", not bits, open source hardware can be profitable in the way that open source software cannot, because the customer relationship starts with the assumption of paying for something. 3) Open source can't create products of equal quality to closed source, because nobody's getting rich. I think that Firefox, Linux and MySQL users would disagree with this, as would I. It's true that many open source project never achieve professional-quality polish, but that's mostly an issue of poor project management and leadership. I think you only have to look at the work HappyKillmore did on the ArduPilot configuration utility, or how Mike Black improved our GCS to see this: I'd argue that both are better than any of the ground station and configuration utilities from the commercial players in our space (and some, including Flexipilot, don't have groundstations at all). Note that these contributions were made not because someone was getting paid, but because the contributors had their own reasons to want better software. And because we set an open source standard, they chose to share their work so that others could build on it. So, to sum up: I understand why commercial developers dislike the entry of an open source project into their market and hope it will fail. But the trend lines are clear on this one: open source is here to stay and is spreading, mostly because it leads to more, cheaper products faster. ArduPilot, for example. went from concept to maturity (with the 2.5 code, now in the hands of beta testers) in a year, including a full suite of supporting tools. There is no commercial autopilot that has come close to that speed of development. And as the DIY Drones community grows and our tools of group development improve, we are extending that to a host of new products created by the members here. To hire this many engineers would be ruinous, but by creating a community of shared interest and a culture of collaboration, we can do so at almost no cost at all. It's really quite magical. Can commercial companies compete with this? I think they can, by offering more "plug and play" solutions, as Krzysztof has done with EasyUAV. Don't try to sell expensive apples to compete with our cheap apples; instead, sell oranges, with shiny bows on top. There's a market for both, and I think commercial developers would do well to find ways to do things that open source can't or don't do well, rather than just wishing that we'd go away.
Read more…

Shrediquette open source tricopter

Posted by Howard Gordon on November 30, 2009 at 11:31am

Tricopter - The Movie... from W. Thielicke on Vimeo.

From http://www.lecun.org/blog/index.php?entry=entry091130-130224..."The Shrediquette is a tri-rotor helicopter built by William Thielike from Germany. William is a PhD student in biology, who seems to have many talents: micro-controller system design, control, mechanical design, flying contraption construction, as well as film making.His tricopter is built around an Arduino Pro Mini micro-controller. Oddly, William didn't use the Arduino development tool and C/C++ programming language: he wrote his software in Bascom, a dialect of BASIC.The yaw control is performed by rotating the tail boom with a servo. This very unlike the more conventional servo-less yaw control of quadcopters, but it's practically unavoidable for tricopters.Much of the material is available for download, including the schematics, the PC board Eagle files, and the Bascom source code."
Read more…

Outback Challenge - Who's up for a run??

Posted by Scott Plunkett on November 30, 2009 at 9:43am
So some time has passed, and I have a nagging in the back of my mind - why couldn't we field an Outback Challenge Team? We are already working on several projects, and combined we have a PILE of UAS time in the air. We could even purpose-design the entire system; airframe, autopilot, all of it from ongoing projects or designs here on DIYDRONES. I have no doubt we could raise a little money and could field a competitive team. I know we are spread all over the world, and that this is all OpenSource...but what better way to prove that this type of collaboration really can produce world-class results.Sooo...who's in?? Seriously, I'm in - and looking for compatriats!
Read more…

Beginner with $650

Posted by Giles Barton-Owen on November 29, 2009 at 3:09am
My aim is to make a simple Ardupilot setup on a EasyStar for strictly £400 or $650 (but shipping is expensive globally as I'm in the UK). I have the Fidi programmer and reasonable Arduino experience so thats not a problem but I want to know, for instance whether the 4Hz GPS is worth the extra $100 etc. (I already have the 32 Channel LS20031 GPS 5Hz Receiver carried by sparkfun) and a Spectrum DX5e w/ receiver.Any mods to the EasyStar worth doing to start with? (I can get it for £80 inc. delivery)I know that its probably covered else where but not all in one place.Any comments would be much obliged.
Read more…

Exploitation of a Unique VTOL UAV Concept – Feedback Please!

Posted by Ashley BRYANT on November 29, 2009 at 1:14am
We are developing a unique, patented VTOL [Vertical Take-Off & Landing], UAV [Unmanned Aerial Vehicle] specifically targeted at urban, mountainous and maritime environments. Full details of the concept and business case can be found in a slide presentation under the SlideShare section of my LinkedIn profile… http://www.linkedin.com/in/ashleycbryant. There is also a video which can again be accessed from my LinkedIn profile or from You Tube with the following url… https://www.youtube.com/watch?v=4mmFas3jsgIWe secured a high level of interest from the UK MOD on this exciting concept. However, the devastating effects of the credit crunch have impacted the UK governments’ ability to further invest in this technology at present. As a consequence, we are therefore looking to license this technology and/or partner with a larger industry player. If you have any thoughts therefore as to where we should be directing our efforts for future project funding and any advice on key investor contacts who may have an interest investing in this technology, whether government or commercial, you views and advice would be appreciated.
Read more…

GPS Emulator Now Outputs uBlox and NMEA sentences

Posted by Paul Mather on November 28, 2009 at 11:30pm
uBlox_u-Center.gifThe GPS Emulator v1.2.0 that's part of Remzibi's OSD Configuration software now supports uBlox emulation. It has the option to enable NAV-VELNED, NAV-POSLLH and NAV-STATUS (which are the 3 messages ArduPilot uses for positioning).ConfigTool.zip <- Includes GPS Emulator v1.2.4EDIT: Here are all the sentences the emulator currently supportsNMEA$GPRMC - Recommended Minimum Specific GPS/TRANSIT Data$GPGGA - Global Positioning System Fix Data$GPGLL - Geographic Position, Latitude/Longitude$GPVTG - Track Made Good and Ground Speed$GPZDA - UTC Date / Time and Local Time Zone Offset$GPGSA - GPS DOP and Active Satellites$GPGSV - GPS Satellites in ViewuBloxNAV-VELNED - Velocity, Speed and Heading in LLANAV-POSLLH - Latitude, Longitude and AltitudeNAV-STATUS - GPS Fix and DGPS statusNAV-SVINFO - Satellite DetailNAV-SOL - GPS Fix, Latitude, Longitude and Altitude in ECEF and Velocities in ECEFNAV-DOP - Dillution of PrecisionNAV-POSECEF - Latitude, Longitude and Altitude in ECEFNAV-VELECEF - Velocity in ECEFNAV-CLOCK - Clock Solution (not sure why you'd use this)NAV-TIMEGPS - GPS Clock InformationNAV-TIMEUTC - Full UTC Time/Date InformationSample Output*** uBlox 12/2/2009 4:41:50 PM = UTC: 214150.296 ***NAV-VELNED : B5 62 01 12 24 00 58 F2 1A 14 FC 06 00 00 00 00 00 00 00 00 00 00 FC 06 00 00 FC 06 00 00 00 00 00 00 11 01 00 00 00 51 25 02 3F 00NAV-POSLLH : B5 62 01 02 1C 00 58 F2 1A 14 B0 4D A1 CF AC D5 1F 1D E0 93 04 00 E0 93 04 00 06 17 00 00 3C 24 00 00 2C F5NAV-STATUS : B5 62 01 03 10 00 58 F2 1A 14 03 DD 00 00 C4 05 00 00 1D 83 00 00 D5 6ENAV-SVINFO : B5 62 01 30 C8 00 58 F2 1A 14 10 01 00 00 00 04 0D 04 10 48 05 00 D6 FB FF FF 01 0A 0D 07 28 56 5A 01 BF FF FF FF 02 0D 0D 07 20 52 E6 00 FC 02 00 00 03 17 0D 07 32 57 48 00 07 02 00 00 04 12 0D 04 14 29 59 01 5F FF FF FF 05 19 0D 04 13 2B 0E 00 0A 01 00 00 06 0B 0D 07 1A 58 DF 00 24 02 00 00 07 0E 0D 04 0C 16 0C 00 61 FD FF FF 08 20 0D 07 22 59 35 01 65 02 00 00 09 05 00 01 00 1A 46 00 25 00 00 00 0A 18 04 03 09 0A 95 00 2D 00 00 00 0B 14 0D 07 1A 43 AD 00 50 FE FF FF 0C 06 0D 04 15 40 39 00 9A 01 00 00 0D 10 0D 04 19 2E 62 01 FC 00 00 00 0E 1D 0D 04 10 44 74 00 82 FC FF FF 0F 07 0D 04 12 4B C2 00 DD FB FF FF 0F 08NAV-SOL : B5 62 01 06 34 00 58 F2 1A 14 25 D0 FD 01 18 06 03 DD CA CD DA 03 F8 51 3D E7 CF D5 7E 1C EC 04 00 00 FC 06 00 00 00 00 00 00 00 00 00 00 36 01 00 00 DC 00 00 10 42 49 00 00 63 51NAV-DOP : B5 62 01 04 12 00 58 F2 1A 14 C7 00 DB 00 61 00 B5 00 5C 00 49 00 3C 00 28 3CNAV-POSECEF: B5 62 01 01 14 00 58 F2 1A 14 CA CD DA 03 F8 51 3D E7 CF D5 7E 1C E2 04 00 00 93 96NAV-VELECEF: B5 62 01 11 14 00 58 F2 1A 14 FC 06 00 00 00 00 00 00 00 00 00 00 18 01 00 00 B9 D2NAV-CLOCK : B5 62 01 22 14 00 58 F2 1A 14 EF 74 FF FF 4A 00 00 00 0B 00 00 00 5E 06 00 00 C9 D7NAV-TIMEGPS: B5 62 01 20 10 00 58 F2 1A 14 D6 AF 13 01 18 06 0F 07 0D 00 00 00 83 A1NAV-TIMEUTC: B5 62 01 21 14 00 58 F2 1A 14 0D 00 00 00 F0 2B 8D 02 D9 07 0C 02 15 29 32 07 CA C7*** NMEA 12/2/2009 4:41:50 PM = UTC: 214150.296 ***$GPRMC,214150.296,A,4851.7535,N,08109.0744,W,34.8,0,021209,003.1,W*46$GPGGA,214150.296,4851.7535,N,08109.0744,W,1,16,0.9,300,M,0,M,,*76$GPGLL,4851.7535,N,08109.0744,W,214150.296,A*23$GPVTG,0,T,348,M,34.8,N,64.4,K,A*25$GPZDA,164150.296,02,12,2009,4,0*52$GPGSA,A,3,04,10,13,23,18,25,11,14,32,,24,20,2.21,0.93,1.79*0E$GPGSV,4,1,16,4,72,005,14,10,86,346,41,13,82,230,31,23,87,072,49*4C$GPGSV,4,2,16,18,41,345,21,25,43,014,21,11,88,223,24,14,22,012,12*73$GPGSV,4,3,16,32,89,309,34,5,26,070,0,24,10,149,8,20,67,173,24*41$GPGSV,4,4,16,6,64,057,20,16,46,354,27,29,68,116,15,7,75,194,16*71
Read more…
3D Robotics

ArduIMU+ V2 on sale ($99)!

Posted by Chris Anderson on November 28, 2009 at 6:30am
ArduIMU+ V2 (flat version) is now priced at $99, which is $30 less than its orginal price. It was already the cheapest IMU/AHRS on the market, but no there's no excuse not to get one (or more!) to integrate into your own projects. The current version now has the high-pass filter removed, which was reducing the effeciency of the DCM code in earlier versions--so it's now even better! This is an unbeatable deal ;-)
Read more…
3D Robotics

Dealing with spammers on DIY Drones

Posted by Chris Anderson on November 28, 2009 at 5:00am
Folks, you may have seen that the price of DIY Drones' increasing traffic and Page Rank is that the spammers are now targetting us pretty regularily. As a result, I've had to turn on moderation for blog posts. That means that when you post, it won't show up until a moderator (there are a couple dozen of them) approves it. Hopefully, that will always be within an hour. Sorry for the inconvinence! (This doesn't affect the discussion forum, which the spammers don't seem to target)
Read more…

THIS WEEK IN AEROSPACE

Posted by Jack Crossfire on November 27, 2009 at 6:00pm
BATTLE OF THE C328

So fabricated this board to see if the wrapping wire & radio interference was making the C328 unreliable. It writes all the control codes for the C328 to make it output continuous JPEGs.

Sadly, it's no more reliable than the previous methods. The C328 needs exact baud rates. It can't convert the 115740 from a PIC into 115200. The set baudrate command isn't very reliable either.You're looking at spending tons of money on a crazy 14.7456Mhz crystal or sending all codes including ACKs over XBees. XBees seem to do exact baud rates.

In the end, got rid of the airborne microprocessors & just passed the XBees directly to the C328. Reduced their baud rate to 57600 & increased the C328 package size to 384. The trick is to send data slow enough to not overload the XBees & send the largest packages possible before the C328 crashes. This gives 7 seconds per frame, slightly faster than 115200 & 128 byte packages.The ground XBee is locking up from packet collisions. It needs frequent power cycles. If by some miracle taxes only go up 4% next year, we might have enough dough for crazy crystals.This is our C328 software. It does everything from full control on the ground to full control on the airframe.video.tarTHE MARCY MANEUVERTo conserve battery power, it's basically a 3m/s descent to 33m, 1m/s descent to 10m, & 0.5m/s to ground. The 33m transition lets you descend into your downwash without smashing into the ground. This was the 1st flight using it, a very low nose pitch caused the radio to drop out at a certain high altitude, followed by execution of the Marcy Maneuver to quickly get back down.

Here's the radio graph.

Here's the altitude showing the tapering at 33m.XBEE DIVERSITY BUSTED

Tried making an XBee diversity system. Fortunately it didn't cost anything.

Mocked up with switching circuits.

Switcher thrown in the ground station.

Ground station with dual XBees.

Aircraft with dual XBees.

The switcher. It must use 2N2222 transistors, not 2N3904.Unfortunately, it was a total failure. Each switching circuit worked when tested separately with 1 XBee. With all 4 XBees connected, nothing worked. It also had other problems. It was a ton of extra electronics, wires, stuff that can break. It should really be done on the main board instead of another breakout board. It probably needed another voltage regulator.Even though both XBees were on different frequencies, they probably detected enough power on the channels to back off. There could also be crosstalk in our UART multiplexer.Another problem is to be most effective, each transmitter would need 2 receivers rotated at 90deg, bringing the hardware to 8 Xbees. Since our problem isn't fuselage obstruction but antenna polarity, you probably don't need diversity as much as turnstile antennas, but this requires a quadrature hybrid.Time to "back off" of diversity & look at antenna placement or alternative radios. Merely keeping the antenna unobstructed by anything including foam may be enough.Here is our diversity switcher firmware.diversity.tarGOODBYE XBEETook a roundabout path, but finally got those MRF49XA's to work.

The transmitter.

The receiver.

They do indeed reach all the way across the apartment atleast. These were intended as single chip radio modems for an indoorcopter & super cheap XBee replacements, hopefully without the lockupproblems.The trick is to copy the reference software & ignore the datasheet. Thegame is all about setting a low enough baud rate & a high enough SPIrate so the FIFO's are kept up to date. If the transmit FIFO empties,it transmits 0x00. If the receive FIFO overflows, you drop bytes.The rate at which it fills & empties FIFOs is determined by the baudrate register, DRSREG. Both receiver & transmitter need the same baudrate.All communication can be done with just the SPI interface, ignoring theINT, FINT, FSK pins that the demo uses.To make it run fast, you have to use the extra pins in addition to SPI.Lowering the FSK pin causes SPI to read directly from the receive FIFOinstead of the register memory. The alternative to the FSK pin isreading the RXFIFOREG register.You also need the FINT & the INT pins to know if the receive FIFO hasdata. The alternative to the FINT & INT pins is polling the STSREGregister.It has some odd tricks like how all the registers are 16 bits framed byCS pulses, but for the TXBREG register you can write bytes indefinitelyin a single CS pulse & those bytes are transmitted.It's designed for packet communication. It scans the incoming signalfor a 2 byte start code. Then it begins filling the receieve FIFO withthe incoming signal, including the start code, until you reset the startcode scanner. You can also scan the entire incoming signal yourself.When no transmitter is on, it outputs noise in the FIFO.With pure SPI, no interrupt lines, 6 MIPS microprocessors, & wrapping wire, got 60kbps out of them.This is our firmware, which is supposed to run on the same chip as the flight controller.mrf49xa.tarMORE EXTREME ALTITUDEDid several pirouettes at a very high altitude in a secret country whereit's allowed. These were demos of high altitude capability butpirouetting video is not the reason for doing it. It's for gettingbetter images of M.M. world headquarters.This was higher altitude coverage of the area around M.M's dishes but notas high as the previous video. Made a point of documenting thisland before it was completely developed.

Some secret shots from a secret location.

Read more…

Ardupilot Ground Station 2.6.4 A&B New Look

Posted by Dr Mike Black on November 27, 2009 at 6:30am

Hi All,Been hanging around here for quite a while now and gleaning as much information as i can, maybe its time to give something back.One of the biggest problems we found was that when in the field, its hard to get all the information where you need it, re-sizing all the windows, if you touch the pad, you can lose the window you want, always the GS, hard to find the pointer to bring it back, when you have one eye on the aircraft one eye on this...So this is my attempt..I hope its usefull to you.Please give feedback as to you thoughts and any improvements.GROUND STATION 2.6.4 UPDATE::1024x768 GCS for smaller LaptopsTrue speed indicator updated for greater accuracyYou can set True speed to MPH/KMH (defaults to KMH) & Altitude to Meters/feet (default Meters)Tme Left estimator, a better accuracy with a new gauge. (you need to set Amps FT to what your aircraft draw flat out)Amps / Watts added (again needs to be set up bottom left with your cell count and Mah)Complete colour re-design for ease of view outside, on a sunned out dull laptop.THINGS TO DO:Fix the irritation, when you click the FIND UAV button so that it auto pops to the position, at the mo you have to double click the position in GE then the GS rotates to where it needs to be. STILL NOT FIXEDFlight trackin. STILL NOT FIXEDSorting some innacuracies with Time estimator. BETTERAP Mode being added on 265Enjoy.Try MY Version GE and DONT update it!!!!! this might solve the GE window fro a couple of you guys....I know that GE changes the Callin API about as often as they change underware........so has been a problem fro all integrators...however as i said before in NOT a programmer, 30 years as an aerodynamcist aircraft designer, and 4 years as a military field asset, so please forgive my crude programming.Thanks to the 'Crashing Dutchman' for updating the look and feel.GCS264a Source.zipGCS264a.zip 1024/768 resolutionGCS264b not uploaded yetGoogleEarthWin.exeLV 8.5 or 8.5.1 works available by google search or just in the last line of top of this page : Runtime or8.5 is Here (thanks Morli)Doc.
Read more…