Blogs

GE's new advertising campaign is called "Air Show" and it consists of printing user-submitted model airplane designs on a Makerbot 3D printer. They're one of us!

It's also kinda adorable.

Here's a scene from Philanthropy

Awesome Battle is Awesome! (MGS: Philanthropy) from Hive Division on Vimeo.

Hello everybody!

WHO'S THIS?

I'm Giacomo and I'm the founder and coordinator of a Venice area-based filmmaking collective known as Hive Division.

We gathered around a feature-lenght, no budget fanfilm, Metal Gear Solild: Philanthropy, in order to put together our different skills, gain visibility and grow up as a team. The film was released in September 2009 and had a huge success of public, accumulating more than 3 millions overall views and represents the base of know-how on wich we're currently building our original narrative projects (the first one will be announced in September 2011) and our path in the video production business.

and here's a video we shot for an institutional client

Provincia di Treviso - Ti resta nel cuore 2010 from Hive Division on Vimeo.

Some time ago we met Roberto Navoni,Laser Navigation's CEO and coordinator of the VirtualRobotix Community in order to discuss a future Hive Division project (Wave) for a sci-fi feature that would require an agile camera platform, something beyond any available crane, steadycam or cablecam.

The multicopter frenzy at the time was still building its momentum, but it was clearly a cost-effective approach and, therefore, the best fit for our needs.

A series of meetings and brainstormings with Roberto, though, made clear that the end results we aimed at was not just to get a platform we could use for the feature film Wave, but a high performance flying camera that would suit any indie video production, virtually replacing the helicopter in most of the situation. The project than turned into a proper R&D cooperation between Hive and Laser, one that our lack of immagination forced us to call the "Wave Camera" :)

In Hive Division, the guys following this project are

1. Me
2. Alberto, Hive's 3d Team, graduated in aerospace engineer and future Wave pilot
3. Mattia, Hive's DOP, graduated in multimedia technology ad future Wave camera operator

WAVE CAMERA

Thanks to the HDSLR revolution, many little companies around the world are currently working at such devices and some DID achieve remarkable results, but we always feel like something is missing (the incapacity of producing anything but wide angle shots, the lack of proper focus control etc).

We want to create a new one, built specifically for indie filmaking.

We want our platform to carry heavier equipment, better optics and to carry them faster and further than what existing platforms are currently able to do. We want our platform to be well integrated with its "eye" and to give filmakers-on-a-budget a flexible and powerful tool for their needs.

Instead of trying to create a Predator-sized UAV without any meaningful ROV experience, we decided for a step-by-step approach in order to softly land on any critical aspect of such a project.

The first two platform that Roberto and his company prepared for us are:

1. A light, relatively cheap quadcopter that Alberto will use to perfect his ROV skills
   
   
   
   
2. A medium-sized coaxial hexacopter that will be used to lift our HDSLR and to gradually prepare our wishlist of features for the long-term developement of our ultimate flying camera :)
   
   

We'll start testing both platform around the end of august/september, and we plan, together with Roberto, to keep you Virtualrobotix guys posted about our developements. Any suggestion or feedback you'll be willing to provide will help us shape this platform.

I hope you'll enjoy following our project :)

http://www.virtualrobotix.com/forum/topics/wave-camera-project-by-virtualrobotix-hivedivision-join-force

I personally don't like these constants LEDs very much,

how cool is that:  a real xenon strobe like in real airplanes - for your RC plane !

I've flown with it last evening - it was AWESOME !  

draws much attention...

can get it here

that's the effect it has +/- :

A good post from the AMA government relations guys, prompted by the Wasp ArduPilot-powered wifi sniffing UAV we wrote about earlier:

 

Like any other new technology, in the wrong hands and for the wrong reasons, its use to cause harm can potentially overshadow any intended use for good. This is a quandary that beleaguered Albert Einstein until his death in 1955, and for centuries societies have had to balance the potential for good against the potential for harm with everything from motorcars, to aerial flight, to the Internet. 

However, turning our back on UAS technology is not the answer. In doing so we may well find that we have boxed ourselves in, missed out on significant opportunities and left behind by what is sure to be a huge emerging industry. AMA must proceed carefully to ensure the legitimate aeromodeling community is distanced from the potentially negative aspects of UAS while maintaining its posture as a leader in scientific development and aeronautical technology.

