All Posts (14048)

Sort by

Gizmodo is paying homage to DIYDrones

31e92b8cf0abbd4a9a817354f2864eb7.jpg

It would seem over time this little community is picking up in notoriety. This is awesome everyone and the growing numbers and increased projects and creativeness show what a truly unique community we have here at DIYDrones. Keep it up and I am sure that we will continue to gather more press. The link to the article can be found at:

http://io9.com/5876952/unmanned-aerial-vehicles-coming-soon-to-a-sky-near-you

excerpt:

Get our top stories

follow io9.com

carrot.png

Unmanned Aerial Vehicles: coming soon to a sky near you

The last decade of global conflict has seen the dawning of the age of the robot plane. Unmanned Aerial Vehicles (UAVs) have been around for decades, but today they're ubiquitous war machines with unmatched endurance and lethal combat capabilities. Find out more about these increasingly high-tech pilotless aircraft.

Unmanned Aerial Vehicles: coming soon to a sky near youDrones were developed in the early days of aviation, and were used almost exclusively as moving targets for training exercises. Serious development of controllable unmanned aircraft in the 1960s lead to extensive use in Vietnam. The AQM-34 Ryan Firebee, for example, flew over 34,000 missions – primarily used for surveillance, they could also detect enemy anti-aircraft missile installations. Once launched, they were controlled remotely by a "pilot" in a DC-130 flying nearby. The Lockheed D-21 UAV, which looks like one of the engines from the Lockheed SR-71 Blackbird detached and given autonomy, holds the record as the fastest UAV, topping Mach 4. However, it never made it beyond the testing phase (photo: a D-21 piggybacks on top of an SR-71).

The military UAVs familiar today trace their lineage to aircraft developed in the 1980s. Israel was at the forefront of UAV design, using several light, remotely controlled aircraft to great success in the 1982 Lebanon War. The first modern UAVs used by the U.S. military were Israeli Pioneers purchased in the early 90s.

Better remote control and camera technology allowed UAVs to take on more involved reconnaissance roles. The Israeli light UAVs also focused on light, efficient designs, emphasizing one of the UAV's most important abilities – incredible in-air endurance. Today's UAVs can remain on-mission for 30 to 40 hours, far beyond the capabilities of any human crew. Research into mid-air refueling of UAVs and ultra-efficient solar-powered UAVs could extend that range close to infinity, limited primarily by maintenance needs.

The most well-known U.S. UAV is the Predator, designed and built by General Atomics Aeronautical. The Predator is typical of UAVS in that is uses a relatively simple design that allows simple field maintenance and high reliability. For instance, the 4-cylinder turbocharged engine that powers a Predator is similar to those used in snowmobiles, and the alternator that provides most electrical power would be familiar to the average garage mechanic.

Unmanned Aerial Vehicles: coming soon to a sky near youOne notable characteristic of current generation UAVs is the "cockpit" bulge, a featureless dome where the pilot would sit in a conventional aircraft. This dome houses an array of antennas that allow control and sensory signals to move back and forth between the plane and the controller. The largest is a satellite communications dish – this dish's size and placement are the main reasons UAVs are shaped as they are.

Unmanned Aerial Vehicles: coming soon to a sky near youThe U.S. military was not content to merely identify targets with their UAVs – they wanted to blow them up, too. That's why the Predator (and its variants the Gray Eagle and the Avenger) can be armed with Hellfire missiles. In this configuration, they are not used as front line warfighting machines – against a plane with a human pilot, a UAV will lose every time. They're more like high-tech assassination weapons. In that capacity, the U.S. has used them to kill high-level al-Qaeda operatives like Anwar al-Awlaki. The drawback of this approach is that the imprecision of the Hellfire has caused numerous civilian casualties (the exact number is perpetually in dispute). In the future, UAVs may be armed with smaller, more precise armaments such as the Griffin or Spike missiles.

You might expect that future UAV development points toward fully autonomous planes. There is certainly work being done in this area. Today's UAVs have some forms of autonomy – flight control surfaces may be fully automated, with the controller simply issuing a series of GPS waypoints as the on-board computer handles the details. It's important to note that UAV autonomy research comes mainly from the control angle. That is, programs are written with sensor input/decision trees for the plane to follow. Actual artificial intelligence is not a major aspect of UAV research. But overall, autonomy is not a priority right now. It's a cost-benefit issue – the cost of developing effective autonomous UAVs is undercut by the cost of training human controllers, and there's no great necessity for planes that fly themselves. The political and social ramifications of fully autonomous planes armed with missiles also loom large within the Pentagon.

