Jason Short's Posts

Ardupilot beta

Posted by Jason Short on March 6, 2010 at 12:29am

I just made some changes to the 2.5 code to address some issues of compatibility and general usability improvements.

If you use throttle input, you'll be able to try flying without the Remove Before Fly pin. I had to restructure the GPS reading routines to do this. Now the system goes immediately into the main control loop. This has a few benefits:

The GPS led blinks when GPS fix is lost instead of just turning off.
You don't need to remove the pin before flight - much cleaner for systems buried into the fuse.
You don't need to worry about GPS lock if you are just flying stabilization

The GPS LED will turn solid as soon as it gets a good lock. If you are in manual mode, with the throttle all the way down, you will be in "ground start" which is simply a way to save your radio trim values and reset the Waypoint to 1. A ground start will also allow home to be set after the first good GPS fix. Even if you have in-air restart with a false positive for ground-start, the worse that could happen is you reset your hoe position.

If you don't read in the throttle with the jumper to pin 13, you have to still use the RBF pin.

I've also updated support for reverse throttle for those users who want low throttle with high PWM values.

I have not flown this revision, so if you're willing to help me test it I would appreciate it.

http://ardupilot.googlecode.com/files/Ardupilot_25_02.zip

Thanks,

Jason

Developer

Ardupilot 2.5 Final

Posted by Jason Short on February 22, 2010 at 12:12am

Hi Everyone,

I just finished polishing Ardupilot_25.zip. The Manual will be finished this week.

I'm sure there will be a few setups that have issues, so be sure to check out the test suite which isolates each sub-system for testing. If you have any issues use this blog to post them. What's most important is that you include a log file of your issue enclosed with your comment, as well as a copy of your header file and notes about your radio and receiver.

By default the control switches are not set to Autopilot. This was intentional. I don't want people to start flying it right away without fully ground testing their setup. My suggestion is to get Stabilization working first, then move up to Fly-By-Wire. Once you can fly the plane in FBW mode, then try Autopilot.

I've also updated the GPS debug mode which is now simply GPS_PROTOCOL 5 (instructions are in the header file). Everything about the plane will behave normally, except Autopilot mode will cause the plane to think it's flying your waypoints. Ardupilot will output telemetry and indicate when it thinks it has reached each WP. You can control the speed of the simulation with the throttle control.

Good luck!

Jason

Developer

Ardupilot testing

Posted by Jason Short on February 13, 2010 at 3:23pm

Hi all,

Testing Ardupilot 2.5 from Jason Short on Vimeo.

Here's a video of testing today. I had a flawless run of the T3 round two course. Everything was looking good. I'll post the code today on the repository.

Some flight notes. I completely remove the I term (by setting it to zero) for Roll and Pitch which helped tremendously. I went from highly unstable turns to nice smooth ones.

Altitude hold seems to have a slight oscillation for me. You can here the motor go up and down as the plane pitches up and down slightly. Any thoughts for dampening this out?

I reduced the loiter radius to 20 meters which the plane doesn't like. It tends to do figure eights around the home position. I'll increase that to 30 next time.

I'll post the code tonight.

Jason

Developer

Ardupilot 2.5 Release Candidate

Posted by Jason Short on January 31, 2010 at 9:30pm

I was finally able to test 2.5 over the weekend and added a few tweaks to the code.
Here's what I hope is the final release.

As the new Manual gets formatted, you can view it at: http://code.google.com/p/ardupilot/wiki/ArduPilot25
Until the content is finally moved over the 2.4 manual is still a great resource.

Ardupilot_25_RC2.zip

Bonus - If you look check out the Waypoint_writer_25.pde file in the test suite, you can upload relative waypoints. This isn't supported in the config tool yet.

Jason

UPDATE -

A lot of people were having trouble with the GPS code and LEDs. I reworked the GPS parsers today to iron out some things. They were nothing that would interfere with flight, but I highly recommend using this new version. I've also added the ability to scale down your plane's roll based on airspeed. This should help planes that turn faster when they go slower. We may tweak this a bit in the future, so I'm looking for feedback on it. Note you can always turn it off in your header file with this line:

//6-4

#define AIRSPEED_TURN_P 1

see the header file for more instructions