Recently I purchased an inexpensive usb based oscilloscope to help me do some low level electronics debugging.  Owning an oscilloscope is so cool I just had to tell everyone about it!  And the price of these USB-based oscilloscopes are in range of many hobbiests.  Now I'm kicking myself for not buying one of these years ago.

The above screen shot shows the output of an ATTINY13A microcontroller (similar to what the ardupilot uses for their fail safe / manual override circuit.)  My test code reads a PWM signal in (via an interrupt service routine) and generates a new signal out on a different pin that mirrors the input signal.  I can see exactly what is going on with both the input and the output pins using my cool new oscope.

I'm learning as I go (just like everyone else) but I thought it would be fun to share my experience in a bit more detail and hopefully encourage some people here to also take the plunge.  I have many more details and screen shots posted at my personal blog here:

http://gallinazo.flightgear.org/technology/how-to-be-an-electronics-whiz-on-a-small-budget/

Free-flight glider competitions, which don't use RC control, usually use mechanical compasses to keep the glider pointed into the wind. But an autopilot can do it even better. Tom Pycke modified his Gluonpilot autopilot to do this. Cool!

On request, a special version of the gluonpilot has been created to be used in F1E (free flight gliders) competition.

This is how the gluonpilot adaption works:

• A 3D magnetometer is connected to the 3V3 I2C port.
• Before launch, the model is pointed in the correct direction and the SMD button on the PCB is pressed. From then on, the output on servo 1 is proportional to the "heading error". With a rudder servo connected to servo 1, the plane will always fly in this direction.

There's a good article in Flight Global today about the rise of "optionally-piloted vehicles" (OPVs), which are plane that can fly either with or without a pilot, such as the L-3 Mobius shown above. Why would anyone want that? A few reasons:

--You can fly them in domestic airspace, where there is not currently a workable approval process for commercial UAVs

--You can use a pilot to fly them over civilian areas to get to a military theater, without having to transport them in another vehicle, as is currently the case for for all military UAVs.

--Much better field of vision with a pilot onboard, when that is required

From the article:

There are at least 26 models of OPV flying today, most of which are still in testing, and many of which are technology demonstrators or testbeds.

OPVs fill a niche role; they must be large enough to haul a pilot and a useful payload while piloted, but provide the endurance expected of a similarly-sized UAV when unmanned. Most similar UAVs are medium-altitude long-endurance (MALE) models - and so too are the OPVs.

Northrup Grumman's Firebird

I've seen Blackbird helicopters converted to OPVs, and indeed these seems to the way they're all going. From the article:

The US army is planning to convert almost all of its massive helicopter fleet to OPV control schemes. "Over the next 25 years, the [US] Army aviation shifts from being almost entirely manned to consisting of mostly unmanned and OPV," states the army's aviation planning document - the so-called roadmap.

Here's my latest (and yes need to work out how to do the mix in APM, as all this is on Open Pilot, using 4 motor channels)

Perfect for Aerial Photography and FPV, camera will mount under the front, just behind the landing gear

There's a good piece in the Economist about how a FCC screwup allocated frequencies to a wireless Internet firm that are adjacent to the GPS frequencies. Now the firm wants to roll out its network, and if the FCC lets it go ahead, we're going to all have to start soldering filters on our GPS modules if we want them to keep working. (I hope wise minds will intervene and ensure that this doesn't come to pass, but it's hard to have confidence in the political system at the moment).

Here's the root of the problem:

The ultimate source of the trouble is a decision made in 2003 by the Federal Communications Commission (FCC) to grant special dispensation to a broadband satellite operator called SkyTerra, allowing it to fill gaps in its coverage by means of ground-based transmitters. SkyTerra’s chunk of spectrum (1,525-1,559 megahertz) abutted a crucial frequency (1,575 megahertz) used by GPS satellites. However, SkyTerra’s signals being mere whispers from space and its few proposed ground stations designed to operate at low power, any threat to GPS was dismissed as highly unlikely. 

Everything changed when Harbinger Capital Partners, a New York-based investment firm founded by subprime-mortgage billionaire Philip Falcone, bought SkyTerra in 2010 and renamed it LightSquared. For Mr Falcone, the attraction was three-fold: SkyTerra’s swathe of under-used frequencies; its licence to provide a nation-wide internet service; and, above all, the FCC’s waiver allowing it to use ground-based transmitters where satellite reception was poor. 

Mr Falcone quickly persuaded the FCC to rewrite the former SkyTerra licence. Instead of being conditional on offering an internet service primarily by satellite, with ground stations filling in only where satellite coverage was inadequate, the revised licence accepts that the network will rely almost exclusively on terrestrial transmitters.