If not toward autonomy, where is UAV development heading? Toward robustness and ubiquity. Next-generation UAVs will be larger, allowing them to carry more payload. They will also have more powerful engines – the Avenger variant of the Predator has jet engines – allowing for faster response time. Proliferation of the technology means non-NATO countries will have their own UAVs. Russia has a relatively successful UAV development program, and manufacturers are selling designs like the Hermes 900 to South American countries. Pilotless aircraft will soon be part of a every belligerent international conflict.

That ubiquity can be worrisome, though, when it takes place back home. For now, UAVs used in domestic situations in the U.S. have been smaller, "man-portable" units used for search and rescue, fire suppression and surveillance. NASA uses a Predator variant called the Ikhana (top photo) for civilian research and development. What happens when the cost comes down and every police department in the country has a fleet of UAVs constantly in the air? Current privacy laws are probably not going to answer all the questions such a situation will bring up.

The counterpoint to this UAV-powered panopticon is that it is becoming increasingly easy for the average citizen to create and operate a UAV. The website DIYDrones offers access to an open source project called ArduPilot. ArduPilot is a computer that installs into a plane (typically a radio-controlled plane), then runs the ArduPlane autopilot software, transforming it into a UAV. Civilians even created a UAV to observe police activities during Occupy protests – the OccuCopter is a quad-rotor UAV that can be controlled via iPhone and streams video live to the internet.

Read more…
Wiki Ninja

My APM 2.0 maiden with the MPX Fun Cub

ArduPilot Mega 2.0, the newest autopilot from 3D Robotics/ DIY Drones is mounted in my trusty Multiplex Fun Cub.

The code is 2.27 uploaded via the latest ArduPilot Mega Planner.

Tested were Manual, Stabilized and RTL (Return To Launch) modes. The Fun Cub's Surface Controls were twitchy because I did not put some expo on the ailerons and elevator.

On RTL mode, the Fun Cub was getting battered and shoved by winds on altitude, hence I cannot say if the loiter radius was right. I did not wait for a couple more minutes for the GPS satellites to have a solid fix so on RTL mode, so the Fun Cub loitered a little bit off from the home position; it does not matter because the plane is within my vicinity. Overall, the APM 2.0 performed great in a smaller and lighter form factor.

Thank you APM Dev Team and DIY Drones!

 

Read more…

Hi,

I found this nice blog post, how to run LEDs with the relay switch. I modified the software to work with AC 2.1 firmware. And I added functionality that you can set the limits for the low battery warning with mavlink parameters.

3689441760?profile=original

Overview what this software modification does and what hardware modifications you have to do:

  1. You need to add some LEDs or LED-Stripes in a way, that you can controll them with the relay switch on the IMU (blue PCB).
  2. You need a proper hardware setup to measure the voltage of the whole battery.
  3. If you arm the copter, the LEDs will turn ON.
  4. If you disarm they turn OFF.
  5. If you are flying (LEDs ON) and battery voltage drops under a certain level, they will start to flash slowly.
  6. If battery voltage drops under another level, they will start to flash fast. Go landing!
  7. The voltage levels can be adjusted via mavlink parameters, so you can tune them on the field and you don't have to compile again if you want to change them.

Now how it´s done:

First a WARNING: You use this modification at your own risk! On my tri, it works. Please leave a comment if it works also on your copter. I'm starting from ArduCopter code 2.1.

1 Add LEDs

If you using 3S Lipo, you can directly connect 12V LED stripes widely aviable. They consume ca. 600 mA per meter. The relay called AXICOM IM03 can switch 2A. In this blog post, its already explained how you can add the LEDs and voltage measurement to your hardware setup. But don't make mistakes, it can damage your board or even your battery. I did not modified my IMU PCB, I directly connected the LEDs to the 12V Battery and inserted the relay as switch in between.

2 Add voltage measurement

Here is a discription how to measure battery voltage.

3 Changing the code

Download this file: RunningLights.pde and put it in the ArduCopter directory.

