They join Foxteam and will support the improvement of Ardupilot with the other member of Team.
More video and info are avaible here : http://www.virtualrobotix.com/profiles/blogs/pros3-welcome-to-foxteam
All Posts (14056)
Sort by
They join Foxteam and will support the improvement of Ardupilot with the other member of Team.
More video and info are avaible here : http://www.virtualrobotix.com/profiles/blogs/pros3-welcome-to-foxteam
This doozy was spotted by Wired's Danger Room team:
"We’ve featured some seriously over-the-top military patches here in the Danger Room. This one, nabbed by Spencer in Afghanistan, counts as one of the most over-the-toppest.
The emblem is for Task Force ODIN — the team of killer drones, manned spy planes, and intelligence analysts, named after the all-seeing pater familias of the Norse gods. And it’s just what you’d want from an Army-meets-Asgard mashup.
On the patch (from ODIN’s just-departed detachment) an armed drone sails over the head of a blond, bearded warrior, clad in chain mail. “SURRENDER OR DIE!” screams the text along the bottom. But the ironic thing is, ODIN isn’t really in the killing business any more.
During ODIN’s original incarnation, in Iraq, the task force helped bring hundreds of insurgent bombers to an early end. These days, in Afghanistan, ODIN is more in the business of surveillance and intelligence-gathering. Guess “SURRENDER OR WE’LL WATCH YOU FOR A WHILE” wasn’t a catchy enough slogan."
Howard manned the booth at Maker Faire with me for two years, and was the nicest, most patient person you could meet. He had had early success in the technology industry (see obituary below) and this had allowed him to semi-retire in a beautiful part of the world on the Pacific coast south of San Francisco and to focus on what he loved best: his family, surfing and robotics. As tragic as his death was, at least it was doing what he loved: surfing.
Here's the obituary from his local newspaper:
"San Luis Obispo entrepreneur Howard Gordon, a highly regarded innovator known for revolutionizing Internet information processing and robotics, died of a heart attack July 20 at French Hospital Medical Center after surfing at Pismo Beach. He was 57.
According to family, friends and associates, Gordon lived a life propelled by vigorous curiosity and gusto and yet was low-key and unassuming in the face of some of his culture-altering Internet contributions.
Gordon was among the first innovators who made streaming a video or song over the Internet possible when he championed software-based compression for images and audio — MP3.
Want to attach and send a photo on the Internet? It was Gordon and his company, Xing Technology, that wrote very fast JPEG compression software for personal computers in the 1990s. Before Xing, nearly everyone thought special devices were needed to accomplish such data compression.
A graduate of UCLA with degrees in math and music, Gordon played classical piano, flute and guitar, excelled in dressage and was an avid surfer, skateboarder and champion sailboat racer.
Jeff Buckingham, president of Blue Rooster, a San Luis-based telecommunications company, recalled a man “who definitely didn’t stay inside the box. It was a lot of fun watching him with all of his ideas flying around.”
Amy Kardel of Clever Ducks, a computer networking services company in San Luis Obispo, remembered Gordon as “absolutely brilliant and just the neatest guy.”
Born Oct. 10, 1952, in Montebello, east of Los Angeles, and raised in Pomona, Gordon’s interest in computers goes back at least 40 years, long-time friend and collaborator Eric Redemann said.
While the two were college roommates at UC San Diego in the early 1970s, Redemann recalled, Gordon took a summer job on campus that entailed making a technical, animated film using the university’s number-crunching computer center.
Prior to microprocessors, computer centers at that time were usually huge buildings holding vast banks of computers with long waiting lists for users.
Redemann said Gordon figured he could get exclusive time on the computers if he worked all weekend and let the other students have access during the week.
“So he did the summer job on weekends, which was something like 40 days of work in six all-nighters,” Redemann said, “got good marks for his work and was able to surf and play music during the rest of the week.”
It was also during this time that, with his father, Gordon developed computer models and playing strategies for blackjack. He developed computer-based trading models dealing with stock options and financial futures for the Wall Street firm of the then-Shearson Lehman Brothers and large-scale computerized telephone systems using microprocessors.
By 1982, he founded Network Research Corp., a computer-networking firm. He sold that company four years later and — with a love for dressage — founded Classical Horseman, a mail-order business dealing with dressage training videos. In the interim, he and wife Heidi Carr moved from Malibu to Arroyo Grande, where he based the business.
Gordon founded Xing in 1991 as a robotics and video tracking system company. Before selling the firm in 1997, his company was a leader in the Internet-altering software of JPEGs and MPEGs, allowing images to be compressed and sent online.
Technology was but one facet of Gordon’s life. Jack Smith recalled meeting him one weekend in 2001 (the same year Gordon and Jay Crum set the Transpac record for double-handed sailing from California to Hawaii) while Smith was staging the International Slalom Skateboard Races in Morro Bay.
With typical Gordon brio, he jumped into the sport. Under Smith’s initial direction, Gordon eventually partnered with skateboard legend Bobby Turner and co-founded Turner Downhill. Under Gordon’s direction, the company completely revamped competitive downhill skateboarding by redesigning boards and wheels that dominated world championship racing.
One of his greatest sources of pride in this venture is that his daughter Lauren — now 21 and a geological engineering student at the University of Montana — and son Dylan — now 18 and a visual journalism major at Brooks Institute in Santa Barbara — both became world champion slalom skateboard racers several years in a row — traveling to events throughout the United States and Switzerland.
“He was one of the smartest guys I’ve ever known,” Smith said. “Yet, with all he accomplished, he was also one of the most down-to-earth; a Polo shirt and shorts were his uniform. He enjoyed life to the fullest.”
For the past 12 years, Gordon owned and operated Surveyor Corp. from the family’s La Lomita Ranch in Edna Valley.
Surveyor Corp. is a high-tech company that deals with one of Gordon’s abiding loves: robotics and their applications. Toward that end, his curiosity and gusto were directed toward taking humans past what we know now.
“It’s sometimes hard to pinpoint a man’s impact on his community,” said Tim Williams, owner of Digital West of San Luis Obispo. “When considering Howard Gordon, it’s much more visible. His contribution to the technology world was global and, in many ways, he put San Luis Obispo on the map. His leadership drew the attention of giants in the tech industry, and he did so without limitations here in San Luis Obispo County.
“It wasn’t easy,” Williams added, “to be a major technology player from this somewhat remote region, but the very idea of doing more with less was part of the concept behind every technology application that Gordon built.”
“He had a reputation for creating and building companies and being able to sell them,” Kardel added. “But at the heart of Howard Gordon, he was a good guy who cared about what really matters — not just the integrity of products but also his family and community.”
Gordon is survived by his wife, Heidi Carr, of San Luis Obispo; daughter, Lauren Gordon, and son, Dylan Gordon; and brother, Mitchell Gordon, of Northern California.
No memorial services are planned.
Now have Windows XP running on RoBoard, can write programs on my main workstation using Visual Studio which is great because it's what I've been using for the last 15 years.
Two tips for success with RoBoard in such an environment for anybody who might want to try:
1. If you get RB-100, don't bother buying a USB floppy to load the RB-100's IDE driver. You want to use nLite to make your modified XP install CD per the posts on RoboSavy.com. It's free, it works, and with it, you can strip down your XP install to use only the minimal stuff you need.
2. The RoBoard docs say you can put the winio files either in your application directory, or in windows\system32. I put them in windows\system32 and wasted a day because the winio library initialization failed. Eventually I tried putting them in the application directory, and it worked fine.
Next step... See if I can get RoBoard talking to APM.
The Robots podcast had a great interview this week with Raymond Oung from the Swiss Federal Institute of Technology in Zürich.
"The idea behind this project is to design a set of vehicles equipped with a single propeller and wheels that can drive around in search for fellow modules with whom to dock. Single modules are not stable but once assembled, the flight array is able to take-off and achieve coordinated flight. Modules then detach in-air, fall to the floor and repeat their search for other propellers.
The main challenge in this system is to come up with a distributed controller that can allow modules to work together to achieve coordinated flight. Because of its endless number of configurations, the distributed flight array is the perfect research and pedagogical testbed to study control theory for complex systems."
You may wonder why the world needs Yet-Another-Ground-Control-Station (YAGCS).
The following design goals, which are highly subjective, came to my mind when I started to work on this little project:
- If somehow possible, a GCS should not rely on libraries or tools whose distribution is limited for reasons such as a) operating system or b) commercial distribution or license issues
- A suitable GCS should be able to present the relevant data as simple as possible; rather than including the latest bells and whistles (realistic cockpit instruments, audio, etc.) the data should be presented in a comprehensible form
- The GCS should be as platform independent as possible (i.e., not be Windows-only)
I consider Labview, Flash and Google Earth to be tools/libraries that fall into the first category. Although there is nothing wrong with them since they are are nice and may be very suitable for this application, (in my very personal opinion) I believe that relying on such interfaces bring problems with them (incompatibilities with different versions, operating systems, etc.).
The current prototype of YAGCS relies on QT, OpenGL and a plotting library which is available as open source. QT was chosen due to it's nice signal-slot framework. So far it only understands the text-based telemetry stream that is generated by Jason's APM telemetry stream. The position of the UAV is continuously displayed on the map (previously generated from Google map tiles) and data in the plotting tab is updated. A logfile is also created, which can be used to later replay a flight (rewind and fast-forward are supported). An earlier version supports camera data received via a UDP socket and the current version shows roll/pitch data in a the OpenGL widget. This 3d view could later be extended to show the orientation of the plane relative to the next waypoint, etc. The plane model looks pretty crappy at the moment since I'm bad at modeling.
I would be interested in any feedback. Once I get the code cleaned up I would be also willing to share it if anybody is interested. Since I'm developing it on a linux (Ubuntu) machine I'm not quite sure what would be required to compile it on Windows but it should not be a bigger problem (the few lines of C code to access the serial port would need to be rewritten though).
Cheers, Andre
Auto Launch in 2.7 from Jason Short on Vimeo.
This is always a cross your finger moment. Chris offered to flight test the new auto-launch code which has never been flown before outside of Xplane. I think I heard him say something like 'well this is an old plane and I've landed it in the bay a few times so I guess we should try...'
The winds were pretty heavy, but the auto heading hold worked nicely.
This is a Blog I decided to start chronicling my experience in the hopes that I might make it easier for newcomers to get involved with these amazing machines we call UAVs!
First let me tell you a little about myself. I live in the Adirondack Mountains of upstate New York, in the United States. I'm shown above with my new Senior Telemaster. (Anyone who has followed any of my posts knows the lengths I have gone to to obtain this plane. That's another story!) I am a Network Administrator with a Composites Manufacturer providing Manufacturing capabilities to medical, industrial, and recreational vendors. I have a background in CAD, and CNC Machining. I have had a lifelong love of aviation since I was a small boy growing up in the suburbs of Boston Massachusetts I have always had an interest in electronics, computer programming, and model aviation. First came Radio Control.in about 1989 I started flying a Great Planes PT-40 I purchased at the local hobby shop. Next came an introduction to robotics about 2 years ago with a kit my son got of the Parallax BOE-BOT. This led me to the Arduino platform. Then last January my brother-in-law (a really good guy) gave me a gift certificate to Sparkfun for my birthday! When browsing Sparkfun's web store I came across the ArduPilot, the rest is my experience chronicled here.
First lets talk about my choice of airframe. I wanted a large, stable platform, with a large interior. My "mission" was aerial photography/videography, OK lets face it really I just want to have fun! Anyway , you need to look at what you want to do with your project when deciding on the proper plane to purchase. If you are looking to burn holes in the sky, then a high wing trainer isn't a good choice; if however you want a gentle stable flyer to take aerial photos (as I did) then a high wing trainer is a good choice Many people here like the Multiplex Easystar. The choice is yours but take some time and decide what your "mission profile" is and then seek the advice of others if you aren't familiar with a particular model. While I'm talking about the airframe let me make a basic recommendation, when we all learned to ride a bike, we didn't hope on a 10 speed and just take off down the street never looking back. Rather we started with a beginners bike, and training wheels.If you haven't flown Radio Control before, do yourself a favor and contact your local club and find yourself an instructor. You'll be glad you did!
Shown in the picture above are the two main boards of the ArduPilot system. On the left is the ArduPilot board on the left, and the ArduIMU+ V2. The ArduPilot is the "brain" of the system that integrates all the sensor data, from sensors such as the ArduIMU, and what output is necessary to obtain the desired performance from the aircraft. The IMU is an option as opposed to using thermopiles. Both systems monitor the attitude of the aircraft by sensing the aircraft' orientation in space. The sense I got was that the IMU provided better stability than the thermopiles in mountainous terrain (such as where I live).
. Shown here to the left is the uBlox GPS module.
This module has proven to be very popular, and in my experience very easy to work with. If you've spent any
time reading threads around here you'll probably realize
it does have a few weak points, the antenna connection
is very fragile; so care must be taken to make sure to protect it. The connector on the back of the module is
also very fragile so care should be taken with it as well.
You can see the uBlox adapter, sold at the DIY drones
store, hidden behind the uBlox module. I would suggest using some hot-glue to hold the two parts firmly
together.
Crash protection is highly recommended with this very fragile item. I have heard several methods of protection, including shrink wrapping the parts together, However I have also heard reports of reduced numbers of satellites
obtaining a lock as the temperature rises, so it's important now to insulate it too well.
There are a several supported brands and communications protocols to choose from. With a wide range of features and a wide range of price as well Another important thing to consider is sampling rate, most GPS units come with sampling rates in the 1Hz to 10Hz range. At the low end 1Hz, a slow moving RC car might be able to use a sampling rate this low, but it's not very practical for a plane, at the 10Hz end you could have good data for a fast moving plane. For me 4Hz was great for a slow flying high wing trainer. The choice yours.
No matter what hardware you have, you'll need to consider how to mount them in your airframe. I wanted to have a system I could adjust.
The ArduIMU needs to be parallel to the ground in level flight. Unfortunately it's not easy to calculate exactly where that will be without some actual flight testing. Most planes will fly at a slightly positive AoA (Angle of Attack), therefore the ArduIMU would need to be mounted at an equivalent NEGATIVE angle in order to be parallel to the ground.
The picture on the left shows the installation of my mounting system in my Senior Telemaster. At the back you can see a long strip of Velcro, this acts as a hinge for the plate to pivot on. The 4 Velcro tabs are to attach the removable AP system panel from the mounting plate. The socket head cap screw at the front of the mounting board allows the adjustment of the pitch, positive or negative, of the mount.
While not necessary to make an adjustable mount I think it will allow me some greater degree of precision. If you are using something like a Multiplex EasyStar, it wouldn't make sense to go with something this elaborate.
This picture above shows how I protected my uBlox module with a foam cradle. Notice the cable connected to the uBlox adapter, it goes AFT to the main payload bay where it is connected to the ArduIMU.
The picture below shows the assembly after it was slid in place between the battery tunnel and the fuselage side.
This picture shows the battery monitor adapter, and associated cable I made to attach to the battery monitor on the Ardu Shield V2. If your not going to use the optional telemetry you can ignore this item, as it's unnecessary.
Because I am using a 6s1p LiPo battery pack whose nominal pack voltage is 22.2 volts, well over the 15 volt maximum input to the Ardu Shield V2 board, I needed a way to modify reduce the voltage "seen" by the analog input (AN5).
The battery monitor circuit on the Ardu Shield V2, uses a voltage divider to drop the voltage down to a value AN5 can read without causing damage to the board. Using the formula: Vout = (R1 / (R2 + R1 + "X") * Vin, I was able to determine the value of "X" necessary to bring the voltage down to 5 volts. For me that was 164k ohms. This is only necessary if you are using a voltage greater than 15 volts at full charge. Always calculate based on the full maximum charge, not the nominal rated voltage.
In this picture I've added the Ardu Shield V2. This enables us to add the differential pressure sensor (black box in the middle on the left) for airspeed sensing, and the battery monitoring capability with the voltage divider. It simply rests atop the ArduPilot board. I haven't installed the pitot tubes yet, but the will go out on the wing at least one prop diameter out on the wing. It's important to note here that you should install both the active and the static tubes outside the airframe, and out of the disturbed airflow behind the prop. If you are using a pusher such as with the Multiplex EasyStar you can simply install these in the nose of the aircraft.
Many people using fast moving airframes with IMUs don't bother using the airspeed sensor, however in slow moving airframes, or airframes that fly near stall speed, the Ardu Shield is recommended.
Here in the picture on the left you can see the ArduIMU on the left, the ArduPilot (red board) on the right, and the Ardu Shield on top of the ArduPilot.
They are all isolated from vibration using two different types of foam. You can see a 1/4" thick layer of neoprene foam on the bottom, and a 3/4" pocketed closed cell blue packing foam.
The idea is that the different foam densities protect the electronics from vibration at different frequencies.That's the idea at least, we'll see how well it works in practice.
At the top of the payload bay you can see the battery monitor cable coming from the forward compartment visible at the top of the photograph. Towards the front on the right hand side, you can see where the momentary push-button reset switch is installed through the fuselage side.
This picture shows how the adjustable mount is used to level the cradle the IMU is mounted in. First I check to see that the wing saddle is
level, then I move the level to the cradle, and adjust the mount to
bring the mount level with the wing saddle.
Well, that's it for now! In Part Two, I'll install the pitot tube in the wing, load the code, run through some ground tests, and finally begin some flight testing!
Good luck with all your projects,
Nathaniel
.
But this time, GPS dropped from 9 to 7 satellites in a roll, causing her to fly into the sun. This module dates from when patch antennas were the gold standard & no-one knew omnidirectional antennas were required. Also note we didn't have the standby power cable, so GPS reset during battery changes.
There's the sudden trademark S-N shift of a GPS glitch.
Noted with the A480:
1) Auto exposure is disabled in continuous shooting mode.
2) GPS Patch antennas are going away for a reason. We've done everything possible with the patch, but angles of attack in the wind are too steep.
Another camera joins the crash graveyard.
That brings this flight to
battery: $100
camera: $100
GPS: $50
Props: $6
Just going to keep driving to Sunnyvale & repeating the mission until it works. It seems to be the unique weather.
Now the low bandwidth preview cam was the only thing that got some video.
Then, started thinking about re-enabling the accelerometer. 3 DOF IMU flight was intended for indoor vehicles. It worked real well & it felt more like a space program, so it got used for everything. The problem is the angle of attack is too steep & GPS too slow to get fast turns or tight hovers. Also want an attitude hold mode.
Finally, started thinking again about upgrading to the mighty rangevideo system. Analog video is so ancient & capturing it is so expensive, it's not really worth it. Despite being over 10 years old, 802.11 video is still insanely expensive & there is no digital 900Mhz video.
2 UAV versions.
V tail version and T tail version
See more about the Mugin UAV platform
Test flight
Still "Low cost" platform made in light wood and Alu. I know it's a big ship and Weight are getting close to maximum without special license.
The platform are still in testing - When I have some video documentation I will post.
Wingspan 3 meter.
Motor Twin 53 CC
Mugin UAV platform will soon also be available with T tail.
Source (Dutch): http://www.geenstijl.nl/mt/archieven...iegtuigje.html
Translate with Google: http://translate.googleusercontent.c...3yaqQ7Sj-MXRaA
Specifications: http://rabbit-hole.org/
Defcon interview: http://revision3.com/hak5/defcon18
I was messing around with my simulator some time ago, and found that the ground course, returned from the binary GPS decoder, in GPS_EM406.pde returned false heading between 300 and 360 degrees. This is also mentioned in the comment.
The problem is that the number returned from the GPS module is returned times 100, as the comment suggest, this means values between 0 and 36000.
if(ground_speed >= 50){
//Only updates data if we are really moving...
intUnion.byte[1] = gps_buffer[j++];
intUnion.byte[0] = gps_buffer[j++];
ground_course = intUnion.word; // degrees * 100
ground_course = abs(ground_course);//The GPS has a BUG sometimes give you the correct value but negative, weird!!
}else{
Since the integer used in the intUnion is a 16 bit signed integer, only numbers up to 32768 is supported, this fact yields negative values when the value is above, from the bit pattern interpretation.
The solution is to use the longUnion instead of the intUnion. This solves the buggy ground course.
if(ground_speed >= 50){
//Only updates data if we are really moving...
longUnion.byte[1] = gps_buffer[j++];
longUnion.byte[0] = gps_buffer[j++];
ground_course = longUnion.dword; // degrees * 100
//ground_course = abs(ground_course); //The GPS has a BUG sometimes give you the correct value but negative, weird!!
}else{
I hope that this helps somebody.
Best regards
Niklas
Geof Barrows of Centeye sent me some raw sensors so I can develop for them. These are great sensors due to inpart there flexibility, low external part count (you can see the board has two capacitors), and the use of chip on board technology. They are fairly easy to use.
As of right now, I am able to read the image in log mode. Once I get a lens, then I can start some image processing code. First full image (8 bit greyscale):
I am streaming pixel data via a wireless modem as the USB connection on the XMOS is VERY slow, limiting the frame rate I can use it at. I am grabbing one frame in around 32 milliseconds, but I should be able to bring that down with tuning of delay values. The whole image only takes 32K RAM, meaning I can work with the whole image, and have 32K RAM for processing capabilities. Final plan consists of a scalable architecture with add on modules to support any number of sensors. The sensors will be trained via IMU.
In the world of IMU's, I ordered another board as the other was messed up beyond recovery (port mappings). I also messed up this time (Flipped two ports...), but it is usable.
I am using Bill's DCM algorithm, and I need to tune the PI values. Current output isn't very usable:
10,000 points:
We've changed the channel that reads the throttle on basic ArduPilot from pin 13 to pin 11. That's because pin 13 shares an LED, and it's causing problems with some low-voltage RC receivers. Pin 11 is clean.
The above picture shows the correct jumper wire configuration. If you've been using pin 13, please switch it to pin 11.
In the code, you tell ArduPilot which pin you're using with this line:
//3-1
#define THROTTLE_PIN 11 // pin 13, or pin 11 only (13 was old default, 11 is a better choice for most people)
Sorry about this messiness, but it's all in the service of extracting as much utility as possible out of the basic ArduPilot board (which was originally designed not to control the throttle at all--those were simpler days!). Later this year we'll release a new version of the ArduPilot board which will clean up everything nicely (same features, so nobody will be left behind), but for now, please whip out your soldering iron and switch the jumper.
The manual has been updated with the new instructions.
Jani sent over some pictures of the first beta ArduCopter retail units going out to the dev team. Yes, the dev team is that big now!
We'll announce pricing, package options, pre-ordering procedures and final specs within the month. I'm guessing that we'll be able to start shipping retail units by the end of September. We want to make sure that the code is pretty bulletproof, so the contents of those boxes will have to do a lot of flying between now and then!
Initially, we will be selling via our affiliate, PhiFUN (note: that site is not ready for ordering yet. Ignore the preorder offer for now--it doesn't work yet!) and directly via the DIY Drones store.
Please understand that ArduCopter is a full UAV, not a RC toy, so we have to comply with export and other regulations. So, for example. sales via the DIY Drones store may be US-only and require compliance with a no-export agreement. For those outside the US, PhiFUN will be the primary distributor, although we'll be looking for a European partner, too.
It's here! The first beta of the retail ArduCopter frame arrived today, and it's GORGEOUS. Jani has totally outdone himself. Above is the box, which is surprisingly small--just 13" x 4.5". Nice label, tells you what's inside. (This box is just the frame. If you'd ordered the other bits, such as the APM autopilot, GPS, motors, ESCs and props, they would have come in smaller boxes, and they'd all be packed up in one bigger box.)
Everything fits in really neatly.
Here all the parts are laid out. Each subsystem is in its own sealed bag, labeled and numbered.
An example of one bag: the power distribution PCB. Front...
...and back.
An example of the CNC'd parts. Love the little touches, like the name etched in the dome components.
Parts list
Introductory instructions. Full instructions are online.
Stickers!
Next steps: the beta testers are going to build and fly the quads with the latest software. Based on that feedback, we'll finish the documentation and decide on a release candidate of the code, and burn that into the boards. Jani will stock up on a LOT of the component parts, including motors, ESCs and props, and we'll announce a release date and prices for all of the versions, from just the frame to a complete ArduCopter UAV kit with everything included.
Totally thrilling. This project has been a long time in development, starting with the original ArduPilot board, and it's really gratifying to see it hit commercial maturity like this. Jani, you're a star!
Some quickie shots from my phone, along with first impressions. Above, the cardboard inner box. Same basic setup as the prototype: an indoors protective foam ring body, and a second (yellow/orange) smaller body for outdoors. No other big changes that I can see. Same brushless motors, cameras, props.
I see that DANGER is part of the selling point (that explains these obnoxious promotional videos. There's a little skull in the logo at the center there...
Awww. The cover over the electronics is now opaque. You can't see the gorgeous circuit board and chips :-(
Thankfully, they've fixed the motor wires. Those were the #1 point of failure on the prototype. Now they've got a proper connector and are tucked away nicely.
Also, no silly rubber feet like the ones that kept falling off on the prototype.
When I get my iPhone charged up, I'll try the software.
I get the whole cheeky viral video thing, but this one from the Parrot AR.Drone team just seems obnoxious and irresponsible. Or am I just being over-sensitive?
Speaking of the AR.Drone, my production version just arrived. I'll add unboxing pictures in a few...[Update: here]
UPDATE: There's a second one, even worse. Now they're tormenting animals:
UPDATE: There's a second one, even worse. Now they're tormenting animals:
