Blogs

ENJOY GUYS IT'S SUMMER TIME !!!!!!!!!!!!!!!!!!!!!!!!

After reading several blog posts and discussions about folk having startup issues with ESCs, APM2s, etc, I thought it prudent to build a simple servo tester to allow ESC checks sans APM functionality. The new issue of Make Magazine, #31 (I did a discussion post last week after the mailman delivered it) has a section on servos and their function. It included a common manual servo tester/driver.

I had everything needed to build it in my stash except a 50K pot  that was less than 10 turns. A quick trip to ebay and $5 later got me 5 pots.. delivered in less than 5 days!

Why, you say, didn't I just buy a premade servo tester while I was on ebay? In general I like building things rather than consuming things. If you started with my first blog posts, you may recall that I buy where it makes sense and build when it pleases me and I have the parts on hand.

In the case of my tester, I know and understand how it works. I didn't take pictures of the scope outputs because the circuit is so well known and there are much better sites that can show you servo drive theory. Go consume them for details. ;-)

How, pray tell, did I determine the CCW, CW direction of the motors without installing the props? I ran the motor at the lowest speed adjustable with tape on the outrunner section of the motor. My finger served as the direction indicator.

Motor 1 was fine CCW. All the others required a lead swap to obtain correct rotation. This process also allowed me to run each motor up to the max my simple tester provided. Listening for bearing knock, grind or other mechanical issues that might have crept into the build was also part of the process.

One thing that is for sure, we need some type of kill switch on these machines. I haven't put much thought into it but it would be a grand safety feature for these birds.

Next up I wanted to verify the output power of the ESC to the APM2. The simple tester worked so I knew it was in the range for the circuit design but the APM2 is a little more particular than a 555 circuit. On a previous trip to the local hobby shop an Electrifly Power Match power meter had followed me home.

The power meter has Rx/Tx inputs to act as a voltmeter for those supplies, perfect for what I wanted to know. The ESC may not have an adjustable output (like Castle Creastion units) but the 6 millivolt low value should not be a problem if the ESC holds steady.

The Arducopter assembly manual, if read sequentially, led me to believe that the power to the APM2 did not require the JP1 jumper. It would not power up as shown in the assembly manual. Further reading indicated that JP1 is the default mode. I tested the APM2 with a USB cable and it powered fine. Back to the PDB lead, JP1 installed and...

hurrah! Going for the gold I added the Spektrum power input. The receiver modules lit up looking for a bind (not shown in the above pic). The Tx was in the house so I declared victory and called it a day.

Little steps add up and now the ESCs are direction correct and I can begin to integrate the APM2 software and bind the Spektrum Rxs with the Tx.

From Matt Waite's Twitter feed:

The now mostly put together Drone Journalism Lab at @Unl_CoJMC ... as seen from a drone:

I've just finished the build and will begin early full up integration testing in the next day or so on NTNS-2.  This is a highly modified Stinger 64 with APM2.  There are really 2 airframes.  One is for flight testing, gain tuning, learning a little about APM2.  I have to admit that there have been several issues.  The two that i know that I have are the flash card slot being a bit less than tight, perhaps some formatting issues -and- the stock GPS lock issue.  For my installation this doesn't seem to bother time to 1st fix, but I am loosing lock in flight, dropping satellites.  I am NOT using a downlink, have the jumper removed, and power is being applied to the input and output sides with a Castle BEC Pro set at 5.05V.  SW version is 2.40.  Of course no red wire from the ESC.  The GPS is somewhat masked by some wires and the EDF mtr wires run just behind APM down to the fan.  It's not ideal for EMI.

Not to worry since this isn't the objective configuration and I just "score" APM when it has lock and the altitude is reasonable.  My 100 mph Stinger flight test bird:

Here's a picture from the Stinger HAB build.  It's pretty tight inside the bay:

Some of the BOM:

2-Castle BEC Pros (5.3 and 12V)

3-Omega Kapton heaters

1-external relay + helpful external LED

3-Airtronics 94761 servos for flight control

1-analog servo for the sailplane towhook release

APM2

Venus GPS/regulator/logic level converter

SparkFun datalogger

ReplayHD 1080p (heated) and externally powered

4s 5000 mAh battery

airspeed probe and pressure sensor

voltage and current sensor

Airtronics 10ch rcvr, Airtronics SD-10g TX

Very much modified Stinger 64 airframe (the only inexpensive component)

BRB APRS

I'm about 1/2 # lighter than NTNS-1; 1200g Kaymont