Add the following to your "APM_Config.h" file and modify it to your needs:

#define BATT_WARNING_RELAY  1   // 1: Relay Switch controls LEDs an generates low battery warning. 0: no changes.
#if (BATT_WARNING_RELAY == 1)
# define BATTERY_EVENT   ENABLED
# define LOW_VOLTAGE      9.8   // default values, editable via mavlink
# define LOW_VOLTAGE_PRE 10.5
# define VOLT_DIV_RATIO   3.27  // take care of this, it depends on your resistors
# define MOTOR_LEDS  0  // Do not use build in LED function
// The following two global variable definitions need to be added to the "Arducopter.h" file
int rl_state   = 0 ;    // this global variable is used to save the on/off state of the relay
int rl_counter = 0 ;    // this global variable is used for the flash rate timer
#endif // (BATT_WARNING_RELAY == 1)

In file "ArduCopter.pde" in function "static void medium_loop()" modify (add 4 lines):

             if (g.battery_monitoring != 0){
                 read_battery();
                // Mod for Low.Batt.Warning with LEDs on Relay //  ( add 4 lines from here)
                #if (BATT_WARNING_RELAY == 1)
                handle_relay_lights();
                #endif
             }

In file "Parameters.h" section public:

Increase the number after "static const uint16_t k_format_version" by one. Warning: This will make the APM erase your EEPROM and Log after flashing the new compiled firmware. So save your settings first! After this, you have to reload your settings and level the copter again.

On the following 3 blocks, look for the first line and add the second line:

     k_param_super_simple,         // search for this line
     k_param_low_voltage_pre,     // add this line below it

     AP_Int8        super_simple;
     AP_Float    low_voltage_pre;

     super_simple            (SUPER_SIMPLE,                k_param_super_simple,                    PSTR("SUPER_SIMPLE")),
     low_voltage_pre            (LOW_VOLTAGE_PRE,            k_param_low_voltage_pre,                PSTR("LOW_VOLT_PRE")),


Now, you can compile and flash. Connect with mission planer, go to settings and klick refresh parameters. You will see in the list on the left side LOW_VOLTAGE_PRE and LOW_VOLTAGE. The first is the treshold for slow flashing, the second for fast flashing.

Things to mention:

I hacked this HowTo together from several commits on my local git repository. I hope everything needed for this change is mentioned here. If it works for you, please write a comment! And use this at your own risk, you should know what you are doing if you modify hardware and software.

U4eake has also improved his original version! You can find it here !


Have fun!

Igor Van Airde

Read more…

It flies...

3689441819?profile=original

Hi there...

being a complete novice with autopilots and quadrocopters in general, I just got my stock 3DR kit completed and was able to fly.

Some observations that might help newcomers to get the stuff together:

  • If you think you have checked everything - do it again. There's certainly something you missed.
  • Getting the right motor connections to the PDB board is a nightmare. Even if you follow the instructions, you almost certainly end up with a wrong order of motors. Even if the CLI motor test works as per instruction, it might still be wrong. I had to switch front and back motors to make it work. The best test ist the "hand test" - hold the copter over your head and apply some throttle. Feel how the copter reacts to movements. Even if you never have done this before, you will feel when it is right. The copter will feel incredible stable in your hand. If it just does "something", then there's probably something wrong.
  • To change the order of motors, instead of disassembling the frame and to resolder the PDB, I just swapped pins in the connector from the motor output of the APM to the PDB. Much easier.
  • I had to reverse the pitch channel on my R/C. Don't know why, but when I pulled the stick, the back motors increased speed instead of the front motors.
  • Definetly think about getting telemetry - flying the copter is so much fun, you will need the battery monitor ;)

So much for today - need to update the copters firmware ;)

Michael

Read more…
3D Robotics

ArduPilot 2012 Software Roadmap

3689441745?profile=original

About once a year we post our software roadmap for the next 12 months. Last year, we promised we would take ArduPlane and ArduCopter into their 2.x generation, with full two-way MAVLink control and a full featured ground station and setup process. The 2.x generations of the code were intended to give APM-based vehicles all the features of professional-quality autopilots at a tiny fraction of the cost. With a huge amount of effort from the whole dev team, which now numbers nearly a hundred people across its many projects, we've completed that. Yay!

 