Developer

Ardupilot 2.5 Beta

Posted by Jason Short on January 14, 2010 at 5:00pm

This is a quick note to let everyone know that Ardupilot 2.5 is feature complete and can be downloaded via SVN. If you're on Windows, use TourtiseSVN and if you're on a OS X like me, try Versions. The code is located here.Once the Beta feedback is in I'll post a zip file of the final version. Information about using SVN can be found on the web. Please post any issues in this blog post, and I'll fix them immediately and re-upload.I'm also building a wiki manual to help with the configuration, but it's an early work in progress. I'll write a lot more this week, but there should be enough content up there to get you going.Use the Airframe tester to configure your new 2.5 header file and familiarize yourself with the startup sequence. Don't use the old 2.4 file, except to copy over your old gain settings. I've tried to keep as many of the values the same, but many values are new as well.By Default the control switch settings are 1 - manual, 2 - Autopilot, 3 - Stabilize. Feel free to change them to whatever you like.Good luck,Jasonp.s. Who thinks Ardupilot needs a logo?

Developer

Ardupilot 2.5 preview part 6

Posted by Jason Short on December 27, 2009 at 3:00pm

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

Developer

Ardupilot 2.5 preview part 5

Posted by Jason Short on December 24, 2009 at 11:23pm

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

Developer

Ardupilot 2.5 preview part 4

Posted by Jason Short on December 20, 2009 at 7:00pm

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

Developer

Ardupilot 2.5 preview part 3

Posted by Jason Short on December 20, 2009 at 5:42pm

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.

Developer

Ardupilot 2.5 preview part 2

Posted by Jason Short on December 19, 2009 at 7:00pm

Ok this post is about crosstrack error. Ardupilot 2.5 has a basic system for adjusting the plane's bearing when it has steered off of its intended path due to wind. Thanks to Doug Weibel for the code.

XTRACK_GAIN = .2if (abs(bearing_error) < 25) {        bearing_error += sin(radians(crosstrack_heading - bearing_error)) * wp_distance * XTRACK_GAIN;}

We set the crosstrack from our starting location as the angle toward the waypoint. As we get blown from side to side, that angle changes. We run that through sine to get a nice ratio and multiply it to get an angle to add to our heading.Depending on the gain and bearing error, we can get wild results, so we need to limit the effect to a range of degrees. In this case 25°. If we go outside of 25° by a lot, we can reset the crosstrack to be from the current location.Here is an example:

Developer

Ardupilot 2.5 preview part 1

Posted by Jason Short on December 19, 2009 at 5:55pm

Hey all,I thought I would start featuring what's new in 2.5. As you might know it's more than bug fixes. It's an entirely rewritten version that's intended to scale up and be customizable for all sorts of fun things including future projects like Mega. I just finished the loitering code so I thought I'd post that feature first.On a tip from Ryan Beall, I implemented a simple vector field algorithm that holds the orbit around a location by specifying the radius to hold.Here is the code:

if(LOITER){        if (WP_distance < radius){                power = WP_distance / radius;        }else if (WPDistance < (radius * 2)){                power = (radius - WP_distance) / radius;        }        bearing_error += power * -90;}

This says the closer we are to the radius the more we turn 90 to the waypoint. The sign can be changed to adjust the direction of orbit for things like implementing turn prediction. Simple!In Ardupilot 2.5 you will be able to loiter over any location or specific waypoints.

That's it.-Jason

Developer

Final Beta of the Ardupilot 2.5 Airframe Test

Posted by Jason Short on December 18, 2009 at 9:00pm