Total weight is 3# 2oz vs. the flight test bird at 2# (identical XCG and flight control setups)

Ballast is 2.3oz in the forward bay.

The result:

Testing, SW version catch up/merges, HIL testing with FlightGear/X-Planes, Temperature testing with APM1, duration testing, log testing...camera testing.... to follow.

From Diginfo.tv. Those are the gnarliest motion capture dot-holders I've ever seen. Why out on sticks? A commentor says they're using a motion capture system that's just a fraction of the cost of a Vicon. Anybody know anything about that? (Maybe someone who can read Japanese and can navigate the Chiba U website) 

The Nonami Group at Chiba University is developing drone robots for information gathering, and the group has demonstrated four multi-rotor helicopters, flying in formation using image processing.

"The cameras capture the markers, and send all the images to the host computer, which calculates the position and attitude. Positioning can be done to within 1 mm. The control frequency is 100 Hz, so position and attitude are calculated every 10 ms, to prevent collisions."

Each helicopter weighs 300g, and can carry a payload of 500 g. Currently, each has a 250 g battery, so they can carry cameras and other devices totaling 250 g.

"The current demonstration is an attraction, so it might be even more fun to have ten of these flying. Also, when they're actually gathering information outdoors, the more there are, the faster they can obtain information. So we're thinking of using formation flight with a commercial version."

"It's very difficult to create mathematical models for this type of drone. But we do quite rigorous modeling, with strong nonlinearity; that makes the models complicated. But we've designed a controller to match that complexity, and we're verifying that the drones can actually fly in a stable manner."

"On July 5, we took part in an emergency drill by the Police Department. The scenario was an explosion at a chemical plant. Our mission was to find out if people were on site, and return. We succeeded very well, and the Police Department said they'd like to introduce this system. It could also have lots of other applications. For example, it could be used to monitor volcanic eruptions, or to inspect power lines."

Interesting these folks are able to obtain permission to use a drone for a commercial endeavour, or did they?

This appears to be filmed in the US, so the FAA rules, should be applying to them too, right?

We're within a day or two of releasing ArduCopter 2.6.1 to the public in the Mission Planner. It's the best performing code we've flown and the waypoint accuracy is really impressive. You can check out Marco Robustini's video above to see an long-distance waypoint flight, some tight loiter at 5:30 (holding in a 1m box!) and a fun demo of autorotation.

A full list of changes is here, but they include:

Performance improvements:

• Better loiter, especially with the new 3DR uBlox GPS. Check out the video from Marco above!
• Better yaw control
• Better DCM implementation, resulting in noticeably smoother flight
• Better camera control, including improved setup in the Mission Planner.
• Etc

Bugfixes:

• Fix to dataflash erasing, which should resolve an issue some users were having
• Fix some MAVLink commands
• Fix Circle command
• Fix some units
• Etc

Front

Back:

Front:

Back:

Imagery from a multiwii quadcopter. Described by Forbes:

Someone going by the name Tretch5000 has posted a truly haunting FPV (First Person Video) portrait of Detroit that mixes the lush greenery of the city’s Belle Isle with the decay of abandoned buildings. He used a camera mounted on a personal drone similar to the ones the U.S. Military uses to soar high above the landscape and skip along the ground, taking in the city’s ruins.

A new company called Rotary Robotics is planning a $100 drone, controlled by a smartphone, for aerial photography. They're planning to launch something in the $250-$300 range, with the price falling later. They call  it "Drones for Peace" (tagline: "@DronesForPeace provides eyes for the everyman. Tyranny has no place to hide.") and are a finalist in the MassChallenge competition for startups. A Kickstarter campaign is also planned.  

We are currently developing our first product, a $100 surveillance aircraft designed to bring airborne imagery to the masses. This aircraft functions as a flying point and shoot camera, allowing any operator to gather aerial photos or video with no prior training in aircraft or RC planes. The aircraft is preprogrammed through a map based application on your computer or smartphone.

The user selects the locations which are to be photographed and throws the aircraft. The plane automatically flys to these locations and takes the desired photos, after which it returns to its starting location and lands. The user can then download the photos from the aircraft onto their computer or other mobile device. The photos can be stitched together into a map or used for any desired photographic purpose.

(Via Co.Exist)

Maybe somebody heard about IMAV - International Micro Air Vehicle Conference and Flight Competition. This year it was held in Braunschweig, Germany, 3-6 July. I was there and presented a paper about my project - SmartAP. Also our team took part in flight competition. Here is a short summary of the trip.
In general, teams from all European countries took part in conference and competition. Moreover, there were people from the United States, Australia and China too.