The 2.x generations of ArduPlane and ArduCopter are now being flown by thousands of people, making the APM platform the most popular open source autopilot in the world.  With the introduction of APM 2 (above), with vastly improved sensors, lower price and fully-assembled delivery, this growth looks likely to accelerate. After a shipment of 150 boards to early-adopters last month, full production of APM 2 will resume in early Feb. The current 2.x codebases already fully support the new APM 2 boards.

 

So at this point the 2.x codebases are essentially feature complete, and we can move on to 3.x. (That said, the 2.x software will see continued updates to improve performance and reliability. In particular the traditional heli version of ArduCopter is a couple versions behind the more mature multicopter code, and will continue to evolve over the next few months--helis are hard!).  

 

As the dev teams focus on the 3.x code, you should see far fewer public code updates for a period of about three months (until April 2012). Lots of work will be going on behind the scenes in the Git repositories, but we will not be rolling out public releases of new features that risk drowning the team in tech support and documentation demands. Again, we will continue to fix any issues that are identified in the 2.x code and otherwise ensure that it's flying well for everyone, but we won't be adding new features to it during this period.

 

The 2012 Software Roadmap

 

The main objective of the 3.x codebases will be a new architecture that emphasizes modularity and portability. This is to help with the following:

  • Better reliability by making the code easier to understand, debug and maintain
  • Easier accessibility for new dev team members
  • Easier portability to new hardware platforms
  • RTOS compatibility, to prepare for the forthcoming ARM-based versions of APM

Examples of Planned New 3.x Features:
  • MPU-6000 DMP support. 
  • Inertial dead reckoning drift compensation
  • Full scriptable camera control on both ArduPlane and ArduCopter, with interactive camera gimbal setup
  • Auto-trim:  sets RC trim points when exiting manual mode
  • Loss of signal failsafes for GCS link
  • ArduCopter: Autonomous "follow me/look at me" control with handheld GPS groundstation
  • ArduCopter: Support for I2C/SPI/CAN motor controllers and forthcoming "smart" motor controller/PDB board
  • ArduPlane: Support for Flaps with automatic speed dependent deployment
  • ArduPlane: Servo control loop gains with speed scheduling
  • ArduPlane: Airspeed nudging from the RC TX in autonomous modes
  • ArduPlane: Inverted flight mode and scriptable acrobatics
  • ArduPlane: Sonar flare control

Architecture changes:

Make RTOS support possible:
  • Eliminate global state in sketches. This is a broad, fundamental change required to effectively use an RTOS.
  • Modularize sketch code into classes with interfaces. This will improve code comprehension and help enforce communication with messages rather than global state (again, required for RTOS)
  • Replace loop()-style structures with explicit periodic scheduling. This will increase code comprehension, enforce non-reliance of ordering of loop items (& global state), and make it easier to move to RTOS later.
  • Eliminate remaining synchronous blocking IO
Coding style:
  • Rename library class methods and members to meet coding standards
  • Run automated ‘indent’ script on all source, implement indent bot which fixes whitespace issues checked into repository nightly
  • Dramatically reduce reliance on preprocessor in sketches: features like HIL & ArduCopter traditional heli will be implemented using standard interfaces rather than source code manipulation
Logging:
  • Proposal: switch from special dataflash logging packets to MAVLINK 1.0 data
  • Modularize logging, move to libraries directory
  • Add SD card support for APM2

 -------------------

Join us!

If you'd like to join the dev teams, please read this post on the best ways to do it. (Short form: pick something specific that you'd like to help with and show some familiarity with the code). We're always looking for more programmers, but we're careful about taking time to figure out how to integrate them best and on which project, both for their sake (to have the highest impact soonest) and for the sake of the existing dev team members, who have limited time. 

 

You can always PM me with a request to join the team, and I'll generally start by adding you to the dev team mailllist so you can see how we work and get a feel for where you might fit in best.

Read more…
3D Robotics

3689441646?profile=original

From Aviation Week:

A lightweight automatic ground collision avoidance system (Auto GCAS) which depends on a terrain database of the entire world housed in a smart phone is being flight tested by NASA.