I finally had some quality time with the Ardupilot Airframe Tester in the air and would like to report, after a few bug fixes and tweaking, I finally have a nice solution.Why this matters and why you should fly it:- It will help you set up your plane properly and give you vital debugging information.- It will help you adjust your stabilization gains- It is a very nice flight stabilizer- It will let you test your Autopilot setup (more on this below)You can read this post to learn about the debugging aspects.What I really wanted to explain is the new Fly-By-Wire mode. It essentially lets you input the relative waypoint location in space, and the plane will try to go there. Now, other than being fun, it is really helpful for debugging and adjusting your gain settings.The new FBW input is proportional and controlled with your radio:Hard right = waypoint is 35° to the right; centered = waypoint is dead ahead; left = -35°Hard up means the waypoint is below you (hey, you can reverse that if you want.) Centered means the waypoint is at the same altitude.While in FBW, the airspeed controller will try and maintain a constant airspeed.Here is the last beta. After this the tester will be final and appear in the download section.Ardupilot_25_Airframe_test_beta4.zipA note about radios - In the header file you can specify radios. Futaba Faast radios can be scanned at 50hz and others at only 25hz. This has to do with how they setup the signals. So there is an option in the header file to use Fubata or other radios. Default is "other." (Spectrum's won't work with the Futaba setting. You need to specify 'other')The events.pde file contains the code for managing your radio's 3 position switch. Instructions are in there as well.The full version of 2.5 should be right around the corner.Jason

Developer

Public beta of the Ardupilot 2.5 Airframe Test

Posted by Jason Short on December 15, 2009 at 12:00am

Hello everyone,The Ardupilot 2.5 Airframe Test is now available as Public Beta. It goes without saying that everything seems to work, but we could use your feedback finalizing this code.Use this release to:- Configure your 2.5 Header files- verify your sensors are functioning properly- verify your servos are not reversed- verify your stabilzation is pointing your plane AWAY from the ground- verify your failsafe is functional- output handy radio values for header files- view the throttle output based on your airspeed sensor- fly a fully stablized plane with throttle based failsafeThe failsafe will cause the plane to loiter slowly at the point of failure. Just try and grab the signal at the next pass. ;)The header file has been moved to be right inline with the other files for your convenience. There are a few hardware specific options listed at the top of the header. Set yours up to fit your plane. Note: If you use this without a Z sensor, you will need to calibrate the XY sensor. (Simply point each side of the sensor at the ground/sky before flying.)For debugging, all the output is sent to the Serial monitor at 10 Hz. You will seeRadio IN: R:1501 E:1500 T:1015 (rudder, elevator, and throttle)Analog IN 0:499, 1: 529, 3: 235 (X, Y, and Z from IR)Sensors: ir_max:305 roll:0 pitch:-4 airSp:0 (IR_max higher number = more resolution, roll/pitch are angles, airspeed should be 0 at rest)PWM OUT: R:1504 E:1517 T:1024 (rudder, elevator, and throttle)As well as:set_mode: ##5| AUTOPILOT The current flight mode indication based on control switch position.*** FAILSAFE DETECTED *** The throttle has dropped 50µs below it's normal cutoff. Set this in your radio's preferences.Radio calibration:When prompted, move the Rudder (ch1) and Elevator (ch2) to the extremes to set your maximum servo travel. You will be prompted to hold the stick into position to move ahead in the process. The servos will twitch, which can be a guide to calibration in the field.Throttle input is disabled by default. Solder a wire from your channel 3 input signal pin to pin 13 to read the throttle for failsafe. Set throttle input to 1 to enable it. (Highly recommended)Adjusting the gains for attitude control - There is really one gain to worry about and that is ROLL_GAIN, and PITCH_GAIN. Lower this gain if things are squirrely up there.This code will spin the propeller. Please be careful...Best of luck,JasonSee this post for the latest version.

Developer

Help testing radios

Posted by Jason Short on December 6, 2009 at 5:41pm

Hi everyone, I'm looking for some volunteers to test some code that's part of the 2.5 release of Ardupilot.I'm looking for a wide range of radios and here's the trick: You need to solder a jumper from input 3 to Pin 13 on your ardupilot.I'm sure some people will have issues, so better to catch them now versus the final release. I'm also going to be posting more code snippets to test in the coming week.Here is the file: Ardupilot_radio_tester.zipPlease center you radio trims before you run this so we can compare output. Use the serial out in Ardiuno to see the output.note:Radio model #Receiver model #Ch3 Failsafe settingCh1-3 values when radio trims set to central positionNote,if you can set your radio's failsafe to drop ch3 value below normal, please try that. Also, let me know if that can't be done with your radio.Thanks!Jason

Developer

Visualizing PID loops

Posted by Jason Short on November 9, 2009 at 3:45pm