And not just low-powered ones for serving inner cities. The company intends to build a broadband wireless network comprising 40,000 base-stations across the United States. These stations will put out 15,000 watts apiece. Typical mobile-phone transmitters in urban areas radiate between five and ten watts. Even the 100-foot towers used in open countryside transmit no more than 60 watts.

A team of people who had worked at Joby Robotics, who were doing the UAV-as-energy-generating-kite thing we wrote about earlier (which I gather didn't work out, sadly), is trying to raise money on Kickstarter to turn their hybrid quad-plane aircraft into a commercial product.

The Quadshot is a remote-controlled aircraft we have created that melds advanced Open-Source hardware and software with a unique airframe design. It can both fly forward like an airplane and hover like a helicopter - but without the usual complicated, expensive, and fragile moving parts.

It uses the Lisa Paparazzi IMU, but isn't meant to be a UAV. Instead, the electronics serve as a pilot assist, and you can switch from copter to plane to acrobatic combo with a flick of a RC switch. $500 to pre-order the version with the IMU.

As this site becomes bigger and attracts more attention, I'd like to emphasize to new users and old that a big part of our mission is promoting and protecting responsible use of UAVs. We have encouraged regulators, defense organizations and law enforcement agencies to join this community to become better informed about what's possible with small UAVs, and many have done so.

If you are not already aware that what you say here may be read by police and regulators, you should be. They're here and are paying attention. I personally think that's a good thing, and I spend a lot of time with such organizations explaining what we do and inviting them to participate. Our message is this: the site is for peaceful, civilian use of UAVs, which is the big new area that we're collectively working to build here. Anything else is banned.

To make this as clear as possible, I've added the following to our site policies:

7) No discussion of illegal or harmful use of UAVs will be tolerated. Responsible use of UAVs is at the core of our mission. That means conforming with all laws in the United States, where this site is based, and insisting that our members elsewhere follow the laws of their own countries. In addition, we feel that part of our responsibility it to help the relevant authorities understand what's possible with amateur UAVs, so they can make better-informed policies and laws. So we have encouraged all relevant regulators, defense agencies and law enforcement agencies to become members here and even participate to help them do that, and many have. In addition, if we see any discussion of UAV use that we feel is potentially illegal or intended to do harm, we will bring it to the attention to the relevant authorities, and will comply with any legal request they make for information about users (although we don't know much that isn't public; see the next item).

8) Your privacy is protected, up to a point: This is a social network, so everything you write and post here is public, with certain exceptions: 1) Your private messages are private. Administrators are unable to see them, nor can anyone else other than the recipient. 2) Your IP address is private. We are hosted on Ning, which controls the server logs. DIY Drones administrators can only see your username and email address; they cannot see your password and do not have access to your account.

There are some nice new approaches on frame construction out there.

This Korean guy found a nice way to get more thrust and it has also a good open space in front.
Looks interesting to fly with cameras. I enjoy the idea. Sounds good. Don't you think?

There is also this other one "ButterflyCopter" with same idea but... 10 motors!!!

Here we can see how nice is the result of a camera aboard:

Source: http://www.kkmulticopter.kr/index.html?modea=kk&modeb=KKMulticopter

Cheers,

Sandro Benigno.

Hi all, On popular request, here's a short tutorial on how to make a low battery warning on my hexa with blinking leds, as you can see at the end of the following video :

EDIT : The software changes in this blog are now outdated and not necessary anymore.  For the new software see my new blog with much more possibilities (without using the relay) : U4eake's showleds, arming and low battery warning leds

Furthermore I'll use this as a reminder on what to change in my code when new versions come out :-)

First I'll give proper credit where credit is due, this code was originally written by Bill Sanford and posted on rcgroups here : Bill Sanfords running lights.  They are originally intended to be run with a brushed esc, so they can pulsate.

I never found an explanation on the 'attraction mode' leds on standard arducopters, so I modified Bill's code it a little and used the onboard relay to drive my hobbyking 12V leds :  http://www.hobbyking.com/hobbyking/store/__8941__Turnigy_High_Density_R_C_LED_Flexible_Strip_Red_1mtr_.html

I have a lot of them, so they draw much more current then the outputs of the APM can provide, but the relay has no problem with it.

General principle :

I have the leds setup as follows : on arming motors, the leds go on, indicating the copter is armed.  On disarming they go out.