The flights follow initial development of the Auto GCAS for U.S. Air Force F-16, F-22 and F-35 fighters, and are aimed at extending use of the safety system to a much broader range of applications from unmanned air vehicles to general aviation aircraft. The system uses precise navigation, performance and digital terrain data to constantly monitor the aircraft’s position relative to known obstacles. Auto-GCAS is designed to intervene as a last resort, automatically recovering an aircraft when it senses that a ground collision is imminent and the pilot is not taking action.

...

Unlike the original Automatic Collision Avoidance Technology (ACAT) Auto GCAS project which was flight tested on an F-16D in 2010, this new test phase is using a 9 ft 8 inch wing span radio-controlled hobby Super Flyin’ King model aircraft. Tests of the Droid (Dryden Remotely Operated Integrated Drone), are being undertaken by NASA Dryden Flight Research Center with support from the Office of the Undersecretary of Defense and the Air Force Flight Test Center.

“We’ve talked about the modular architecture which means you can put it on other aircraft, but we’d only flown it on an F-16. So we asked why not try it out on a very different aircraft,” says Auto-GCAS project manager Mark Skoog. Aside from demonstrating the transition and portability of Auto-GCAS to another platform, the project is also designed to develop and explore performance enhancements such as new escape maneuvers beyond the vertical fly-up used by the F-16 system.


3689441709?profile=originalLateral escape maneuvers (marked in blue)


(via RCG)

Read more…

Hi,

I just build a Tri based on ArduCopter. I had some issues with yaw and did some changes in the code. In this post I want to share my experience and I would like the developers to take my changes into the official release, that it will be easier for others to build a Tricopter.

First of all, this is the result:

3689441724?profile=original

One of the most interesting mechanical parts, the Yaw-Servo:
3689441383?profile=original


Now my yaw-issues and solutions, starting from code release 2.1:

1) Yaw-Servo not in middle position on "power on"

2) Yaw-Servo reverse with Mavlink RC7_REV

1) Yaw-Servo not in middle position on "power on"

Issue: On "power on" the Yaw-Servo moved into mechanical limit (bad sound, high current consumtion and reduced lifetime for the servo). After a few seconds it returned to the middle position.

Solution:

In file "radio.pde" in function "output_min()":

Replace:

    APM_RC.OutputCh(CH_7,   g.rc_3.radio_min);

By this:
    #if FRAME_CONFIG ==    TRI_FRAME
    APM_RC.OutputCh(CH_7,   g.rc_4.radio_trim); // Yaw servo middle position
    #else
    APM_RC.OutputCh(CH_7,   g.rc_3.radio_min);
    #endif



2) Yaw-Servo reverse with Mavlink RC7_REV

Issue: Depending on how you mount your Yaw-Servo the stabilisation of yaw can run in the wron direction. Reversing yaw on the remote doesnt help. You need to reverse the servo or change it mechanically. To reverse the servo:

Solution:

In file "ArduCopter.pde" in function "fifty_hz_loop()":

Replace:
    APM_RC.OutputCh(CH_7, g.rc_4.radio_out);

by:
    APM_RC.OutputCh(CH_7, (   (-1 * (g.rc_4.radio_out - g.rc_4.radio_trim) ) + g.rc_4.radio_trim  ) );

I got this change from this Link!  Now you can reverse the yaw-servo by putting "-1" to the parameter "RC7_REV" via Mavlink.

Regards, Igor

Read more…

CubeStormer II solves the Rubik's Cube puzzle faster than the human world record.

This ARM Powered robot was designed, built and programmed by Mike Dobson and David Gilday, creators respectively of CubeStormer

and Android Speedcuber



The mechanics are constructed entirely from LEGO, including four MINDSTORMS NXT kits, with the addition of a Samsung Galaxy S II smartphone running a custom Android app as the robot's brain. Both the MINDSTORMS NXT kits and the Samsung Galaxy SII use a variety of ARM --based processors.

The app uses the phone's camera to capture images of each face of the Rubik's Cube which it processes to determine the scrambled colours. The solution is found using an advanced two-phase algorithm, originally developed for Speedcuber, enhanced to be multi-threaded to make effective use of the smartphone's dual-core ARM Cortex-A9 1.2GHz processor. The software finds an efficient solution to the puzzle which is optimised specifically for the capabilities of the four-grip mechanism. The app communicates via Bluetooth with software running on the ARM microprocessors in the LEGO NXT Intelligent Bricks which controls the motors driving the robot. During the physical solve, the app uses OpenGL ES on the phone's ARM Mali-400 MP GPU to display a graphical version of the cube being solved in real time.