This post is an attempt to add a visual explanation of PID loops. I had read Michael King's excellent post , but I wasn't sure how to design loops to do specific things.To me PID loops seemed a bit of a black box, so I decided to graph them out in order to better understand the inputs and output of the equations. They are actually quite simple, but I've never seen a good visual explanation. I may have some details wrong, so if you have additions, please let me know and I will update the graphs.For this example I will show how the steering works on my plane using the rudder. The goal is to connect the bearingError (the difference between the plane bearing and the target bearing) to the rudder. The trick is that you can't just create a direct relationship, or your plane will death spiral. You need to connect the bearingError --> IR sensor --> rudder. That way the plane is always stabilized while it's turning.Here is a diagram of the bearing error. I'm limiting the error to ±30° because I want to limit how fast my plan can turn. More on that later.

IR sensors:The diagram below explains the input you can expect from the sensors. On a hot day you could expect the full range of 0-1023 from them. The value 511 means that the opposing cameras can see exactly the same temperature. This usually means they are looking at the horizon and hopefully you've placed them onto your plane in a perfectly flat orientation. On average days we need to scale the output to the full range, then we offset it by 511 so that we get a positive and negative value for pitch and roll.This graph shows the relationship of the IR sensors output to the rudder. You can see the trough created by the sensor values. The plane can actually bounce around in this trough causing the drunk driver effect.

In this diagram, the sensor output is scaled to .65. This works for my plane, and keeps oscillations at a minimum.

Connecting the bearing error to the IR sensors.In order to stabilize while turning we need to connect the planes bearing to an IR value which we will use as an offset of the actual value. In a sense we are moving the trough to the left or right based on how much we need to turn. I guessed my plane can only safely turn at an angle defined by the IR sensors as ±180. I also guessed I could ignore bearing errors larger than ±30° as my plane can only turn so fast. If you graph the values you'll see 30° bearing = 180IR and -30 = 180IR.

Notice that the proportional term is a lever with a direct output. There is no delay. If you want to have the response be delayed, use the Integrator. To calculate the value for the integrator, take the proportional value and divide it by the number of seconds you want the change to take. For example, if I want change to take 5 seconds, the I term is -6/5 or -1.2If you want some rapid response, and some delayed response, pick a ratio for each, do the math separately and then sum the answer. For example:Output 60IR for proportional and 120IR for the integral. This will cause the rudder to react to 1/3 of the input right away and 2/3 will be applied smoothly over a 5 second period.

A throttle may want all the input as an integral since the smooth transition can keep your plane from torqing sideways.When you take the IR offset value generated by the above equation and apply it to the stabilization you'll see the equilibrium piont has shifted to the right.

The plane will fight to hold that angle by moving the rudder back and forth. If the plane is holding the turn, note that rudder is straight.I know this is pretty basic stuff, but I could not wrap my head around it until I made these graphs.Jason

Developer

AP with Ground Station and 2-way comm

Posted by Jason Short on November 8, 2009 at 6:30pm

I wanted to post the code and exe of the Flash file for the Ground Station and my AP. If you want to try it, you need to do a few things first.(If you try this, remove your throttle or disconnect your ESC from your motor!)1 - Load the DefaultsWriter.pde onto the Ardupilot HW to get some decent values into the EEprom2 - Load the Waypoint Writer onto the Ardupilot HW to put some waypoints into the EEprom3 - Load the JSXPilot_Navigate.pde onto the Ardupilot HW4 - Download Serproxy and configure it as indicated in the cfg file5 - Run the Flash app as an EXE or with a local Flash player or -maybe- it will work in a browser6 - Press the space bar to connect the GS to Serproxy7 - tilt the plane to adjust the IR sensors and the plane is set to fly at 30MPH - it's in debug mode8 - If you want to play further, look in the test.pde and see test versions of 3 important functions. Elsewhere in the code these functions have been relabeled with a "_off" also turn off debug mode in the defines.hThis is a lot, but I'm used to it. Also, this is information for people making there own AP or just curious. It's not supported. It only works with my radio. It's barely tested. The code is very well commented. If you can get it to work for you, you win a gold star.Download it hereYou can see the video here of it in action. GroundStation.mov

Developer

That sinking feeling...

Posted by Jason Short on October 31, 2009 at 6:30pm

