All Posts (14056)

Sort by

Michael's Dispatches 4 U

On http://www.michaelyon-online.com/warthog.htm Michael Won wrote:

UAVs are very useful, but come with sharp limitations. They are great hammers when you need a hammer, but they’re still hammers when you need a wrench. For example, UAVs can’t guard bridges against suicide bombers. They have limited, pinprick firepower other than for small targets. They are useless in poor weather. UAVs are but one sort of tool in a great big tool chest.




IMG_1727aC-1000.jpg




The Warthogs had to wait for a Reaper to roll by. No telling where Mr. iRobot would fly to. Do these go to Pakistan? I have no idea, but it seems like you can’t read the news without seeing where these robots have hit more terrorists. There was a time when the enemy thought terror was a one-way street.

This place has gotten to be like a hornet’s nest of Predators and Reapers. A couple years ago, you’d see them every day, but now you can’t turn around without seeing an iRobot Terminator buzzing around to land or disappearing into the sunset or sunrise.


lmopar also had some more Insitu porn from the same airbase for everyone interested in that.

http://www.rcgroups.com/forums/showthread.php?t=1215717


a3138603-213-P3220047.jpg?d=1269365085




Read more…

Project Andromeda - Communication Protocols


I've been busy writing the communication protocols between the Ground Station and Autopilot. I thought some people might be interested and possibly make use of the approach I've taken. It's all done in binary with discrete packets and makes use of DMA and Interrupts to use as little processor time as possible.


Asynchronous operation is achieved by the use of two FIFO queues and double buffered DMA channels for each radio. There is a lot of detail that will make the diagram above make a bit more sense.


Full article at: http://www.projectandromeda.com.au/blog

Read more…

More ArduIMU Fun

Had a few more flights with the ArduIMU yesterday.

I should mention, that with regards to RC flying, my main interest is competing in IMAC (Scale Aerobatics). Basically it's flying giant scale aircraft through predefined aerobatic patterns for judges. Last year I competed in intermediate (3rd of 5 difficulty levels) and this year I'll be moving up to Advanced (4th of 5 levels).

Arising from this interest, my long term goal would be to get an autopilot doing aerobatics.

Anyways, yesterday was the first flight of the spring with my contest aircraft, shown here.

After the first flight, to confirm that everything was still working, I couldn't help but put the ArduIMU/GPS on board for some data collection.


What I really wanted to know was if typical IMAC aerobatic manuevers could be detected by the sensors used on the IMU. If the sensors railed as soon as I departed level flight, then we might have to rethink things a little. On the second flight with the IMU on board, I put the plane through the Intermediate contest sequence from last year. By flying a known sequence it makes it easy to figure out what the aircraft was doing at each point of the flight, and to determine if the sensor data is appropriate.

The initial data analysis is favourable. I am using the ArduIMU code associated with the recent Ardupilot 2.5.1 work with a few tweaks to work with my equipment. I also added the gyro rate information to the ASCII data stream to give me a better idea of what's going on inside the ArduIMU.

Here are a couple of snapshots from the data:


The starting of the engine is clearly visible in the Roll Rate data. The engine is hand propped. A few flips with choke on to get it primed, and then a few flips with choke off and she's running:


You can see that the engine introduces alot of vibration noise into the rate gyros. I'm not too worried at this point because:
- I had the system hard mounted without much padding.
- I will be installing this in my smaller electric aircraft to start.

If I ever get cocky enough to Ardupilot a gas plane, I might have to add some filtering to the rate gyros to damp out this vibration.


The last maneuver in the sequence is a rolling circle. Basically, you need to fly a circle, while rolling the plane. You need to do 4 rolls in total, so after each 90 degree heading change the aircraft should have completed one more full roll. In my opinion, it's by far the most difficult maneuver they force us to do. Anyways, the data shows just how bad my "roller" is:

There's more stuff in there, but the fact that I can make sense of the outputs gives me hope that I can teach the Ardupilot to do the same :)


Thoughts, and To Do List:
1. GPS signal seems to go wonky as the aircraft rolls inverted (even for short periods). Still haven't decided if this is an issue, since during aerobatics, the attitude and attitude rate is more important than the lat/long. The key will be to make sure that the Attitude and Rate numbers aren't peturbed by momentary GPS jumps.