Human speedcubers' solve times only include the physical manipulation of the cube and don't include some time which is allowed to "inspect" the cube beforehand. Times recorded by CubeStormer II are for the total solve including: image capture, software solution calculation and physical solve.

Read more…

[OFF-topic] Meanwhile in Brazil...

3689441524?profile=original

don't forget to watch the video in the linked site :D

This guy was arrested by the police for piloting his R/C plane on a busy highway, while on a bike driven by his girlfriend.

According to the reporter the news crew spotted the couple trying to trick the police by flying the airplane at a higher altitude while crossing border patrol.

http://g1.globo.com/parana/noticia/2012/01/rapaz-e-detido-no-parana-apos-pilotar-aeromodelo-na-garupa-de-moto.html

It's kind of funny... but dangerous and unfortunately giving R/C flying a bad reputation.

Read more…

Ideal Motors for Quadcopters:

While searching for the Ideal motors I figured out few things which will give smooth flight and long battery life

1. Should be low Kv

2. Should have enough torque. May be the motors with more outer dia are better

3. Should have very low weight

4. Should be using very low current while on low load. but spinning bigger props

5. CNC light weight casings

6. Should be using Neodmium high temp magnets

7. High quality lamination 0.2mm stator sheet for high temp operation

8.High quality motor shaft.

Or anything else

Read more…

RCTP, a Directed Airflow Controlled Vehicle

After going over a lot of projects here on DIYDrones I realized that there are not a lot of projects involving thrust vector vehicle control.

Inspired by among others the guys at Armadillo and by following my local heroes at CopenhagenSuborbitals I decided to master the technique of balancing a vehicle on a column of exhaust, wither it being air, rocket blast, water jet or something completely different.

Here is one of my initial experiments the Reactive Control Test Platform:

3689441553?profile=original

The RCTP uses 3 vanes, spaced 120 degrees apart, to direct the airflow from a single propeller. The on board IMU (ArduIMU V2) receives input from a RC system (Multiplex EVO 9 with Scherrer UHF) and regulates the thrust vector to maintain a pitch, roll and yaw attitude commanded by the RC transmitter.

Why 3 vanes? ... beacuse it is more of a challange :)

All RC signal reception, inertial processing, data logging and servo output are handled by the the ArduIMU V2 on board processor.

The TCTP MK I and II is a pre-study for a bigger and more advanced vehicle that will simulate an ascending rocket.

More pictures and videos of this and other projects on this blog:

http://dzlsevilgeniuslair.blogspot.com/

I am very interested to hear form people that have any experience with similar aircrafts.

Read more…

Birth of Octocopter :)

3689441582?profile=original3689441607?profile=original3689441582?profile=original3689441652?profile=original

Almost there!
After countless hours of fitting and soldering, the thing is starting to look like something that will
actually fly! I had to make custom 3 degree mounts for the motors as they are too big for the frame.

Amazingly enough, the whole build was without any serious issues. Just niggly little gremlins that
were thwarted quickly.

Setup the APM1 board and all the esc & RC connections.
Loaded the latest firmware using MP.
At first it wouldnt arm, so I re-did the radio calibration and all worked flawlessly.
Im quite surprised as I had ENDLESS trouble with my arducopter but then again those were the
fresh n00b days. Im definitely on the road to not-so-fresh n00b :)

Thanks everyone who helped!

One thing I did notice is with the copter powered up, when I connect the USB to the PC. The
one motors spun up for like 100ms. Shouldnt be a problem. Havent connected via the xbee yet.

Today I plan to loctite all the motor screws and CAREFULLY give it a little test flight this
afternoon, as long as the wind dies down.

Hoping im not going to have too much stability issues.

One last point on vibration. The motors vibrate a little, and in turn vibrate the frame.
The electronics bed (clear polycarbonate) is mounted on 4 anti-vibration mounts.
They work alright, halving the vibration. The APM is mounted with 3 layers of foam double
sided tape. Im happy to report theres virtually NO vibration on it! W00t!

Will post some videos later!

G:)

Read more…

Well this took me a while, I've been too busy travelling to complete in time.

Some of You may remember my earlier post:

http://www.diydrones.com/profiles/blogs/all-in-one-uav-controller

 