Ok, let's start. We got to Germany by plane, so the quad was disassembled and packed to prevent it from damages.

A couple of hours was spent on its assembly.

The next day was the first conference day. That day we (me and my co-author) made a presentation in "Guidance, navigation and control" section. The subject of my paper is "Micro Air Vehicle Autopilot For Commercial and Research Purposes":

The flight competition is divided into two parts - Outdoor and Indoor.
Each of both parts is also divided into two groups - Autonomy and Dynamics. In Autonomy one a vehicle had to fly far enough, recognize horizontal and vertical targets, then fly through arches, drop a ball and make precision landing. The Dynamics section required to demonstrate as many time as the vehicle can pass through arches in a certain amount of time (4 minutes).
Only FPV or fully autonomous piloting were allowed.

We took part only in Outdoor, generally because of our vehicle is too big to compete in indoor.
The good thing that we used the quad with our custom autopilot, presented the day before at the conference.

So, here is our ready to fly quad:

And here we go:

Here are some photos about what the other teams have:

Very interesting solution (by the way, based on Ardupilot Mega):

Our team enjoying the flights of the other guys:

The next day was dedicated to Indoor Flight Competition. Several teams took part in fully-autonomous mode. However, generally, participants flew in manual mode by FPV.

The place for the competition:

An only team, which took part in Indoor Dynamics in fully-autonomous mode. It was really impressive:

The other teams:

The last day, as well as the first, was dedicated to paper presentations.

As for the main trends, the most important subjects at the conference, in my opinion, were dedicated to autonomous navigation based on onboard video processing or laser range finders. Significant part of papers was about aerodynamics, especially about the researches on the new concept types of micro air vehicles.

Approximately half of participants in Outdoor Autonomy took part in autonomous mode and another half in manual FPV mode. However, in both Outdoor and Indoor dynamics almost all the teams took part in manual FPV mode.
It's very pleased to see the efforts to fly autonomously, but almost every team crashed at least once during their flights. Therefore, manual FPV flight remains to be more predictable and reliable so far. But likely so far...

Kirill

In case you weren't able to catch the webinar, here's a screen capture of the session.

I thought the webinar was great -- there were a few technical glitches, but the material was nicely organized and the participating developers did a great job of stepping through the code.  I enjoyed it and learned a lot. 

I thought I was capturing the session in super hi res mode, but apparently I suck at screen capture and the resolution isn't great; but it's good enough for following along what the speakers are saying.  The beginning was cut off as I was trying to figure out how to turn on the sound.  If someone has a better capture let me know and I'll add it here.

Update: now using much better quality screen capture by YureZzZ.  Thanks YureZzZ!

Many thanks to Andreas M. Antonopoulos for putting together a great outline for this webinar.  I'm certainly looking forward to seeing more of these! (private note to Andreas: SITL!)

 From IEEE Spectrum:

The reason to go with little tiny rockets for microrobots (as opposed to a more conventional propulsion system powered by batteries) is fairly straightforward: energy density: you can get a lot more energy per unit of mass from a rocket than you can from a battery. These particular rockets use APCP (Ammonium Perchlorate Composite Propellant), and each has multiple stages, with integrated "delay charges" that modulate the thrust from the rocket by significantly reducing its output for up to about five seconds. Here's what the design looks like:

As IEEE Spectrum aptly titles this video:

"BWAHAHAHA DID YOU SEE THOSE PUNY HUMANS FLEE IN TERROR?!"

This is an awesome compilation of my best FPV flights from the first half of the summer since I moved home to Colorado after graduating from law school in Virginia. Lots of low-level proximity action and beautiful scenery from the Colorado low lands south of Denver. Highlights include Daniels Park, Mount Herman in Monument, Castlewood Canyon, and the new Rueter-Hess Reservoir in Parker.

Just look at the complexity (and size/weight) of this mechanical gyro! Now that functionality (times nine--three gyros, three accelerometers, three magnetometers) is performed by a $15 chip smaller than your fingernail. 

From Hackaday:

When we posted our call for rocketry hacks and builds, we expected to see a few altitude sensors and maybe a GPS module or two. Apparently, we forgot similar hardware is very popular in the remote-controlled aircraft world, and can be successfully added to a rocket as [Kevin] and his ArduPilot equipped J motor rocketshowed us