When battery voltage reaches 10.6V the leds start blinking slowly (2 Hz).  From experimenting I know that I now have about 1 min of flighttime left with my battery.  You may need to experiment yourself to find out how much you have left.

When voltage goes down to 9.9V, it's really time to land (about 15s left) and the leds start blinking rapidly (5hz).  This is also the time when the copter will go into RTL, unless you modify the code (will get to that later on, see software, point 3. event.pde)

Hardware :

First the hardware.  I soldered a 3S balancing connector to the relay ports of the IMU as shown in the pictures. Yellow wire goes to pin AN0 on the imu.  Red wire goed to middle pin of relay.

PAY ATTENTION : on the 3S connector, swap the black and yellow wires if you use standard 3S balancing connectors !!!  Standard 3S balancing connectors have the black wire on the rightside end in the picture below.  On the imu however, the third pin is ground and the rightmost pin is AN0 which should be connected to +12V.  So swap the wires if you're using a standard 3S balancing connector or you'll invert polarity and damage your board !

Then on the other side of the imu, solder the ground pin together with relay pin 0 with a solder bridge.  Also solder a short wire, connecting the pin AN0 (yellow wire) to the right side relay pin (pin 1).  

Now connect Yellow to battery +12V and black to battery minus.  Connect red to leds+ en blue to leds-.  All leds should be connected in parallel to the red and blue wire.  Don't overdo it though, the relay must be able to handle the amps.  60 hobbyking leds (1m) is still fine.  If you want more, check ampdraw en relay specifications.

With relay in pos 0, the red wire (led+) is connected to ground, so leds are off.

With relay in pos 1, the red wire (led+) gets fed +12V comming from Yellow wire at AN0.

Furthermore AN0 is constantly connected to +12V from battery so it can monitor battery voltage.

Your hardware changes are now done.

DISCLAIMER : I assume if you do this that you have sufficient knowledge about soldering and electronics.  Even though I tried to explain as best as I could, I take NO responsability if you destroy your board doing this.  Do this at your own risk !

Software : These changes are no longer valid, see my new blog mentioned above for recent code !

You'll need to make the following modifications the the firmware and then compile and upload with arduino.

1. In ArduCopterMega.pde

Find the medium_loop() function and in it find case 4.  There is a call to the read_battery() function there. 

Insert a call to handle_relay_lights() right after the read_battery() call.  See red text below.

// This case controls the slow loop

//---------------------------------

case 4:

  loop_step = 5;

  medium_loopCounter = 0;

  delta_ms_medium_loop = millis() - medium_loopTimer;

  medium_loopTimer     = millis();

  if (g.battery_monitoring != 0)

{

  read_battery();                               

handle_relay_lights();

  }

  ArduCopterMega.pde is now ready.  Don't forget to save it !

2. APM_config.h

Add the following code :

#ifndef BATTERY_EVENT

# define BATTERY_EVENT ENABLED

#endif
#ifndef LOW_VOLTAGE

# define LOW_VOLTAGE 9.9

#endif
#ifndef MID_VOLTAGE

# define MID_VOLTAGE 10.6

#endif
#ifndef VOLT_DIV_RATIO

# define VOLT_DIV_RATIO 3.33

#endif
#ifndef INPUT_VOLTAGE

# define INPUT_VOLTAGE 5.26

#endif

 

// global variables for motor leds and battery monitoring through onboard relay 

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

I know the variables should probably be defined in parameters.h but upto now I've been too lazy to do so...  If you want to, pls do so, but bear in mind that it's an extra file to modify each time a new firmware comes out.

  That concludes the APM_config.h modifications. MID_VOLTAGE is when the lights start flashing slowly, LOW_VOLTAGE is when they flash rapidly and when copter goes into RTL.

You may have to experiment a little to find the right values for you.  See also the wiki about battery monitoring.

3. Events.pde As of version 2.0.38 this step is already implemented in Events.pde, no need to change it.

Since I now have leds to warn me when battery gets low, I don't want the copter to unexpectedly go into RTL cause my leds have been blinking and I didn't land in time.  One time when I was testing this, hoovering low with blinking lights, my copter suddenly took of and flew into the hedge.  Luckily I wasn't in between.

So I only want the copter to go into RTL when he's flying on an  automatic mode (auto, loiter), not when I'm in control.

Find the line void low_battery_event(void) in the event.pde file.

Change the whole function to look like this (red text changed) :

