Blogs

All Posts (14054)

Sort by
3D Robotics

New Co-Pilot from FMA

Posted by Chris Anderson on January 24, 2009 at 11:30am

FMA just announced their new Co-Pilot. The main difference appears, along with smaller sensors and all-digital operations, is that it's now part of a wireless onboard communications system that will eventually include other components such as GPS and telemetry. It's controlled with a IR remote control with a LCD display that you hold. Much more expensive, too. Eventually, FMA will be offering a RTL autopilot as part of this package. Here are the details. AVAILABLE SPRING 2009 Complete Package with all Accessories Priced at under $250 USD 1. Stand-alone operation – computer module installs between existing receiver and servos. 2. Micro-size components – Utilizes SMT components and tiny infrared thermopiles reducing the profile of sensor modules by approximately 50% over previous CoPilot models. 3. All new, digital sensor technology – Digital conversion now takes place within the sensor units. Communication between the sensor modules and the CoPilot computer is accomplished on standard, 3 wire servo connectors. The potential for analog noise in any installation is virtually eliminated. 4. Unprecedented Accuracy – As with all previous CoPilot models, the system offers accuracy to 1 degree of the horizon by sensing the temperature variation between the earth and the sky. Just center the control sticks and CoPilot-II will right your model from any attitude in split seconds. 5. The optional Vertical Sensor module forces the system to roll out of inverted to prevent the potential for striking the ground upon low altitude recovery. When installed, the vertical sensor also allows for automatic and continual calibration. 6. Supports all types of radio systems including any spread spectrum radios. 7. Stabilizes up to 4 channels for compatibility with virtually any aircraft configuration including CCPM heli’s, differential or dual ailerons, flapperons 8. Supports high-resolution digital servos as well as analog servos 9. Works in most weather conditions with the exception of heavy rain or severe overcast making it the ideal and affordable solution for radio control enthusiasts. Automatic weather check can be read out on the LCD at any time. 10. Flight Stabilization with a “Natural Flight” Feel – The CoPilot-II now includes “stick priority” as a built-in option to provide a natural flying “feel” when using flight stabilization. Using stick priority, the CoPilot-II is now capable of automatically reducing flight stabilization sensitivity just by moving the stick further away from center. This results in a natural flying experience without sacrificing recovery time. 11. New 3D modes (currently under development) include automatic vertical hover, knife edge, and inverted flight. 12. On/Off remote control can be set up on any type of auxiliary transmitter switch or knob. 13. New “Flight Modes” access allow for setting up different stabilization characteristics on any type of auxiliary transmitter switch or knob. Now it is easy to switch between basic stabilization and 3D modes with the flip of a switch. Learn new aerobatic maneuvers with safety and confidence. 14. Simple to Setup and Operate – Includes streamlined “wireless” user interface for vastly improved and simplified system setup and monitoring. The wireless system which makes this possible is a new technology developed by FMA termed “IRNet”. CoPilot-II is therefore the first IRNet peripheral to be made available by FMA/Revolectrix, but IRNet applications will extend far beyond the CoPilot-II. This means that with the purchase of the Co Pilot II, you are already set up to use any future IRNet peripherals that become available. Items under consideration include GPS integration, on-board watt meter, tachometer, temperature sensor, digital servo matchbox, tools for selecting appropriate electric propulsion components and others. 15. IRNet offers a fresh approach to Controlling and monitoring On-Board Avionics – IRNet consists of a wireless, infrared, 4 button programmer containing a 2-line, 16 character LCD, and a wireless network router. IRNet range is dependent on weather conditions but ranges from 30 to 200 feet, line of sight. The router is mounted in the aircraft and is capable of supporting multiple IRNet compatible devices. Each device on the “network” communicates with the IRNet programmer using a unique address much like the network of computers in your office, but on a smaller scale. Connected IRNet peripherals are represented as separate devices in the programmer, each supporting its own unique menu system. Setting up an IRNet device is as simple as scanning for the device’s welcome screen and answering a series of questions, much like using a television remote. Monitoring system information in real time is as easy as scrolling through the available data screens. Imagine being able to pre-flight check every critical piece of electronics in your aircraft prior to takeoff, and all without having to bend down and remove a wing or even plug in a wire.
Read more…