Well I must say it is done! And it came out pretty nice! This is an all in one UAV controller:3689441363?profile=original

As mentioned - it's all in one board that contains the following:

- 3 axis gyro

- 3 axis accelerometer

- 3 axis magnetic sensor

- orientation sensor for calibration and in flight corrections

- 2 pressure sensor (one for altitud and the other for air speed measurement)

- moisture and temperature sensor

- 10 Hz GPS

- contactless current sensor

- optically isolated PWM inputs and outputs (5 inputs and 8 outputs), with additional one non-isolated input and 4 non isoated outputs

- 10 16bit analog or digital inputs outputs

- I2C, SPI and CAN communication ports

- miro SD card for data logging

- SEPIC power supply that will maintain device operation down to 1 V remaining on the battery

 

All of it is controlled by TI's 32 bit DSP (TMS320F28335) with float support. This is a real power engine capabe of 150 MMACS!

I've been sucessfully working on programing it directly from Matlab / Simulink - this has dramatically improved code development eliminating hard coding of all routines.

All comes in a neat  2.2 by 2 inch package with weight of just under 0.4 oz (12 grams with no servo headers)!

 

There are two other version being currently build and tested as well - one intended for quad copters (no headers just I2C ad CAN) and the other with an integrated GSM module (Telit's GE865 module).

 

If some of You would like to contribute to the development of this module You are welcome - it turns out working on a project of that scale alone is just beyond my abilities and time commitment, so I would welcome some of You to contribute! Please feel free to contact me!

By the way I will be making other posts very shortly about other exciting projects I've been working on so keep watching!

3689441535?profile=original

Read more…

3689441507?profile=original

Video of my BlimpDuino at Melbourne Mini Makers Faire

http://www.flickr.com/photos/74286203@N05/6704426813/in/pool-1874758@N22

More about the event:

and

Richard
Read more…

QuadControl - A cheap, expandable controller

3689441464?profile=original

Over the past couple of months I've been working on the QuadControl MCU, the intention of this is to have a cheap, easy to use and expandable control board for Quads and Hexacopters. The features are as follows:

ATMega640/1280/2560 Processor, dependent on needs, the first prototype will have the 640 as it is cheapest - they can all be used on the same PCB as they have the same footprint and fuses etc. The intention is to use the 2560.

ITG3200 3-axis gyro.

ADXL345 3-axis accelerometer.

9 Motor/Servo Outputs, the standard four for Quads plus another two for Hexa's and three for camera stabilisation.

8 Receiver Inputs.

FTDI/ISP Connections for programming and bootloading.

Expansion capable, for further I2C sensors and a 3.3V GPS.

Small Footprint, at just 38x54mm it is about half the size of an Arduino Mega2560, and significantly less tall.


The first version of this has now been successfully test flown on my quad. All features appear to be working, which is promising! The board is designed to mimic an ArduinoMega2560, so will work perfectly with MultiWii and Aeroquad code - ArduPilot is, however, untested as I'm unfamiliar with it. I'm looking for a tester or two to help me verify the design (specifically with ArduPilot and on a Hexa). As there are two small issues with this design (FTDI pins aren't in the correct sequence/tracking error) I can offer it at cost price.


I'm now in the position of looking to produce more boards, and was wanting external input. What features would you like to see on a board like this?

Read more…

Connecting the FPV System Together

This week I connected and ground tested my FPV system. Its a very basic FPV system, cheap and won't be a long term solution, but I just wanted to get started in FPV and learn from mistakes/learn what I like/don't like etc. And there isn't as much at stake if I crash/lose it!

FPV System: http://www.hobbyking.com/hobbyking/store/__13443__900MHZ_1500mW_Tx_Rx_1_3_inch_CCD_Camera_NTSC.html

Monitor: http://www.airaccent.com/8gb-jxd-990-mp4-mp5-player-silver-p-8210.html

Read more…

Death of a Feigao

feigao01.jpg

feigao02.jpg


The $30 Feigao motor we got in May 2009 finally dies when hitting a piece of wood, after already being on the ground. It was a FeiGao 5300kV 17g 141g thrust. Today, it's $34. Obviously, it's going to cost a lot of money to fly such a large aircraft in such a small space.

Really thought that motor would last forever & the very existence of the project seemed just to make use of it.

We did find the horizontal velocity wasn't being calculated in the previous flights. After fixing velocity, the vehicle showed signs of being able to stabilize horizontal motion, though not return to the target point. Altitude hold was still nowhere close.

There are 3 options:

1) Build a smaller aircraft, using a recycled toy motor.  It would use a smaller battery & new circuit board.  It would have a shorter flight time, not support lifting a POV attachment, & would be more expensive in the long term.  The 1st copy would be free & it would be easier to fly, indoors.  Replacing the motor & propeller would require buying complete toys, since those power systems are insanely expensive from plantraco.com.

2) Get an EDF for the current airframe.  It would potentially be crash proof & have faster throttle changes.  It would have shorter flight time & its resistance to crashes is unknown.