void low_battery_event(void)

{

gcs.send_text_P(SEVERITY_HIGH,PSTR("Low Battery!"));

if (control_mode > ALT_HOLD) { set_mode(RTL); }

}

I am thinking hard if it wouldn't be better (if possible) to change it into set_mode(Land); to have the copter land on an empty battery instead of attempting to get home with no juice left (which will probably end in disaster if the copter is more then 15sec away from home)

4. RunningLights.pde

Add the file RunningLights.pde to the directory where ArduCopterMega.pde is located.  This is a new file to add.   You can download it below.

RunningLights.pde

That's it !!!  Compile and upload with arduino, enable battery monitoring to battery volts in setup (type setup in CLI and then battery 3) or choose battery volts in mission planner -> hardware setup -> monitor.

Enjoy and feel free to ask questions ! 

That's a new fancy stencil printer coming in, beside one of our pick-and-place machines at the 3D Robotics factory in San Diego. All sort of new equipment is in place, including the new reflow oven, automatic glue dispenser (for two-sided boards), lots of smart feeders for the pick-and-place etc.

All this automation and high-quality equipment has meant a massive improvement in board quality and yield. Our aim is to produce the most reliable and robust boards in the industry, and this kind of investment will help us get there.

We'll be moving to an even larger (8,400 square foot) space in the next few weeks, in anticipation of ramping up with a bunch of new products.  If you're in San Diego and want a tour, ping me and I can arrange a time with the team there.

From a Forbes article:

We've written about this before, but I'm not sure everyone's seen the video. It's a really impressive production process. No doubt heavier than foam and possibly balsa, but that will improve over time with new materials.

What about this ARDU Hexa?

Carbon CNC frame

Aluminium standoffs

Titanium screws

etc etc



More pictures at: http://holco.picturepush.com/album/154602/p-Arduspyder.html

We did this project together. Mario for the ideas me drawing and routing.

Sold as a multiple rx buddy box, can be wired in a way that the rx is connected to the master input, the computer connected to the slave input, and if the computer looses it, you can switch to manual, overriding almost everything.

http://www.hobbyking.com/hobbyking/store/__18703__Wireless_Buddy_Box_System_Dual_RX_Controller_.html

An object oriented fork of the APM autopilot code supporting multiple vehicle types and with the goal of supporting multiple ArduPilot boards in the future (currently only ArduPilotMega).

Some clarification:

It started as an object oriented (C++) branch of ArduPilotMega. It provides an abstraction layer between the different modules of the autopilot so that they can be shared among different vehicle types. After several discussions, we on the development team choose not to use it as a base for ArduPilotMega and ArduCopter. Think of it more as ArduPilotMega++ if you like.

Currently ArduPilotOne supports: rover(full autopilot), quad (manual flight), boat(full autopilot, not yet tested), plane(full autopilot, not yet tested)

The quad full auto support will be online in a month or so when I have time to sit down with my arducopter again and get the rest of the gains. This isn't meant to compete with ArduCopter, ArduPilotMega, it is simply a different option if you want something that you can have the same code base and is object oriented. The quad/plane code doesn't have nearly as many options as ArduCopter/ ArduPilotMega, but for my research with multiple vehicle cooperation I want a platform where all vehicles run the same c++ code using different modules for unique vehicle differences. It is fairly extensible so it will be easy to add more options as needed.

Notes:

1. There is no command line mode.

2. You must run it with a ground station talking mavlink. If a mavlink packet is not received by the vehicle from the ground station it will go into a failsafe mode.

3. The main ardupilotone.pde sketch is meant as a template. You can easily copy it and modify it to your liking in a different sketch.

4. In ardupilotone.pde the vehicle configuration file is included. Make sure you include CarStampede.h if you want to test the ArduRover functionality. PlaneEasystar.h if you want to test the plane, BoatGeneric.h if you want to test the boat, QuadArducopter.h for the quad etc.

5. Feel free to make your own vehicle config file for your specific vehicle, you can use the others as a template.

Tech Specs:

memory: only 80k

speed: 150 Hz attitude loop, 100 Hz control loop @ 60% load

Hosting site:

https://github.com/arktools/ardupilotone/

Hello people, this is POLLUX my first BIG uav airframe, (it has a twin named CASTOR)...

Wingspan 4.2 meters.

Lengnt: 3 meters

TOW: 55 kg aprox

Engine 100cc twin cilinder.

what do you think??????

Going to be ready really soon (i hope)