quadrocopter

Posted by quix-fz on January 23, 2009 at 8:30pm
a few weeks ago i decided to build a quadrocopter. this would be a real challange but still inside the capabilities of the pcb i made. i actually designed it with plane-uavs in mind. but there's no reason it wont be able to controll a quadrotor.here's the finished board connected to a display. the display i a cheapo 128x64 graphics lcd controlled by another atmega168 and connected with spi. i removed the yaw-gyro from the board to get to the spi bus (also needed for programming the main atmega)... always include a isp-port on every board involving an atmega!that was mainly build to port the arduino code (using crystalfontz serial lcd) to winavr/gcc (using my spi-display). i already had everything working on the arduino and could do some testing with gyro integration and sensor fusion with the accelerotmeter.
this is the frame. i used 10x8 cf-tubes and glued aluminium-profiles for mounting the motors and attaching them to the central gf-plate. the motors are TP 2410-09, supersimple 30A ESC and EPP1245 props.
here's the test-stand. these motors+props are very powerful, so there are 3 bottles of coke in the basket, so it doesnt lift off. getting it to stabilise was surprisingly simple, here's the code. this code is run whenever there's new data from accelerometer, that's 640 times per second. gyro-data is also read then//gyro_x is current gyro output//x_angle is current integrated gyro angle mixed (127/128 gyro, 1/128 accelerometer) with little accelerometer angle (fixed point 20.12)seradj[0]=(gyro_x>>1)+(x_angle>>10); //adjustment/stabilisation for x-axis, basicly a simple PI-controller//serinp[2] is the throttle channel, serout[0] is the ppm-output for the back rotorserout[0]=serinp[2]+seradj[0]; //the values are micro-seconds x2 for the ppm-outputserout[1]=2000; //left, currently offserout[2]=serinp[2]-seradj[0]; //frontserout[3]=2000; //right, currently offthat's stabilising it very nicely. would probably be good enough for flying. the angle it stabilises to isn't exactly 0, probably the accelerator isnt perfectly parallel w.r.t. the frame. ppm is only output for the 4 esc's, one after the other as fast as possible, thats 250hz update rate at idle and 125hz at full power. works great so far.TODO:- better mounting for the pcb, receiver and battery- connect serial display for debugging- stabilise roll and yaw- tons of currently unknown problems- fly :)
Read more…

Getting started

Posted by Túlio Fernandes on January 23, 2009 at 8:00am
Okay, I just bought my freeduino and a ADXL330(Wiimote 3-Axis Accelerometer module). I bought everything at seedstudio which cost me USD $45, a bargain, since here in Brazil just the freeduino would cost me slight less than the double.When these two little babies arrive I will start myself in arduino programming and DIY stuff, since I started my computer science course I felt in love with this kind of stuff. I started reading in a daily basis things about PICs, eletronics, automations, DIY, you name it. But I think I have read enough, I need to go to the next level the one which we do something :DFreeduino - way too expensive in Brazil.(USD $40)

Read more…

Questions about piloting my Hawkeye RC with the ArduPilot

Posted by kitemaker Ken on January 23, 2009 at 1:07am
An old friend developed a nice Rogallo winged RC plane which he calls the Hawkeye. If interested, you can read about it at his site- http://electricflights.com/hawkeyemainpage.htmlI test flew the Hawkeye last summer into the fall, until the rains returned to the northwest. It is very portable, easy to fly and designed to carry a camera. Shot lots of video and then realized that I want an autopilot to increase my odds of getting the shots I'm after. I'm game to try an ArduPilot, as its design and open platform appeals to me.