3) Get another Feigao & make it a pusher instead of a puller.  A pusher alone should eliminate shaft breakage, but have an unknown effect on propeller breakage.  Flying indoors would definitely continue to be virtually impossible.

Read more…
Moderator

RCAPA petitions the FAA, now its time to act.

bio_peggy.jpg

Let the battle commence, people will be getting bored of me pushing this issue. But if you ever want to turn a dime with a UAS in the USA or have sensible rules for flight you had better start making a noise.

Patrick Egan starts his article in sUAS News like this

RCAPA cites incongruities in the UAS ARC charter and what is transpiring as part of an alleged “public process”. The charter and membership roster FOIA requested by sUAS News is applicable and of concern to the small business, end-user and academic community stakeholders. This egregious oversight is yet another example of what many in the global airspace integration community view as subpar leadership and questionable administrative actions taken by the UAPO (Unmanned Aircraft Program Office.) These and other purported irregular practices have been highlighted and are not going unnoticed by elected officials. It begs the question, at what point do we as taxpayers say, enough.

A letter to the FAA which is so far unanswered is also there.

This is just the first step, the NPRM process is ever closer and louder noise will be needed then.

RCAPA is free to join find them here and perhaps consider a tweet if you do such things.

Here is a copy and paste tweet.

HEY FAA UAS in the NAS today the RCAPA way suasnews.com/2012/01/11217/… #FAA #UAS #UAV #diydrones #suasnews #AUVSI 

Join the Facebook page here http://www.facebook.com/groups/317984811558233/ and add support

Finally LinkedIN http://www.linkedin.com/groups/RCAPA-4230773

Lets try and make this Friday the 13th an interesting one in Washington.

Read more…

Getting six fly modes on Futaba T10CAG transmitter

We use for example CH5,switch C-3positions and switch D-2positions.

Settings:

1. Transmitter END POINT menu-GEAR -100%3689440774?profile=original

2.SUB-TRIM menu-GEAR -0

3689440674?profile=original

3.AUX-CH SELECT menu –CH5-Ls1(Logical switch)

3689440712?profile=original

4.LOGIC SW menu.Settings as shown on left.

3689440791?profile=original

 5.PROG.MIX1-8 menu choose mix 5

3689440685?profile=original

 6.P.MIX5  page 2/2 settings as shown

3689440808?profile=original

7.GYRO SENSE menu settings-CH5 and switch C as shown.

3689440728?profile=original

 8.GYRO SENSE  menu position 2 to ON.

DSCF9571.jpg?width=500

 9.C switch up,D switch up and set 68%.Pulse with in this set is 1166µs.

DSCF9573a.jpg?width=500

 10.C switch middle position,D switch up and set 48%.PW-1264µs.

DSCF9574a.jpg?width=500

 11.C switch down,D switch up and set 16%.PW-1423µs.

DSCF9575a.jpg?width=500

 12.P.MIX5 menu tab2/2 turn MIX ON.

DSCF9593.jpg?width=500

 13.P.MIX5 tab1/2 C switch down,D switch down and set -(minus)71% at poin5.PW-1554µs.

DSCF9582a.jpg?width=500

 14.C switch middle,D switch down,set -(minus)76% at point1.PW-1683µs.

DSCF9583a.jpg?width=500

 15.C switch up,D switch down and set -(minus)71% at point5.PW-1814µs

DSCF9585a.jpg?width=500

 16.Now P.MIX tab2/2

DSCF9586.jpg?width=500

That's all.There are other ways to do it,no doubt.

Read more…