Above the Fog from Jason Short on Vimeo.

This is a video of me loosing my plane into the sun and fog for almost 5 minutes. I was just testing my AP that i've been working on over the last month and a half and it was my first flight with working waypoints. I tuned everything way down, but it was working ok so I let it run loops around the T3 course. One thing I turned off for debugging was altitude control. In hindsight, that was a mistake. I could have just dampened it down more, but I shut it off entirely.The plane slowly climbed the entire time and before I realized it was pretty high. Eight minutes into the flight she turned right into the sun and fog bank and I didn't see it again until four and a half minutes later. I was panicking I couldn't take over manual, because it was in the fog. I even thought about running to the car and chasing it until I realized I had no idea where it was. Last I saw it was headed out to sea. I had nothing to do but wait and count the $ to replace it.I stared at the sky for what seamed ten minutes and all of the sudden I saw it gently doing the T3 above me. I put it in FBW and brought it straight down. Enjoy the video, I edited out the 4 minutes of circling. You can hear me fussing with the radio, and I one point I put it in Manual and turned it left in a futile effort to find it. I just put it back into AP and hoped I did a good job. The plane will fly again.

Developer

Orbiting and Turn Prediction

Posted by Jason Short on October 28, 2009 at 1:30pm

I was wondering if anyone had done any work on orbiting or managing turns? I prototyped an idea I had last night about orbiting waypoints and realized the same algorithm works for turn prediction.On my autopilot I have running a drift compensation routine that maps the desired location of the plane onto a line connecting the old waypoint and the next waypoint. I simply look ahead 10% farther on that line and steer toward that point instead of the actual waypoint. This helps me regain course when I'm blown off or miss it entirely.In my simulator I added a check to see which side the next WP is -right or left- and I use a vector rotated 90° to the plane bearing to offset the WP to the left or right. This vector also allows me to orbit the target.Here are some diagrams and a shot from the simulator showing the orbit. If anyone has done this before I'd love to hear about how it went. I hope to fly it this weekend if my replacement ESC ships by Friday.

A screen grab from the SIM

Click to view Flash sim

Developer

XFPilot with Navigation

Posted by Jason Short on October 3, 2009 at 11:30pm

I've been working on this the last two weeks and I finally today did a successful walking navigation using the software. It's an extension of the last version I posted which now includes navigation (EM406 only). It's still a work in progress and I'll have it in the air soon, but until then I thought I'd share.The whole reason behind making this was to create something custom fit for my FPV setup. I'm also interested in trying alternate styles of navigation algorithms which I can now do, and test them with my ground station. All the code is custom written except for the GPS parsing algorithm which was only changed slightly to use Longs instead of Floats. (I'm doing a lot more calculations per second than the current Ardupilot, so I wanted to stay away from Floats.)I'm also reading the throttle input instead of using a 'remove before fly' jumper which frees an Arduino pin for other uses such as Lights or my audio based telemetry.The nav algorithm is pretty simple but it will keep the plane on track during high winds and I use simulation to predict when I'll reach a waypoint and how much I'm turning based on the IR readings. I'll be adding an airspeed sensor soon which will greatly add to the accuracy of the sim and give it throttle control.Here is a copy of the progress and a Flash base station. There are a bunch more features and details in the code and more coming soon. Feedback is welcome, and a special thanks to everyone who wrote the Ardupilot code. I've learned an enormous amount from it.JasonSource Files

Developer

An OSD alternative

Posted by Jason Short on September 21, 2009 at 10:30pm

OK this is half joke, half serious. This is a quick idea I had for the autopilot/FPV unit I'm building. I don't have an OSD and I'm afraid of investing an extra 300+ on a plane that will be going through flight tests in a week. I also don't have Xbee radios nor am I interested in staring at my laptop while my plane flies around. Especially when I've spent so much time on the FPV gear. Here's my lame/fun idea: I picked up a Speech Jet chip that I will wire into the microphone input of my Range Video 900Mhz transmitter. I'm sending out SW Serial through a free pin on the ArduPilot to call out waypoints, heading, altitude, speed, etc.Here's an un-amplified recording. The audio into the transmitter should be pristine when it's done.Play AAC fileBreadboard: