All Posts (14048)

Sort by

Working as a BYU electronics shop tech, I occasionally get to help out the guys at the MAGICC lab. A PhD student came in a few weeks ago with a problem: He wanted to make an Alpha-Beta probe. Encoders of the accuracy he wanted are too heavy and too expensive to put on a 5 pound flying wing, and the multiple Pitot-tube option was not his game to play either, so he was wondering if we could make encoders like the big expensive ones he was looking at, except for being big and expensive.I got to thinking about P-factor in flying tail-draggers and high AoA flight: Props that are presented with a relative wind that is off-normal to the plane of rotation produce asymmetric thrust. Using that principle in reverse, small pager motors could be mounted to a Pitot-probe, each offset by 90-degrees. It is possible to work up different configurations, redundant placements of similarly oriented pager motor "generators" and the like, but the basic idea is that as long as the props on the pager motors are uni-directional (no camber/bias for rotation in forward verses reverse), and as long as the props are kept out of dirty air or asymmetric dynamics due to the Pitot-probe, these should make a simple Alpha-Beta measurement system.As to taking the measurement: My hunch is that the ratio between the potential differences made by the motors resolves the alpha and beta components of the airflow. That or the current generated when a load is place accross the terminals of the pager motors.So has this been tried before? What are some issues?
Read more…
Developer

Ardupilot 2.5 preview part 6

New in Ardupilot 2.5 is mission simulation/debugging. First load a mission using the config tool and make sure you select "Set Manually" in the home info area on the left.Then, in the header, set the value of Debug to 1 and upload 2.5. The mission will begin as if it's already in the air and will start outputting telemetry. If everything is OK, the plane should make each waypoint and end up back at home in a Loiter pattern.This is also a 3d simulator, so altitude will be monitored as well. In future releases, specific waypoints can have altitude requirements to meet before the plane can move to the next WP.Tweaking the SimThere are two values to make the simulation more realistic for your plane. First is turn rate. This is a basic value that indicates how fast your plan turns. Higher values means faster turning. The idea is that at 90° the plane will turn 55° per second. This isn't realistic, but if you know how fast your plane will turn at thirty degrees you can just multiply that x3 and you'll have a good value.est_turn_rate = (roll_sensor * TURNRATE * (long)deltaMiliSeconds) / 90L;The next values are#define CLIMBRATE_UP 1000 // (meters * 100) how fast we climb in simulator at 90°#define CLIMBRATE_DOWN 3000 // (meters * 100) how fast we drop in simulator at 90°Again, these values are just to make the math easy for me ;) Adjust to suit the rate of climb for your plane.Ok, that's it!Jason
Read more…

XMAS BAY, XMAS GOLF 4 U, DEATH BY MARCY 1

XMAS BAY 4 UHad the best weather ever on an XMas. Totally clear, no wind & warm inland.Being the only day you can traverse the MacArthur maze in 1 day, took some snaps above Emeryville.

Moon over Berkeley.

Don't think we've ever seen such a flat calm. Like a millpond. It will make it harder to see the bergs.Finally the movie. Whenever you stop flogging GooTube with your family XMas videos, you'll get a transcoded flight movie.Product links in this post:Professional image stabilization software: http://heroinewarrior.com/Professional UAV: http://vicacopter.com/XMAS GOLF 4 USince no-one plays golf on XMas, had a chance to use the golf course for what it was intended for: flying. That's us in our favorite flight test range.

DEATH BY MARCY 1The Marcy 1 boards are killing us. Mainly everything except the ESC is done from scratch on 1 chip to minimize weight & not commercially sourced. You have to make the radio, the position sensor, the PWM generator, the AHRS, the camera, all from scratch.The radio library must be ported from its successful test harness to the flight hardware. Discovered the SPI pins need to be set to the right modes just to get an SPI interrupt.Next, the USB library which served us well through Vika 1 stopped working on both the Marcy 1 ground station & a new Vika 1 ground station using a crystal.

Finally swapped the crystal for a tried & true oscillator & it worked. So USB works with full 48Mhz oscillators but not 12Mhz crystals + 4x PLL. Everything's leading to the traces not being symmetric & somehow causing a lopsided oscillation or maybe an unstable oscillation. The capacitors are exactly symmetric on a commercial board.

Read more…
Moderator

Worth a Christmas day look

getAsset.aspx?ItemID=28591

http://www.flightglobal.com/articles/2009/12/25/336604/top-ten-picture-stories-of-2009.htmlI found Uncle Rogers quiz way too hard this year.http://www.flightglobal.com/articles/2009/12/21/336433/uncle-rogers-christmas-quiz-2010.htmlDownload your free Vulcan poster, and read about display flying the Tin Triangle, they used to rush through the hills around my parents home, just too cool.http://www.flightglobal.com/articles/2009/12/22/336324/tin-triangle-display-flying-the-vulcan.html

getAsset.aspx?ItemID=32128

I just realised I have been reading Flight for close on 40 years!! Flipping heck.
Read more…
Developer

Ardupilot 2.5 preview part 5

Merry Christmas everyone.I wanted to talk about a new aspect of 2.5 that enables coders to easily program missions through a simple API. The main idea is that many common events are sent to functions in the event.pde file to be handled by you in any way you see fit. You can do anything and access any variable in the system - within reason. The events.pde file can be swapped out with a different mission and uploaded to the the hardware.The first and most important event is the switch_event. This event is called when the 3-position switch on the radio has changed. The function set_mode(MODE) is called and the argument is one of the following flight modes:MANUAL - complete radio controlSTABILIZE - uses IR sensors to stabilize the aircraftFLY_BY_WIRE - allows the user to "steer" the aircraft using autopilot control loopsAUTO - exactly what you thinkRTL - Fly home nowLOITER - Circle around current location (set when aircraft arrives at home during RTL)An example of setting the current waypoint back to the index 1 is shown when the switch is in manual position.
void switch_event(byte switchPosition){        switch(switchPosition)        {                case 1: // First position                set_mode(MANUAL);                // this is handy function to restart your mission:                reset_waypoint_index();                break;                case 2: // middle position                set_mode(AUTO);                break;                case 3: // last position                set_mode(STABILIZE);                break;        }}
The next most important event is a waypoint event. There are a few basic events called (more will be added as necessary.) In the example below Loiter mode is turned on when we load WP 3. The variable elapsedTime is set to 0 ( elapsedTime is a user defined timer that increments in milliseconds.) If you want to stop Loitering after a set number of seconds, see the next example below.
void waypoint_event(byte event){        switch(event)        {                case EVENT_WILL_REACH_WAYPOINT:                        // called just before wp_index is incemented                        Serial.print("Reached WP:");                        Serial.println(wp_index,DEC);                        break;                case EVENT_SET_NEW_WAYPOINT_INDEX:                        // called just after wp_index is incemented                        Serial.print("Now going to WP:");                        Serial.println(wp_index,DEC);                        break;                case EVENT_LOADED_WAYPOINT:                        // called just after wp is loaded from memory                        Serial.print("Loaded WP index: ");                        Serial.println(wp_index,DEC);                        print_current_waypoint();                        // custom loitering code                        if (wp_index == 3){                                set_mode(LOITER);                                elapsedTime = 0;                        }                        break;                // called when the pattern to be flown is automatically restarted                case EVENT_LOOP:                         Serial.println("Looped WP Index");                        print_current_waypoint();                        break;                  }}
The mainLoop_event is called with every execution of the control loop. Here is a good place to check the elapsedTime variable to escape Loiter mode and continue on with the mission.
// called AFTER every control loopvoid mainLoop_event(void){        if (control_mode == LOITER){                if (wp_index == 2 && elapsedTime > 120000 ){ // 2 minutes                        elapsedTime = 0;                        // our waypoints index is not altered during LOITER                        // All we need to do is reload the waypoint                        load_waypoint();                        // and return to Autopilot mode!                        set_mode(AUTO);                }        }}
Other events include:void gps_event(void)void low_battery_event(void)void failsafe_event()More will be added as necessary, and of course, you can add your own.JasonNext installment - The Mission Simulator
Read more…
Developer

ArduIMU v1 hardware users - Firmware help

It just came to my attention that people trying to use the latest revision firmware with the older ArduIMU hardware were having problems. The current revision firmware has lots of goodies in it that the pre-v2 hardware firmware did not have such as much better vibration resistance, euler angle output, binary message output for Ardu-IMU-Pilot, etc. We had included code in recent revisions to allow use of either hardware, but I guess neither Jordi, Jose, or myself had checked it on the v1 hardware.There was an error in the sensor_sign[ ] declaration. It has been corrected in revision R19.If you have had trouble downloading all the individual files of the latest revision source code I have added a zipped download file of R19. To select between v1 and v2 hardware you need to pick one of two pairs of of declaration lines to comment out at around line 53. They are commented so you can see which you need. Just place the // in front of the pair you do not need....
Read more…
3D Robotics

Finally, a working Osprey-like RC model?

GAUI TG-609 from Michael Yang on Vimeo.

The civilian version of the Osprey V22 tilt rotor is the TG-609. Such a vertical take off, fixed wing flight platform has long been a UAV dream, but it's proven too tricky for RC modeling to date. Now Gaui seems to have cracked the code. After more than a year of development, mostly on working on the transition from heli mode to fixed wing mode, it appears ready to release the plane. The above video gives a sense of how it will fly; although it doesn't show full fixed wing mode yet, it's at least half-way there. It's not for sale yet, but apparently Empire RC will be the distributor in the US. I'm not sure this is the ideal UAV platform, due to limited payload capacity and very sensitive CG. But if you want something with the launch flexibility of a heli and the duration and flight effeciency of a plane, maybe this is worth checking out. Here's a bunch of pictures of the aircraft on the ground and in flight.
Read more…
3D Robotics
If you've been following Tom Pyke's progress on his impressive Gluonpilot, you will have seen that he's implementing it with a realtime operating system (RTOS), rather than programming "straight to the iron" the way most autopilots are done, to gain maximum control over interrupts, timing and the like. He's using a relatively powerful dsPIC chip, which can handle the overhead of the RTOS (I think he's using FreeRTOS, but I've pinged him to find outUPDATE: yes, it's FreeRTOS. See below). Here, he makes the case for a RTOS: "The main advantage of a real time OS is that you can use threads (which we will use tasks from now on). You don't need to bother anymore about the delay your telemetry processing can cause to your Kalman filter or PID control. No more need for timed loops or Timer interrupt routines. It looks perfect! There are some things you need to keep in mind: You need to prioritize every task Every task has a separate stack. This stack is used for the task itself AND every interrupt routine that may be called during this task's execution Thats about it! Let's take a look at the different tasks in gluonpilot: --Telemetry: All the output needed for our groundstation --ConsoleInput: Processing and answering all the commands you send to the autopilot --Sensors: Gathers and processes (filters!) all the sensors (gyroscope, accelerometer, gps, pressure sensor) on our autopilot module --Control: Sends the correct position to the servos! This handles both manual, stabilized and full autopilot modes." The prioritization of the tasks is as follows:

Read on here. UPDATE: In an email, Tom explains more: "Yes I'm using FreeRTOS. Whether you should need to consider it [I had asked him if it would work on a 16Mhz Atmega--chris] is not easy to answer. 16MHz doesn't seem a lot. The dsPic runs at 80MHz (40MIPS) and - I think - has more memory. Using an RTOS does not cause an extreme amount of overhead, but you can no longer push the processor to its limits: - You need more memory because interrupts can be executed (and use the stack) of any running task/thread (and you need to assign a stack size to every task) - You need enough spare CPU cycles to make sure all tasks can always be handled in time. - And the RTOS needs memory, flash and CPU time of its own It may sound contradictory, but I started using FreeRTOS to make sure people can easier add code to the autopilot. In the last version without it, the code became complex and critical to change, because of all the timing-critical code and timed loops. Now with the RTOS, people can add lower priority tasks and I'm sure the manual control and time-critical filtering still works. However, you need to keep the design as simple as possible. The only features I'm currently using is the scheduler (because it's easier than a timed loop) and a queue mechanism for pushing data from an interrupt to a sleeping thread. There are some RTOS pitfalls such as priority inversions. But it's really up to you how far you want to go. Replacing your timer interrupt routine by a threads wonn't give you any problems you didn't have already. If you use mutexes for mutual exclusion all over your code, than you're down to a more challenging task :-) In the end, I can only suggest that you play with it for a day or two... port some existing code to FreeRTOS and see how comfortable you are using it. It's not really that complex."
Read more…
3D Robotics

$30 laser rangefinder!

Cool news for those interested in SLAM (Simultaneous Localization and Mapping) for indoors robotics. From Hizook: "A commercially-available ultra low-cost laser rangefinder is finally set to hit department store shelves in February! I'm speaking of the laser rangefinder presented at ICRA 2008 that costs $30 to build that sits atop the recently announced Neato Robotics XV-11 vacuum cleaner. Others have thoroughly discussed the XV-11's competitiveness with iRobot products, the possible patent infringement of iRobots square-front design, and its ability to perform SLAM. But everyone has glossed over the coolest part: Forget the $400 robot, $60 batteries, $30 wheels (etc.) available for pre-order on Neato's website... if made available, sub-$100 laser rangefinders would revolutionize hobby robotics! Read on for a description of this compelling (future?) component. Neato sponsored an ICRA 2008 research paper entitled, "A Low-Cost Laser Distance Sensor," that detailed the design of laser rangefinder that costs only $30 to build. Called the "Revo LDS", it is pictured above. Diagram of operation below:

Unlike the more expensive (many thousands of dollars) laser rangefinders that use time of flight measurements, such as those discussed here and here, the Revo LDS triangulates the distance to an object using a fixed-angle laser pointer and a CMOS imager, with a known baseline between the two. To quote: `A compact, rigid point-beam triangulation module incorporating laser, imager, and electronics. With a low-cost CMOS imager and a DSP for subpixel interpolation, we get good range resolution out to 6 m with a 5 cm baseline, at a 4 KHz rate. The key insight to the Revo is that high precision is possible with a small baseline, because of the digital image sensor.` A motor spins the unit at 10Hz to give a full 360-degree field of view. An optical encoder gives 1-degree angular accuracy. Not exactly Earth-shattering, but simple and low-cost. An enclosed, robust USB version of this sensor would have broad appeal, and open up the world of hobby robotics to a sensor that is ubiquitous on research robots. Oh, and I suppose the XV-11 isn't half-bad either: I seriously hope that Neato makes the laser rangefinder component available separately, but it is currently not listed on their website for purchase. At the moment, I am a bit worried about the possibility of litigation due to similarities between the XV-11 and an iRobot patent (see below). Hopefully they see the light and avoid destructive lawsuits." Read the whole thing here.
Read more…

Only you can prevent UAV patent trolls.

I was researching prior art for a fully redundant motor/ESC/Battery device, and came across this patent for the the Segway ESC by Dean Kamens group (DEKA). And I realized that given enough money and an interest in a particular field, these companies could patent the obvious and make open source a difficult proposition.In response to the risk of patent trolling in the arena of DIY Uavs, I propose we make an effort (periodically) to indulge in some high concept - think tank level - ideas publicly (blogging), on the grounds that failing to do so might leave room for patent trolls.I also thought the recent (iRobot) entry into this field would make an excellent thematic starting point with bridge inspection. Other than the obvious photographic data of a bridge - what data could a UAV collect, or sensors could a UAV place and service that would identify metal or concrete fatigue of a structure? Vibration, conductivity, spectral response, current leakage, isolated heat from friction (ir), geometric deformation by n acoustic transponders. etc...Happy Winter Solstice...
Read more…

Careers in Aerospace

Hello everyone! I'm fascinated by the work you all do! www.JustAerospaceJobs.com is a site that aggregates all aerospace jobs in the US from a variety of sources, making it a highly efficient tool for finding careers in the aerospace industry. I hope some of you can benefit from it!
Read more…

Basic understanding of ESC

I'm trying to find out what is the maximum update rate for a typical ESC is. I saw that most quad copter designed require the ESC update rate to be very high, i.e 100Hz or more.My understanding a ESC takes a PPM signal from 1ms to 2ms with a 20ms duty cycle. So a max of 50Hz update rate, is that correct? Is there some "play" in the duty cycle maybe max of 10ms. Or I'm way off base? Looking at ESC data sheets seem to be missing this information.
Read more…
Developer

Ardupilot 2.5 preview part 4

Just like in the previous version of Ardupilot, throttle control maintains speed and altitude. I've made a little demo to help demystify the behavior of throttle control. This loop uses a special scaling feature that brings up the throttle to a high level when the airspeed dips below the desired cruising speed. Altitude of the plane is also maintained with the throttle by increasing the desired airspeed. Finally airspeed is scaled to match a throttle output %.Here is the Flash Source: PID Throttle.fla.zipNext installment: Events API
Read more…
Developer

Ardupilot 2.5 preview part 3

Ardupilot 2.5 has the same heading control as before with the addition of a simple controller to adjust the rate or turn for the rudder. To give you a better tool for setting gains and for understanding what happens where and why, here is a handy interactive version of the PID code.Mouse the mouse left or right to indicate which direction the plane should be turning. Up and down control the current roll of the plane.
Read more…