The ArduPilot is a small Arduino comparable board designed for UAVs, quadcopters, and other whirligigs not powered by rocket motors. To get real-time telemetry from his rocket, [Kevin] attached a GPS receiver and an XBee transmitter. When launched on an H165 motor, [Kevin] was able to keep a radio lock on his rocket, allowing him to pull down data in real-time.

There are a few drawbacks to using the ArduPilot to collect flight data; the ArduPilot only reports ground speed, a somewhat useless feature if the vehicle is going straight up. Also, there is no way for [Kevin] to record data to an SD card; the ground team must be able to receive the XBee, lest bits of data go missing. For most rockets the radio issue shouldn’t be a problem. [Kevin] launched the same hardware on a J motor and was able to receive data from 3600 AGL.

From Hackaday:

After [Pyrofer] built a quadcopter, he purchased a cheap 6-channel transmitter made in China. Unfortunately, that transmitter was terrible so he took an old PS2 controller and built his own.

For his build, [Pyrofer] broke out the analog sticks and wired them to an AVR housed in the handle of the controller. The AVR sent commands to a 2.4 GHz radio transmitter powered by a small LiPo battery. With the addition of a few tact switches behind the shoulder buttons of the controller, [Pyrofer] has four axes of control with a few buttons for changing modes on his quadcopter.

This build really doesn’t hold a candle to some of the awesome DIY RC transmitters we’ve seen, but we’ve got to give [Pyrofer] credit for coming up with a very simple and easy build. Just about everyone has a PS2 or XBox controller lying around, and with a few extra hardware bits it’s easy to bodge up a decent remote control.

[Pyrofer] used a project called Funkenschlag to generate PPM signals, so if you feel the need to replicate this project send it in when you’re done.

I just wanted to share a mapping mission I ran last week with the E382 from Event 38 (my company) and processed with DroneMapper.com.

The reason these results are somewhat noteworthy is the amount of time it took to make this. I pulled up to the flying field, setup the plane in maybe 5 or 6 minutes. I hand launched the plane, flew around manually for exactly 5 minutes, taking 110 pictures in that time. Brought it in for a quick landing in some bushes then I packed up and went home. At home I uploaded the images straight to DroneMapper without even reviewing them. A few hours later, DM came back with really awesome results. All of this took just a few minutes of my time not counting the drive to and from the field.

My setup on the E382 is as follows: 

- Skywalker 168cm Airframe

- APM 2.0 with ArduPlane 2.4

- 3DR Telemetry Radios 915MHz

- Canon Powershot SX230 HS with CHDK

The camera is really what made this so quick.. with built in GPS all the images are geotagged automatically as they're taken. This mission was actually done to see if it could keep a GPS lock for the entire flight which it did. Having the images geotagged and processing them with DroneMapper returns files that can be analyzed (as in the image above) for things like the elevation profile of any path, the length of a path, the area of a field and so on. There are nice tutorials on how to get started with that in the DroneMapper FAQ.

Measuring the length of a trail

Measuring the area of low lying vegetation

Extracting the coordinates of a point of interest

So sonar was officially back again for another swing at a home run, with a lot more clockcycles.

AP

It was a hot one.

Unlike the last attempt, beacon triggering over USB was neither an option nor accurate enough.

So that was propagation delay over 10ft using a hard wired trigger & 266khz sampling on a PIC.  It was extremely accurate but not reality.

Past attempts to synchronize beacons with radio packets were very ineffective.  That requires a mode of communication with a constant latency.  USB was good enough for 1 meter accuracy.

The 802.11 system currently in use is even less realtime than the USB system in the old days.    The aircraft would use IR for a trigger.

It came from a chinese toy.

The IR emitter was toggled at 38khz & ran on 1.5V.

The intended IR trigger naturally failed.  38khz modulation was too erratic.

That leaves only a draconian complex system involving a dedicated, hard modulated 900Mhz radio set. The radio set would be used to send triggers using a hard realtime bit banging protocol.  An 802.11 radio would be omitted from the ground station.

The MRF49XA radio in raw mode allows a trigger to be sent with 256khz precision.  Getting raw mode requires clearing the TXDEN & FIFOEN bits in the GENCREG register.  Then, the FTYPE bit in BBFCREG needs to be set for analog filtering.

Getting the maximum bandwidth requires driving the FSK/DATA/FSEL pin on the transmitter to 0 or 3.3V & reading the RCLKOUT/FCAP/FINT pin on the receiver.  You're looking at a lot of pins for a full duplex radio set.