The Hawkeye flies fine with its rudder and throttle controls, being quite stable and impossible, in all my experience, to invert. So, can I assume that I won't need to use a FMA IR stabilizer? Wouldn't know what to control with the FMA Co-Pilot, as there's no elevator or ailerons on this bird. Has anyone successfully flown anything with the ArduPilot and no FMA Co-pilot? Will the current ArduPilot firmware work as designed without a FMA Co-pilot on board, or will I need to rewrite some of the code?All questions, comments, advice or fore warnings will be read, appreciated, and answered, thanks!
Read more…

SLUGS Autopilot. Soon to become Open Source.

Posted by SLUGS Team on January 22, 2009 at 4:13pm
The Santa Cruz Low-cost UAV GNC System (SLUGS) is a high-end UAV Autopilot that is currently under development by the Autonomous Systems Lab at the University of California Santa Cruz. Although not ready for prime time, the project's website shows some significant progress towards a fully functional platform.The SLUGS autopilot is heavily geared towards research in small to medium sized UAVs. Great care has been taken to assure that it has enough processing power for moderately complicated control tasks and at the same time is easily reprogramable via Simulink. This effectively allows to rapidly iterate from simulation to implementation with no intermediate coding.The developed architecture physically decouples sensor integration and INS filtering from the control algorithm and communications by using two 33Fj256MC710 dsPIC Digital Signal Controllers (DSC) interconnected via a high-speed Serial Peripheral Interface (SPI) bus. The SLUGS autopilot has been designed to be modular and extendable in order to extend the sensor and peripheral suite as the need arises via CAN bus daughterboards.The Ground Station Software has been developed to decode the incoming telemetry messages from the SLUGS AP. It also works as a Hardware-In-the-Loop interface to Simulink and is the central point to configure the Autopilot.One of the main features of the SLUGS AP is its ability to interact with virtually any Simulink model via a Hardware-in-the-Loop Simulator. There is a predefined protocol to send simulated sensor readings to the AP, as well as a protocol to receive control commands back. But aside from that, one can make the HIL simulator as simple or as complex as one needs. Currently we have a six-degree-of-freedom model of our UAV, and an engine model. Some work is underway to include an atmospheric and weather model.We are currently working very hard to write some sort of documentation and getting all the code ready for public release under the MIT Open Source license and under GIT version control system. We expect this to be ready around April this year.
Read more…
3D Robotics

ArduPilot (Legacy) main page

Posted by Chris Anderson on January 21, 2009 at 5:00pm

 

3689315381?profile=original

 

[This original ArduPilot board, now called the "Legacy ArduPilot" is no longer produced or officially supported by the DIY Drones dev team, and this page is maintained just for historic reasons. However, there are still many users of it out there and it still works fine. The user group for Legacy ArduPilot users, for both thermopile and IMU use, is here.]

 

ArduPilot is a full-featured autopilot based on the Arduino open-source hardware platform. It uses infrared (thermopile) sensors or an IMU for stabilization and GPS for navigation. It is the autopilot used to win the 2009 Sparkfun Autonomous Vehicle Competition.

The hardware is available from Sparkfun for $24.95. An expansion board ("Shield") kits that includes an airspeed sensor, a 3.3v power regulator for 3.3v GPS modules and other sensors and cables and connectors for easy attachment of the XY and Z sensors, is available from our own store for $57.20.

 

User f

ArduPilot features include:

  • Can be used for an autonomous aircraft, car or boat.
  • Built-in hardware failsafe that uses a separate circuit (multiplexer chip and ATTiny processor) to transfer control from the RC system to the autopilot and back again. Includes ability to reboot the main processor in mid-flight.
  • Multiple 3D waypoints (limited only by memory)
  • Altitude controlled with the elevator and throttle
  • Comes with a 6-pin GPS connector for the 4Hz uBlox5 or 1hz EM406 GPS modules.
  • Has six spare analog inputs (with ADC on each) and six spare digital input/outputs to add additional sensors
  • Supports addition of wireless modules for real-time telemetry
  • Based on a 16MhZ Atmega328 processor. Total onboard processing power aprox 24 MIPS.
  • Very small: 30mm x 47mm
  • Can be powered by either the RC receiver or a separate battery
  • Four RC-in channels (plus the autopilot on/off channel) can be processed by the autopilot. Autopilot can also control four channels out.
  • LEDs for power, failsafe (on/off), status and GPS (satellite lock).