2. Definitely want to integrate the static airpressure system into the data record (I'm not sure I trust the GPS altitude numbers)

3. Add accelerometer data to the output stream. It would be intesting to see if I can track the gravity vector as I do a slow roll across the field.

4. Right now the data log is time stamped with the GPS Time of Week (TOW) value. Since the ArduIMU is spitting out sensor data faster than my GPS is updating the TOW, I'm ending up with multiple datapoints with the same time value. I think I will switch the timestamp source from TOW to "timeNow" (Arduino milliseconds since boot) to try to prevent this.

That's all for today. More to come.

Tom

Read more…
Developer

ArduPilot 2.5.1 alpha test video

I have been busily testing ArduPilot 2.5.1 with ArduIMU and correcting bugs in the basic functionality. I now have all MODEs working well in my primary airframe configuration and will now work on verifying other configurations (radio types, shield versions, thermopiles, etc.)


If you want to help test climb aboard. There is an active thread in the Forum.

Read more…
Developer

Flight testing 2.5.03

Hi All,
I just uploaded the last version of 2.5.0(3) I wanted this one to be rock solid before 2.5.1 came out.

I got a few hours today to tweak code and gains for my EZ Star. I implemented the derivative term in the heading/navigation loop and all the other loops used just the p term. The derivative term helped reduce overshoot by about 50%. I'm not kidding about the wind. The plane was flying at a 30° angle to fight the wind.

Altitude hold was working very well. Pitch_comp reduced to .1 was about all I needed. The airspeed control needs work, but Doug is tackling that.

I have my own personal ground station in Flash and I added uploading of all of the major variables in order to tune the aircraft in flight. This worked great so I'll leave the code included for the GCS team to check out. I didn't use error checking, I had the plane echo back the values so I could see if the uploaded values worked correctly before re-entering AP. It was far less complicated to do it that way than to try and implement errror-checking through code.

I've also implemented a simple dampening system for flying into the wind based on ground speed. Doug has a much more complex version, but this one worked remarkably well. Here you can see the loiter pattern. Please note that I was flying into a terrific headwind. The plane was moving 12 mph upwind and over 40MPH downwind. Sometimes the wind would pick up and the plane would virtually stand still, hence the strange patterns. Overall the snaking was minimal and far better than before. I was able to hold the 45m radius no problem. I could have cut that down to 30.







Altitude hold with 15 loops around home, then a landing.


Read more…

A little side project...

I’ve been working on a little side project. I originally wanted a case and / or a stand for my Xbee and Xbee Explorer module, so I ordered a couple from Polycase and strapped it together. It looked nice enough and attached to the back of my laptop with Velcro so it was an OK solution. Then I started getting lazy and didn’t want to lug out my laptop and everything every time I wanted to log a flight, so I went to a couple of the different on-board loggers, but never really found a solution I liked (picky, I know.) So that brings me to my little project. I have just finished the schematic, layout and specs and I have a few boards on the way.Here’s what it is: It functions in four possible modes; logger only (you can use it as an onboard data logger without the case and additional modules,) logger plus data pass-through on the USB port (with an Xbee module attached - for when you want to log data to the microSD card AND pass it through to a PC,) stand-alone receiver / logger (with an Xbee module onboard – utilizing the onboard battery, no PC required.) So if you took the best attributes of an XBee Explorer module and combined it with a really good data logger with a battery and charger…this would be the love child.I actually have two versions: one for those of us who like elegant solutions, and another for those who believe in extreme simplicity, but require fewer features. I call them LinqLogger, basically because they were designed to log downlinked data.The first design consists of the following components and features:Components:It uses an ARM7 LPC2148 (512K user flash and a ton of GPIO pins,) includes both a USB and Barrel plug LiPO charger (MAX1555,) On/Off switch, RTC (facilitates date / time stamping of logs,) Xbee socket (pick your own or use one you already have,) external reset, and start / stop recording buttons, USB link and logging status LEDs, microSD card slot (up to 2 GB FAT 16 formatted for PILES of data)Features:Not only does it do a nice job of data logging, but it also has a USB mass storage device profile built in - so when you attach USB, you get a mounted drive on your PC where you can see the actual files on the SD card; nice because you don’t need a separate microSD card reader / writer.The external battery connector makes the board a very independent data logger; you don’t need another microcontroller. It comes with SD+USB boot loader that allows the end user to tweak firmware to their project specifications. Configuration is done through an on-board configuration file, so there is no need to type in initialization commands. When the module is switched on and logging is initiated, everything received by the Xbee module is recorded.The second (simpler) design consists of the the following components and features:Components:It uses an ATMega 328 (16MHz, 3.3v), USB LiPo Charger (No barrel plug – MAX1555, charging LED,) microSD card slot (up to 2 GB FAT 16 formatted for PILES of data,) no RTC, On/Off switch, simple FTDI to USB (just like Xbee Explorer,) Program / Log Switch (used only when programming the ATMega328 via an FTDI – this is done so that the USB used for charging and data pass-through is NOT used for programming.)Features:This model uses the basic serial STK500 boot loader which comes pre-installed so that you can tweak the firmware, but has very few additional features. The system is the equivalent of combining an OpenLog logger interfaced to an Xbee Explorer with an on-board power source and charger.If either of these sound interesting to you feel free to drop me a line. I will be posting pictures, schematics etc., and of course it will all be available as Open Source. I have breadboarded these and they both work well. The boards and the cool little cases will both be here in the coming weeks...if anyone else wants one, I'd be willing to sell them at cost as kits or something. Any ideas you guys have for additional development are obviously welcome too!
Read more…
Developer
Poll - how do you want FBW to work?

Jason Short came up with a great flight mode, FLY BY WIRE, in ArduPilot 2.5. This mode differs from STABILIZE. In STABILIZE the autopilot constantly tries to return the plane to 0 pitch and roll, while you give stick inputs that tell the plane to do something else. It feels a bit like you are arm wrestling against the autopilot sometimes. With FLY BY WIRE if you move the right(*) stick half way to the right then the plane will bank half of the maximum amount defined. As long as you hold that stick position the plane will hold that bank. If you center the stick, the plane will go to zero bank.

* - All references to right stick assume a mode 2 RC setup where the right stick controls pitch and roll.

That is all great! You are not arm wrestling the autopilot. You are telling it what roll you want and it is giving you exactly that roll.

But what about throttle and elevator? Jason had a scheme where if you moved the right stick then you would get both a pitch and throttle response. In 2.5.1 I have been trying an alternate scheme involving both pitch and throttle increasing or decreasing together. I am convinced that these schemes are not the best. But what is? It really comes down to user preference.

I think the two best alternatives are:
  1. Have the throttle remain under manual control and have the right stick up and down control pitch angle. This setup is great for tuning your servo PID gains (both roll and pitch), and is a really fun way to fly.
  2. Have the elevator maintain a constant airspeed and have moving the right stick up and down increase or decrease throttle from a cruising throttle. This setup is probably the ideal setup for new pilots. You can hand the transmitter to anyone and they can fly. Can't stall because airspeed is controlled. Want to turn, move the stick to the side. Want to go up or down, move the stick up or down. Of course they still have to deal with what up and down is and what left and right are while coming and going, but if you let go the plane will always take care of itself.
What do you think is best??? Maybe something else?

I can't seem to get the poll to embed - please go here

Read more…

Commercial Quadrotor Recommendations?

I am setting up a lab this summer for some student research that will be similar in most ways to this one at MIT: http://vertol.mit.edu/

I would like to buy 6-8 commercially available trirotor or quadrotor helicopters in the $1000 - $1500 price range that would be similar in capabilities to the old Draganflyer V Ti. I've looked around and I would be very happy using Parrot AR Drones, but they have not set a date for releasing them or published a price. Likewise, Draganfly's web site says they will release their E4 in 2010, but no price or date of availability either. I could swear their web site used to say the E4 was coming in 2009.

I will only have the students for 10 weeks, so I would rather have them doing higher-level research using copters that work out-of-the-box and have available spare parts than have them spend a big part of their summer testing and debugging copters that they have built from scratch. Any suggestions?

Garry

Read more…
3D Robotics

That's Nathan Siedle, CEO of Sparkfun, handing me the very first ArduPilot Mega board to come off the Sparkfun production line. We were at an Arduino planning meeting in NYC; that's Massimo Banzi of the Arduino project in the back.


Here's a closeup photo of the board. It looks great! The only thing that's not quite right is the GPS connector is supposed to be sideways, so it doesn't rip off in a crash, but we'll fix that in the next batch. It doesn't really matter, because nobody will use that connector; they'll be using the GPS connector on the IMU shield instead.


Front:


Back:

I don't have an ETA on when they'll go on sale, but it's not long now!

Read more…

Maiden Ardu-Flight for me

It was my first flight with an Ardu-anything today. Working towards getting an ArduIMU/ArduPilot working.

So far it was just a data logging flight. I had a GPS and ArduIMU installed in my Stevens Aero Edge 540 along with an OpenLog from Sparkfun.

After downloading the data into MATLAB, and some manipulation, I outputted a Google Earth KMZ file of the flight:

You can view an animation of the flight in Google Earth here:

Google Earth KMZ file

The plan is to eventually tune ArduPilot/IMU into this aircraft (using the great start that has been going on with 2.5.1 code here).

Tom

Read more…

This week in aerospace

PROP ADAPTOR TERRORISM, INDUCTOR INSANITY, THERMOPILE TERRORISM, WHAT SLOW
ATTITUDE ESTIMATES MEAN, LAST WEEK'S VIDEO FLIGHT

PROP ADAPTOR TERRORISM

These aluminum GWS prop adaptors are ridiculous. Lately they started stripping before getting anywhere near the required tension. Down to threadlock on plastic again.





Forget about those tiny set screws. Use TRex-450 bolts. Time to move to China to make our own.

INDUCTOR INSANITY

Managed to get the Marcy 1 radios to stop locking up permanently. The ground station watchdog timer wasn't being reset. Definitely a point for microcontroller operating systems. That got it down to 1 lockup which instantly recovered around every 15 minutes. These are probably from the reset pins glitching & we know tying those to Vdd adds noise to the thermopile.



So cannibalized a motherboard to make inductors for Marcy 1. These are made with 20" of wire. The larger the spaces between the windings the better.





Inductors on Vdd & GND got it just a hair quieter than 1 inductor on Vdd.





Wound Vdd, GND, & signal on 1 core & that got the best results & least weight. It's probably down to the EMF through the air.





& the readout at flight RPM finally shows a waveform of sorts. Modulating PWM really kills it.



THERMOPILE TERRORISM

Now to get roll & pitch out of it you need to lowpass filter it, stretch it to a constant period, average several periods over time, & take the magnitude at the N, E, S, W phases. Already tried getting the magnitude & phase of the peak. That doesn't work because you've got an irregular horizon with peaks that always show up at the same position regardless of attitude.

Think we got roll & pitch curves. On the ground there's a lot of crosstalk. In the air it resembles more normal attitude changes.



Holding it 5ft off the ground, on the golf course, you get decent attitude sensing & there's a 1V thermopile change. Got a mag gimbal lock when she pitched up.



The completely processed thermopile waveform with spikes for azimuth.

Main problem is the DC offset & amplitude are completely random. The difference between max & min temperature for a given angle of bank is not constant & we don't have enough room for a Z pair. Best idea is a set of thermopiles on the ground station for measuring temperature range in addition to the sonar.

Finally, She's too heavy with the inductor & POV to do much flight testing. Don't know whether to start a lighter flight computer now or master attitude sensing on the ground.

SLOW ATTITUDE ESTIMATES

Thinking things over, the attitude estimate & feedback on Marcy 1 is going to be so slow you're once again looking at filling in blanks in the data. Neural networks got abandonned because no matter how many algorithms you throw at a piece of garbage data, you're still reading the same garbage data.

They improve stability as long as the input data stays in a certain pattern. An unexpected gust of wind or descent causes these algorithms to destroy the data & your autopilot actually takes longer to compensate than it would using PID loops. We stopped neural networks when uBlox 5 came out.

LAST WEEK'S VIDEO FLIGHT

Headed over Los Gatos at night. You get a nifty view of the valley. Unfortunately only been flying the camera after Major Marcy operations & those have only happened at night. The view would have been better in daylight.


Read more…

USB DSM2 Transmitter for my Blade MSR helicopter


Today i flew my Blade MSR using a joystick, my PC, and the 2.4ghz LP4DSM transmitter which used to be in the tx controller. The serial protocol is best documented here, but information on this exists elsewhere including here in a few posts, on diydrones. I'm pretty excited that I finally got this working...it took a few nights of serious head scratching to work out some kinks.


I used a USB to TTL breakout board to transmit to the LP4DSM module, which apparently is a pretty common module found in numerous spektrum and other transmitters. I used LabVIEW to assemble all of the code, pulling axis information from the joystick, filtering this data, and converting that into hexadecimal PPM which was sent via serial to the TX.


I still have some bugs to work out, but it worked, and that is progress.


So, while I was working on this, I also bought an Arduino Pro Mini (yes, i gave into the temptation of a $20 already tested, super small, and assembled board :-D ) and an "ArduIMU Sensor Board - Six Degrees of Freedom (Main)". I put the board name in " " because it's actually only 4 degrees of freedom, having a 3 axis acc and a 1 axis gyro, with analog output.


It doesn't come with any documentation (nor does the Arduino Pro Mini), and I'm not sure if that is common or not. There is online documentation for the Arduino Pro Mini, which is helpful, but I find the information here on DIYdrones to be the best resource. thankfully the hardware is somewhat self explanatory.


Lastly, I bought two micro servo boards, which are the same servos on the Blade MSR, and the BMCX, and possibly others. i'll have to post the name/details of those servos later, i can't find the info right now.


My plan is to put both boards on my MSR, to make a stabilized camera mount using my endoscope vid camera. You can see where this is going.... :-D


....pull off the 5 in 1, add 2 more servos and a rx, and I should have a blade MSR that can be video camera flown, flight stabilized, and hopefully very, very cool. (and hopefully light enough!)





Read more…
Hello,I've been silently following the progress of the UAV Dev Board team for a while now, and want to congratulate Bill Premerlani and his great team for their amazing accomplishments.This is my first posting, so please let me introduce myself. I'm relatively new to RC flying, and have very little experience with micro programming, but do have some background in aerospace and software engineering. Anyway, after crashing a few planes, it's exciting to see that such a capable and inexpensive auto pilot has been developed. I've just started digging into all the UDB technical details, so I'm green behind the ears, but hope to contribute in some small way to the team eventually.I hope you won't mind if I also ask a technical question. I'm having a problem and could use some advice.At this point I've got the UAV Dev Board setup, programmed with MatrixPilot 2_0_3, and connected to Spektrum servos in an aileron/elevator configuration. BTW, getting to this point is due to the terrific UDB instructions and tips, as well as Pete Hollands' excellent videos, so thank you!However, I am having an issue getting the UDB to switch modes from my transmitter/receiver. The UDB remains in manual mode (Green light on, Red light off). My apologies if my question is silly, or has already been answered.The Troubleshooting page (http://code.google.com/p/gentlenav/wiki/Troubleshooting) has the following note."Sometimes the board starts ignoring manual controls, or switches back to RTL mode unexpectedly. This is a problem with some receivers that output servo signals at slightly low voltages. This causes the UAV Dev Board to not be able to see them. One solution is to change to a receiver that sends out stronger signals. Another option is to lower the voltage at which the UAV Dev Board runs from 5.0V to 4.5V. This makes the low receiver voltages look stronger relative to the UAV Dev Board's voltage."I'm wondering if this might explain my problem. If the signal voltage is too low, what voltage is recommended?Here's my setup:Red UAV Dev BoardMatrixPilot 2_0_3Spektrum DX 7 transmitterSpektrum AR7000 receiverUDB Spektrum AR7000---------- ---------------radio ch 1 --- AILEradio ch 2 --- ELEVradio ch 3 --- THROradio ch 4 --- AUX 1 (for mode control)gps --- No gps connected (yet)UDB Servos & Power---------- ----------------servo ch 1 --- Aileron Servosservo ch 2 --- Elevator Servoservo ch 3 --- ESC/BEC measured at 5 voltsI've verified that AR7000 AUX 1 output voltage is effected by the 3 way 'Flap Mix' switch on the transmitter. The AUX 1 signal voltage is 0.25, 0.20, or 0.15 volts, depending on switch position. Are these voltages too low? Regardless of switch position, the UDB board does not change modes.Here's what's observed during testing.1) Turn on Spektrum Transmitter1) Connect power to the ESC/BEC:AR7000 lights turn onUDB Green light turns onUDB Red light turns on2) UDB Red light blinks 6 times3) UDB Red light turns off4) UDB Green light remains on5) Change the position of the 3-position 'Flap Mix' switch on Spektrum transmitter- this has no effect on UDB modes6) UDB Green light remains on and Red light remains off7) UDB provides auto pilot servo control and also allows manual control from the transmitterOne other observation. If the transmitter is turned off, the mode remains the same (Green light remains on, Red light remains off).The options.h file is currently set to the default values. Do these need to be changed?#define MODE_SWITCH_THRESHOLD_LOW 2600#define MODE_SWITCH_THRESHOLD_HIGH 3400It's not clear to me what values the AR7000 (AUX 1) is producing, or how best to measure them.Thanks in advance for any advice, and sorry for the long-winded first posting.Phil
Read more…
3D Robotics

Voice controlled heli UAV


From BotJunkie:

"This little helicopter is able to understand you when you tell it what to do. No pushing buttons, no using special commands, you just tell it where you want it to go and (eventually) it goes. Of course, I’m sure it required a bit of work to define where “door” and “elevator” and “window” are, but it’s a much more intuitive way to control a UAV that works when your hands are full, when you’re stressed (think military), or simply when you have no idea now to control a UAV.

I don’t have much in the way of other details on this project, besides the fact that it probably comes from the Robust Robotics Group at MIT, and possibly from someone who lives in this dorm. How do I know? Well, one of the research goals of the RRG is “to build social robots that can quickly learn what people want without being annoying or intrusive,” and this video is on the same YouTube channel. ‘Nuff said.

[ MIT Robust Robotics Group ]"

Read more…