The FSK pin outputs a lowpass filtered voltage which maxes out at 115 khz.  The FCAP pin outputs the unfiltered voltage at 256 khz, so for a sonar trigger, you need the 256 khz voltage.  The voltage is not linear, but either 0 or 3.3V.  You would need a codec to get audio through it.

It's important to get the GENCREG register address right, which happens to be 0x80, exactly the same as the TXDEN bit you need to disable. 

Not as blazingly accurate as the hard wired trigger. 

An original graph from 2009.  The 2 graphs covered the same distance.  No dramatic improvement is jumping out from the extra firepower, but the original USB clock synchronization can be considered very high quality.

Even with the waveform massively oversampled at 266khz, things weren't decisively different than the experience with 74khz.  The massive signal processing developed in 2009 was still required.

The quest to reduce the signal processing to something that could be put in a simple analog circuit showed the comb filter is required to suppress noise.  The integral is required to further separate the pings from the noise.  Not sure why anyone thought a simple analog circuit could do it. 

A PIC at 64Mhz would be just fast enough to do all the required processing for 1 channel.  I actually implemented it on a PIC in the last week, to show how much free time unemployed programmers have.  At 40Mhz, it maxed out at 180khz.  Also, with the comb filter, subtracting a 1/2 wavelength worked better than adding a full wavelength.

A 16 bit ADC might do a better job & be $22 for anything in the 216khz range.  More gain with less noise would do the same thing.  Sort of sad to see the amount of mathematical fudging which was done in 2009, in the belief something workable was just around the corner, only to have it lead nowhere.

Completion of the next sonar board using 168Mhz ARM revealed some interesting nuggets about the STM32.

It works with only 1 VCAP, VDD, & VSS connected, greatly simplifying the routing.  The VDDA & VREF+ can be connected to a VDD pin.  Only 1 VSS is required.

ADC sampling can go in the 600khz range with no obvious noise issues like the PIC.  8 bit sampling goes a lot faster than 12 bit.  While it can do a lot more with audio than video, it's still very limited in the 300khz range that you need for sonar, so you'll be hand optimizing.

Function calls kill it.  As much as possible must be inlined.  Those convenient GetFlagStatus calls need to be replaced with inline ->SR calls.

Some operations go a lot faster with unsigned than signed variables.  1 operation that signing killed involved multiply & divide.

The packing order of variables affects speed.  Splitting up a bunch of frequently used variables with large, infrequently used buffers slows it way down.  Having all the frequently used variables together speeds it up.  It's a caching issue.

So with the ARM screaming at 329khz per channel, that was propagation delay with the sensors 3" apart & the transmitters 2ft away, on the bench.

That was the propagation delay over 10 ft with 3 sensors.  That actually looks equivalent to the PIC sampling at 266khz.  1 of the sensors has 4x the gain of the other 2, without showing any obvious difference.

The position calculation in centimeters once again lost a lot of precision.  With the 12V emitter & super fast sampling, it was almost omnidirectional, but the precision dropped as the horizontal distance increased.  This was the 1st time horizontal accuracy was seen improving dramatically with wider sensor spacing.


The pings were 8 Hz.  The sampling rate was 329khz at 8 bits.  There's no point to using the 256khz radio bandwidth.


Calculating the position has been done with very slow, trial & error pythagorean calculations on the ARM.   Despite its floating point support, there hasn't been enough incentive to load the math library on the flash, to do a fast trig solution.

The position is only calculated on the ARM in case it could be sold as a standalone position calculator.

Ground based sonar still isn't going to have the all out range that ground based vision could have.  For 1 vehicle flying in a small room, it might have the immunity to the environment to come out ahead of vision.  It's not as compact as an equatorial mounted camera, but has a lot less fabrication & costs a lot less.  It won't need a high speed connection to the computer.

In Feb 2010, an amazing amount of work went into getting Marcy 1 a sonar guided autopilot, in the belief that the real M.M. would have seen it in person.  It turned out Her attention was impossible to get for any normal guy & there wasn't a snowball's chance in hell of Her ever watching a normal guy fly a UAV.

Even if sonar worked in time, it was an obsurd campaign.  She had many celebrity suitors & is now settled down with a famous producer in LA, resigning from the USAF in 3 years.  In that case, it would have been truly awful for Her if the sonar panned out in time.

Since we've got our own quad platform mountain we're slowly starting to progress further into mountains. The neat thing about quads: You can really "interact" with people. Great fun :)