Resources:

ArduPilot requires the free Arduino IDE to edit and upload the code to the ArduPilot board.


The code is currently optimized for the Mutiplex EasyStar three-channel powered glider and FMA sensors, but can be modified for other aircraft and sensors. It uses the rudder/ailerons and elevator to maintain level flight and navigate to GPS waypoints. It supports a desktop setup utility and ground station software. It also includes a "fly-by-wire" mode that simply stabilizes RC flight. The main code is ArduPilot2.x.zip in the download section of our Google Code repository, where x is the latest version.

What you need to make a fully-functional autopilot:


Open source extras:

  • If you want to build your own board from scratch, the necessary files and component lists are here.
  • [Note: you shouldn't need this, since this code is loaded on the ArduPilot board at the factory] Latest multiplexer code (for the board's second processor, an Attiny, which runs the failsafe system) is here.
    Instructions for loading this code are here.



Recommended UAV setup:

3689303688?profile=original


Airframe option one: Hobbico SuperStar (49" wingspan, $95, shown above). This is an inexpensive, good flying high-wing trainer with ailerons. It can be hand launched in a park or take off from a runway, and replacement parts are readily available in case of a crash. If you want much better performance with this aircraft, you can upgrade it to a brushless motor, speed controller and a LiPo battery. [If you don't already have one, you'll also need a balancing charger and power supply.] Note: any stable aircraft with both ailerons (for stabilization) and rudder (for navigation) can work, so feel free to experiment with what you've got.

3689313666?profile=original


Airframe option two (recommended for ArduPilot 2.x): EasyStar (shown above). Performance can be improved with the modifications described in this post.

You'll also need:

  • A six or seven channel RC transmitter and receiver, with at least one toggle switch (ideally three-position but two-position will work, too, although you will have to mix channels to have access to both autopilot modes in the air), such as the Futaba 7C.
  • Some servos (at least three for ArduPilot 1.0; at least two for ArduPilot 2.x) and at least three female-to-female servo cables to connect the RC receiver to ArduPilot.


Cool optional extras for your UAV:

Read more…
3D Robotics

Update on ArduPilot availability

Posted by Chris Anderson on January 20, 2009 at 9:37am
Just got the latest from Sparkfun: A total of 87 ArduPilots have been shipped so far. A big batch of 61 of the original rev that were backordered by customers went out on Jan 13th. We're currently have another 34 to fill from backorder. The new revision (with the 5V power regulator) has been ordered and 300 pieces are inbound. ETA on PCBs is Jan 23rd, although it will take about a week after that to populate them with components. I expect that by the end of the month, we should have all the inventory we need and will able to make boards as quickly as demand comes in.
Read more…
3D Robotics

ArduPilot flight test 2: RTL

Posted by Chris Anderson on January 19, 2009 at 10:07pm
Well, chalk up another one to the limitations of sims. Today's return-to-launch (RTL) testing was a mixed bag. When the Superstar was heading off away from us and I enabled the autopilot, it nicely turned back, but when it got overhead it went into a death spiral and I had to disable the autopilot to recover. This happened multiple times, despite it working fine in the sim. Perhaps this was due to the wind (10-12 mph) or the airframe, but the software should be doing a better job regardless. I think we need to work harder on our "circle overhead" algorithm and otherwise put a little more AI in our navigation routines. This is pretty normal for this stage of development and we'll get there. Meanwhile, it was nice to fly on another beautiful day in the Bay Area.
Read more…
3D Robotics

Some guidelines on picking wireless frequencies

Posted by Chris Anderson on January 19, 2009 at 10:30am

3689309441?profile=original

Wireless can be something of a black art, and there are a dizzying array of standards and choices. Here are some simple guidelines to help you pick wisely:

  • --We operate in four frequency ranges: 72Mhz (RC gear), 900 Mhz (video and telemetry), 1.3 Ghz (video) and 2.4 GHz (RC, video and telemetry), not including GPS, which is a passive receiver only.
  • --It is a BAD IDEA to have transmitters and receivers in the same frequency range right next to each other, so you'll want to choose your equipment to avoid this.
  • --In general, the lower the frequency the longer the range because it can go around obstructions better, so 900 Mhz video tends to have longer range than 2.4Ghz video. But digital transmission technology can more than compensate for that, so it's not a hard-and-fast rule. For instance, a high-end spread-spectrum 2.4GHz wireless video setup can outperform a lower-end 900 Mhz one.
  • --Some frequency ranges are more crowded than others. For instance, indoors and in urban environments 2.4GHz has to compete with everything from WiFi to Bluetooth to cordless phones. 900Mhz just competes with some cordless phones.


So, for example, you could try these configurations:

 

Configuration One: RC: 2.4Ghz. Xbee 900Mhz. Video: 1.3 Ghz

 

Configuration Two: RC 2.4 Ghz, Xbee 900Mhz, Video 2.4Ghz, with antenna as far from RC as possible

 

Configuration Three: RC: 72 Mhz, Xbee 900Mhz, Video 2.4 Ghz.

Read more…
3D Robotics

Adding wireless telemetry to ArduPilot

Posted by Chris Anderson on January 18, 2009 at 10:30pm

You may have noticed that we had wireless telemetry in our flight testing last week. It's really easy to add. The first thing to keep in mind is that you should use Xbee modules in a different frequency range than your RC equipment. If you've got 72Mhz RC gear, you can use 2.4Ghz Xbee modules. We use Xbee Pro wireless modules with a Adafruit adapter board on the aircraft side, and a Sparkfun USB adapter board on the ground/laptop side. If you've got 2.4Ghz RC gear, you should use 900Mhz Xbee modules. We use a Xbee Pro with the wire antenna for the aircraft, and and Xbee Pro with a SMA antenna connector (and a good 900Mhz antenna) on the ground, with the same adapter boards as above. Next, you need to set up your Xbee modules. They ship with a default of 9600bps, which you must change to 4800 bps for ArduPilot 1.0 or 57,600bps for ArduPilot 2.x. Connect them with your FTDI cable (see instructions here) then use Digi's X-CTU utility to change the baud rate to 4800 or 57,600 (in the modem configuration tab--press the Read button and then click on and change the baud rate line). You should also give them unique Network IDs so they'll be paired. Just use any 3-digit number, and just make sure you've set it the same on both modules. (Don't use 999 if you're going to be flying around me--that's mine!). When you're done with the settings, click "Write". Remember that after you change the baud rate you have to switch back to the PC Settings tab and change the baud rate there, too, or the utility won't be able to communicate with the module. (Switch it back to 9600 when you're switch to the second module, if it's still in the default mode, and repeat the process.) On the ArduPilot side, use three jumper wires to connect the following pins circled in red on the board below: --Xbee RX to ArduPilot FTDI port TXO --Xbee 5v+ and GND to the VCC and GND pins next to the FTDI port.

It will end up looking like this:

(Note: the above is to get telemetry from the Autopilot. If you just want to see the NMEA data from the GPS module, connect the TX pin to ArduPilot's RXI pin, right next to the to TXO pin, instead.) On the ground side, connect the other Xbee module to your laptop with your FTDI cable, as described here. That's it! If you open up a terminal program on your laptop and set the baud rate to 4800 or 56,000, depending on which ArduPilot software version you're using, you should see ArduPilot telemetry coming in. Anytime there is a "Serial.println" in the code, that data will be sent through the Xbees to the ground. You can record any data you want, and even GPS datalog from the ground! Couldn't be easier. BTW, if you want to test the range of your Xbee link, connect the plane-side Xbee module's RX and TX pins together to create a loopback circuit and use the X-CTU utlitity's range test function. For the modules we're using you should get around a mile. Once you've got the wireless connection set up, you can use our Ground Station to display real-time telemetry with ArduPilot 2.1 and up:

Read more…

ArduPilot modification for controlling 4 servos from code

Posted by Michal B on January 18, 2009 at 3:45pm
Original ArduPilot controls 2 servos (throttle/yaw) by autopilot code or from RC receiver. Other 2 servos are controlled by FMA copilot (or again manually by RC). Although there're servo IN3/4 and servo OUT 3/4 connectors on ArduPilot board, they're at present unused (actually only pass-through control from IN3/4 to OUT3/4 is connected).Yet there's simple way to control all 4 servos from ArduPilot code, and use other two servos for interesting tasks, such as moving plane's camera tilt. Or even better - provide full stabilization in basic ArduPilot, which is at present only planned in ArduPilot Pro.While I don't know yet if stabilization code would fit into 16KB memory of AT168 (together with navigation code), I'll just post how to control all 4 servos from code. We'll see what comes out of this.On hardware side, there's simple wire soldered between digital 6 pin and MUX IN 3 pin. Also connector is added at servo OUT 3 at top right for connecting the servo:

This is for controlling servo 3, for adding control of servo 4, add another wire from D7 to MUX4 and another connector to Servo OUT 4.Now programming part... For controlling servo, we need to output PPM signals at pins 6/7. And do it at 50Hz frequency. Luckily we can set interrupt function that will be called 50 times/second, and generate PPM pulses there. This functionality will use up to 10% of CPU (for delays while generating PPM signals). All the code is here.In your code, call Servo_3_4_Init once, then Servo_3_set or Servo_4_set whenever you need to set angle for particular servo.That's it! We can control now 4 servos from inside code. And possibly add stabilization part to the code...? Let's hope so.
Read more…

UAV Senior Project

Posted by Roy Stevens on January 18, 2009 at 3:19pm
Hi everyone,My classmate and I are building a UAV as part of our senior project. We're going to base it off the Ardupilot. Despite having little experience directly in UAVs, we think, perhaps incorrectly, that the project will be lacking a bit in depth (thanks to Chris Anderson and Jordi Munoz for doing a lot of the real work for us). We are looking for any suggestions from the community for a good add-on project that could be accomplished in a couple months. Anyone have any ideas? Thanks in advance!
Read more…

Alternative connection of GPS to ArduPilot

Posted by Michal B on January 17, 2009 at 3:00pm
If you don't like too short connection cable of GPS to ArduPilot, then here's a fix. Longer cable and better connector will solve 2 problems:- more flexible assembly into a plane- easier program upload to board (since GPS cable must be disconnected before uploading)Original connection:

We don't need to use original GPS connector on ArduPilot, and can connect directly to one data pin and Ground/VCC. So we need just 3 wires, and ideal choice is standard servo cable.I used Servo extension cable, cut it close to female connector, and soldered it to the board as shown here:

and detail:

Then cut original small GPS cable to half, and solder it with servo extension cable male part:

Properly isolate wires:

And you're done:

Tested, it works.
Read more…
3D Robotics

ArduPilot flight testing--success!

Posted by Chris Anderson on January 16, 2009 at 9:00pm

Great day of flight testing ArduPilot today. Jordi and I were joined by Jack Poller, and we spent the whole day debugging code, tweaking gains and otherwise building towards the aim of the day, fully autonomous flight. Good news: ArduPilot works great in the air, we now have an officially flight-tested autopilot! Here's how the day went: --Arrived at the BARCS field and set up all the equipment. Beautiful day in the Bay Area--warm, sunny and no wind. Today we were going to test ArduPilot with the Superstar EP as the main platform, with the EasyGlider and EastStar with EasyGlider wings as secondary platform. --First hitch: we realized that in the last code rev we introduced a bug. Although the ArduPilot board is working fine, the navigation isn't working at all. Lots of debugging and looking at variables on the Arduino serial monitor. Eventually Jordi finds the bug (two variables got reversed). --While he's debugging, I get the EasyStar with Easy Glider wings ready to fly. I get it up a few times but it's really a dog. The ailerons generate as much inverse drag as they do tilt and it's just a struggle to keep it in the air. I crash land once, then again, then after some repairs, a catastrophic nose dive under power. Bye-bye FrankenStarGlider!

--Second hitch: FMA Co-pilot (the version with the built in Rx) is acting flakey. Lots of wiggling of wires before we realize that the crystal is falling out! Scary. Put it back in and tape it for safety. --Lots of flying and watching ArduPilot data and GPS telemetry on the ground via the Xbee wireless module on the FTDI pins of the autopilot board. FMA working great, but when the autopilot is on we're getting inexplicable behavior. This isn't the way it worked in the sim! Keep landing and tweaking gains but it still isn't going in the direction it's supposed to go. Switch to "sneaker sim". Jack walks around with the plane and we watch the rudder and telemetry. --We've been flying in RTL mode but to make the debugging easier decide to switch to "NE mode"--when the autopilot is switched on the plane should always fly NE (that just happened to be the way the wind was coming and wasn't into the sun). --Eventually we figure out what's wrong. The way I've got the Superstar set up, both Channel 3 and 4 are reversed at the Tx to suit the servo configuration. D'oh! Reverse the sign of the servo commands in the code, and now it seems to be working right in sneaker sim. Realize that we need to write a checklist for people using ArduPilot with basics like watching out for reversed channels and remembering to disconnect the GPS before uploading new code.

(Jordi and Chris. All photos by Jack Poller. Full gallery of the day here). --Back to the air. Better, but still not there. It's losing too much altitude in turns. Land, reduce the gains so full rudder is just 15 degrees. Switch from a 7.4V battery to an 11.1v battery to give the plane more power (it's really struggling to climb). --While Jordi is tweaking gains and charging up laptops, Jack and I fly the EasyGlider Pro with FMA stabalization. It's a lovely plane and flies so well. Jack, who's never flown before, gets about ten minutes of air time and proves a natural. Jordi takes it a few times and achieves his best landing ever. Yay EasyGlider Pro! --Laptops recharged and new code loaded. Now we're getting there! The plane flies much better with the extra power. The FMA is dialed in just right. And ArduPilot is rock solid. Tight turns, tracks straight and good altitude hold. Success!

It's the end of the day and we're delighted--mission accomplished. Videos coming later but in the meantime, here's the new code. Also check out Jack's photo gallery of the day.
Read more…
3D Robotics

RC Helis used to smuggle stuff into prisons; how soon until they're UAVs?

Posted by Chris Anderson on January 16, 2009 at 7:40am

From BoingBoing: Someone flew a payload of something into Elmley Prison in Sheerness, Kent, using a RC helicopter. Whatever it was, it's been ingested or hidden, because no one can find it.: "A spokesman said: 'A remote control helicopter was flown into the grounds of HMP Elmley on December 23. 'As a result of this, a search of the prison grounds and an accommodation block were carried out and nothing was found...' 'Using a mini-helicopter to get contraband into jails is unprecedented. When officers spotted it they nearly fell off their chairs', a prison source told the Sun. 'It could have been drugs or a mobile phone in the package. It is possible it was a dummy run.' [Chris here: let me be clear that I'm posting this as a warning, not a recommendation. People may use our technology for ill as well as for good, so we should be part of the process of thinking how to stop/spot illegal activity, as well as (inadvertently) enabling it. ]
Read more…