Alternate System Partitioning

[matttay]

One of the guys over at DIY drones hit on something that I think more should consider given the complexity we're facing: A smartphone in the cockpit as the autopilot. He had used an RS232 board to control the servos, but I've done a subtle tweak on that I thought I'd share. No, it hasn't flown yet, but hopefully I'll start some flights in the coming weeks as the snow melts.

The premise is that you put the servo control, 2 axis gyro, pressure sensor, small micro, current monitoring and a bluetooth on a small 1.5" x 2" board. Then you bluetooth the realtime status over to a larger smartphone or PDA and control everything from there. This small PCB goes in-line between the battery and the ESC.

Why partition this way? First is that a modern smartphone/PDA uses a chipset developed by 300-500 people. It is optimized for cost, size and power consumption while delivering an ARM11 at 500+ MHz and floating point support. They are standalone units complete with GPS, 3Mpix camera, cellular radio, SD cards. They run OSs that were developed by another 600+ people, and use an IDE that was developed by another 800 people and support modern languages with rich libraries. You can find all this in ~100 grams, with a self contained battery that is good for 3-4 hours of 100% computing. With lesser use it can of course run for days.

Yeah, you can roll your own. And if its fun for you, then great. But I want to fly and refine the higher level features, and a closed product doesn't let me play with the source, and the open source projects are too complicated to play with on the weekends because there are 10's of thousands of lines of critical code that you really need to understand before you dig into the system.

Smartphones run for weeks without a crash. Microsoft, for example, requires as part of certification that 30 devices run stress tests for more than 20+ hours, equivalent to months of normal use. Like with a PC, if you have good drivers and don't treat the system as an amusement park, then reliability just isn't an issue.

To me, the best approach is to offload the absolute minimum to custom hardware, and do the rest in off-the-shelf hardware.

Attached is a picture of a pcb. It has a an IDG300 dual axis gyro, SCP1000 pressure sensor, MSP430F2274 uP, a Roving Networks bluetooth module, and a DS2756 fuel gauge. The RC RX connects to the top of the board on the right, and the servos connect to the bottom of the board on the right. The bluetooth lets you connect to just about any cellphone or PDA device that you might find. Symbian and MS Windows are of course big candidate devices, but a host of Java phones might also be suitable.

Attached also is a screen shot of an app that receives 50 packets/sec from the board over bluetooth. Each packet contains current servo pulse width and gyro sample. The gyro filter has a first-order RC filter with corner at 7 Hz. On the screen shot you can see the servo data (all railed because the transmitter isn't on), the absolute pressure, the derived altitude, supply voltage, current and accumulated current, temp (from the uP), gyro counts from the ADC and the estimated bank angle based on gryo. In the plot, you see the roll axis gyro output. The leveling PID based on gyro will happen in the uP, but the GPS-based corrections will happen in the PDA. The app is written in c# an moves back and forth between the desktop and PDA with ease (minus the graph).

Curious how to get your current GPS location on a smartphone? In C#, you simply write two lines of setup code, then an event hander gets called when your location is updated. In this case, we'll time stamp the location and save it to an SD card:


void GPSLocationChangedUpdate(object sender, LocationChangedEventArgs args)
{
if (args.Position.LongitudeValid && args.Position.LatitudeValid)
{
sw.WriteLine("Time: " + DateTime.Now.ToString() + " Longitude: " + args.Position.dbLongitude.ToString("f5");
}
}

If you've done any embedded programming, the above can take days, or weeks even if you have existing libraries. On a PDA or smartphone, it's minutes, and you can readily use 32 or 64-bit floats if you want. Because of bluetooth, there are no wires between the smartphone and the rest of the setup. Some might be wondering about the logic of putting another radio link in the air. Bluetooth is a hopper and will happily co-exist with other hoppers or direct sequence schemes such as Spektrum. Everyone uses bluetooth everyday in their car and with headsets...reliability shouldnt' be an issue. But of course I'll learn this in the coming months...

All in all, I hope to keep things at about 1200 lines of C code total on the small micro, and build everything else on a PDA on top of that. No, I'm not looking to sell this. I'll share schematics and source once it has settled down a bit. I'm mostly just keen to get folks thinking more about this approach. It feels right, and the hardware is evolving so quickly right now. 3G operators are allowing video calls...imagine being in a video call with your airplane, seeing what it sees with 200 mS latency, all the while seeing live data streaming back and overlaid on terrain maps that are downloadign in real time while logging everything to an SD card...it's all doable...and it all fits in your pocket...

PS. The IDG300 gyros are amazing. I'd done a fair bit of simulating looking at different ADC widths and sample frequencies. I was a bit worried about the 10-bit ADC, but after playing with these I'm feeling much better. The concern is that slow rolls aren't picked up (that is, those below 1 lsb). But after playing with this I think it'll be fine. The pressure sensor is also very cool.

[zlite]

Sweet! I'm the guy who did the original Windows Mobile autopilot (http://diydrones.com/profiles/blog/show?id=705844%3ABlogPost%3A729) on DIYDrones, and my hat's off to you--this is way better.

We did another form of partitioning, in the sense that we let the smartphone do GPS navigation, communications and imaging, while a stand-alone FMA Co-Pilot did stabalization. The smartphone controlled the rudder, while the Co-Pilot controlled the ailerons and elevator. No communications or connection between them, so the plane kinda skidded through its waypoint turns as the rudder fought the auto-stabalized ailerons.

Your method is a lot more graceful. I found it difficult to keep up with all the smartphone OSs and phone SDKs, and eventually we stopped developing the code at Windows Mobile 4 on the HP iPaq 6515. If you can come up with a portable code base for Windows Mobile [X] and Symbian [any flavor] you will be doing us all a huge favor!

[FrankC]

You might want to look into the .Net environment, the compact framework is being ported to multiple platforms. I did see an announcement of compact framework for the symbian operating system not too long ago. The idea here would be one code base that would run on any device running compact framework. One other option would be programming in Java since it does run on a wide variety of systems.

[zlite]

We did use the compact .NET framework. But at the time we did it (a year ago, but an even older phone) we still needed phone-specific SDKs.

[matttay]

Things have improved a lot in the last few years in that you don't need phone specific libs anymore for things like taking pictures or accessing the GPS. But where things are still a bit uncertain is, for example, what resolution image you'll get from the camera. I've also noted some early issues with the system bogging down a bit when dumping a 3Mpix image to SD.

But, things like sending a text message, making a data call, using wlan, connecting bluetooth, etc, are all the same no matter what smartphone or PPC you are on.

The .net compact framework is indeed being ported many places, and I looked hard at an ARM7 or 9 that supported it. But I didn't want to lay out and bring up a board like that. Something like the gumstix, with bluetooth (aleady there) and a cellular modem (not yet available) and GPS (not yet available) would be a real solid candidate for eliminating the PDA (and saving weight but probably not cost). I also looked really hard at the various 900 MHz dedicated radios and that's another can of worms I didn't want to open as cellular gives you all the range you'll need without resorting to increasingly exotic antennas.

The other down side side of the c# on smartphone today is that it requires visual studio standard edition, which is about $140. But historically microsoft has done what they can to make the tools nearly free, so perhaps that will change. Luckily, most probably have these tools anyway.

[EpicAdventure]

Interesting approach. Seems to make a lot of sense.

Keep us posted as to how well it works.

What frequency range does bluetooth operate in? Same as the spread spectrum receivers?

[zlite]

What frequency range does bluetooth operate in? Same as the spread spectrum receivers?

Yes. 2.4gHz

[matttay]

Last weekend was our first nice weekend in a while, so I took the system up for a flight. Nothing was being controlled by the PCB or the PDA; it was more of a test to see how a bluetooth link worked alongside the spektrum link. No problems noted. The PDA was inhaling every frame of servo data over the bluetooth link and sampling both gyro channels at the same 50 Hz rate, as well as pressure, voltage, motor current, motor energy, gyro data, temp and a 500 mS rate.

The cool part is that the PDA can now speak (over the speaker) the parameters you wish to monitor, AND it can relay that info down to another PDA via a text message so that while you are flying you can hear the battery voltage, speed, heading, altitude, etc, being spoken to you every 15 seconds. So, while you are on the ground doing a range check, the PDA is chattering away how many satellites it sees, voltage, etc. Then when you are moving over 5 MPH, it starts to send a text message to the ground based PDA with the same parameters. Hearing your power and altitude being spoken to you while you are flying is very cool.

Code size on the MSP430 will remain around 1200 lines. All the heavy lifting is going into the PDA. MSP will run the fast inner control loops on gyro and pressure, and manage the servos. The PDA has the GPS and the smarts. The control is a small part of this for me. I'm more motivated by moving maps in teh hand and getting all the telemetry back in near real time in a setup that can be easily pulled out of a pocket.

Next exercise will be alt hold. That's a few weeks off due to work commits.

There arew two pictures to share. The first is the easystar with a PDA velcro'd to the top. Because the link is wireless (bluetooth) to the small PCB, and because the big PDA has its own battery, camera, GPS, etc, it can really go wherever you have room. Teh easystar is a pig in this config. This PDA is a 190g mobile office, complete with power point and excel (no joke). But it's fine for learning. AUW on the easystar is 884g. The Mega 16/15/5 isn't ideal for a plane this weight, but it fits nicely. Also, there are much smaller 90 g PDA and smartphone that will do the same thing. And looks like ATT is now offering 3G video calls. :)

Some data from the Sunday AM logs allows a crude plot to be made of ascent rate versus motor Pin after importing the logs into excel and averaging over 30+ seconds at a time. Roughly the easystar needs about 50W of motor Pin for level flight. That's about 25W/pound. I wish I could say it climbs nicely at 180W, but the motor is too hot on the prop too small for this weight.

[Connexxion]

Man this is awesome!

This is what I call "off-the-shelf"!!!

I finally got a reason to buy one of those nifty PDA's! :D :D :D

Looking forward to following updates.

Connexxion

[matttay]

A few updates...

First, have a look at this PDA: http://www.htc.com/www/product.aspx?id=46286 It features a 3Mpix camera with mechanical focus, 4Gbyte of internal storage, GPS, 3G cellular, video telephony, and it weighs 110 grams. A really good candidate for on-board controller when it arrives.

This evening I flew the easystar with the elevator loop closed. When I flipped the gear switch on radio, it attempted to hold the current altitude. As you can see from teh graph, the gain was too high. But I'll tweak and try again later this week. The graph shows AGL altitude (barometric) in meters on the left axis, along with stick position (0 to 100%) on the left axis. On the right axis you see the correction applied to the elevator (+/-360 uS of servo adjust), heading (deg) and turn rate (deg/sec). I'll make the gain adjustable via the PDA so I can tweak right on the plane if needed for more testing.

I've done a fair bit of profiling of .net compact framework. Suffice to say I continue to be very enthused. Recall the small custom hardware board is shoveling over 4 channels of servo positions and gyro data 50 times per second. Voltage, current, pressure, etc, are coming over at slower rate (about 2 Hz). The PDA grinds on the data, and ships adjustments back to the custom hardware board 10 times per second. The custom hardware board uses the gyro info to close a very short term loop (about 160 mS total impulse length with 20 mS sample interval, or 50 times a second) for pitch and roll stability. I fly near 4000 foot mountains so techniques that others are using (such as the great work on Attopilot) would be difficult since the horizon can't be seen except for about 60 degrees of the 360 panorama.

In profiling the .net CF code, the main control loop, using doubles, is taking 1012 uS. Decodign bluetooth packets is taking 2011 uS. This is all without optimizations, so I'm pretty confident this is a viable way forward.

I've done some experiments taking photos on the PDA programatically while running the outer control loops and it seemed to work fine. Additionally, I'm logging just about everything I have at 50 Hz, so the system is being asked to do a lot and not visibly complaining yet.

In any case, graph of tonight's flight is attached, along with current schematic as jpg. All the GPS math routines are in and debugged on the PDA, along with the communication with the ground station. I'll hopefully get the elevator loop respectable this week, the roll loop respectable next week, and some simple "fly back home when I toggle the landing gear switch" the week after that.

If you look at the schematics and want to build a board, I'm happy to send you the current source. I had the boards made at Silver Circuits, and had a few assembled by Lil-Brother LLC here in the US. They know the design, and could probably assemble a few for you for under $100 if you provide parts. Part cost is about $50 for the gryo, $20 for the pressure sensor, $3 for the uP, $40 for the bluetooth module, and probably $20 for everything else. Lil-Brother folks are good guys. The PDA code might be a bit more of a challenge, as it uses source from around the net without a clear license, but we can probably work something out. No, this won't ever be turn key, but if you are looking to get deep into the inner workings, this is (yet another) way forward. But I like the think the PDA elmiinates an enormous amount of complexity that is present on every other auto pilot project. I think it is indeed feasible that you'd never have to muck around with the 8-bit micro code. Instead, you could develop directly on the PDA using world-class tools.

[matttay]

Two updates.

The first is that I'm at a reasonable point in the pitch and altitude hold problem that I can move onto the roll and direction loops.

In the first plot, you'll see a flight in which altitude was held reasonably (within 10 meters) in light winds but with steep turns AND with zero coupling between rudder and elevator. In other words, the plane had no idea it was turning. This is a challenge because as a plane banks to, for example, 35 degrees, the lift of the wing drops 20% and the nose will usually tip down. Even on the easy star is doesn't like to correct itself until it has accumulated a lot of speed over several seconds. When you know you are turning, some of the rudder or aileron can be coupled into the elevator to make this less of an issue, especially on steeper banks. So I'm looking forward to a bit of that too.

There are two loops currently running for the elevator, and I've been able to move the gyro loop off the microcontroller and onto the PDA. The PDA and C# continue to really impress me. I really hoped I could do the elevator with just altitude, but not such luck. The turns were the killer. But it was also possible to get into a nose up position and not realize it until it was too late. The subsequent corrections were not subtle. I've thought a lot about how I fly, and especially I've looked at data of my manual flights and it's amazing how little the sticks need to move to stay level. As you look at the plot of the data, keep in mind that 10 uS of change in elevator is about 1 click of trim. The pink trace is the elevator servo (min is 1 mS, max is 2 mS, althought the axis values aren't clear for this one trace), and generally it just wanders up and down one click over a second. During the two minutes shown, the total span of control is about 4 to 5 clicks of trim. My previous efforts were much more aggressive. Intuitively it seemed that having a computer almost going rail to rail on the elevator would be a good thing. It's not. I can tell you it makes the ESC really, really hot. Of course.

The pitch and roll gyros are sampled at 50 Hz, and sent to the PDA over bluetooth. The PDA extracts an average that eventually is comprised of several minutes of samples (to account for gyro drift) and then uses a leaky integrator to form an estimate of pitch. The assumption here is that over several minutes your average pitch will be 0, and that you won't have a "significant pitch departure" away from 0 for more than 10 or so seconds (if you do, it eventually "leaks" down to zero and then when you correct yourself you are in trouble). Based on all the log data collected so far, I think these are both reasonable.

In the graph, you'll see the current parameters of interest. Some signs are wrong on the display because I've opted to adjust everything so that when I see it going up, it means the plane is also going up. That doesn't hold across the board, but it helps in viewing this stuff.

So it's onto heading and bank hold, using the same approach.

About half way through this, I realized that even being 10 minutes from a flying field meant there was signficant turn around time to figure out a sign was wrong (I had my first crash...it wasn't serious but I tend to test low because I like to see what it's doing (50 to 100 feet) and tend to want to see as much data as possible, so I didn't flip back to manual control in time...PDA broke loose, but nothing broke).

Thinking more on this, I ended up (again) on the DiyDrones site, and read about a guy using FlightGear to test his AP. After downloading flight gear, and seeing the web-based interface, I was controlling altitude in about 20 minutes from a simple app. In another 20 minutes, I had my PID loops, GPS lib and math libs pulled over from the PDA. Another few hours had the graph and some clean up. So, I'm also including an early shot of a standalone autopilot that can control any of the full-sized models in the FlightGear simulation. This is indeed an excellent platform to workout the waypoint math and sequencing. My hat is off to those guys as the interface (http-based) is awesome, albeit a bit taxing if you want to pull every little bit over.

You can see a screen shot of the app below. You can set parameters on all 4 loops (baro alt + pitch gyro for elevator, bank angle + GPS error for rudder). In the screen shot, the graph shows altitude versus time. About halfway through I bumped the altitude up about 500', and you can see the step response to the change plotted in blue. In any case, incredibly useful--not so much for tuning, but for making sure the maths are correct. The possibilities here are really endless...quantizing sensor data to N bits, adding noise, changing sample freqs. It's is amazing how much I've learned with with this. And it saves you from having to go the flying field, say hello to everyone, put the plane up, flip the auto pilot on, realize something is wrong, bring it down, and head back home in 5 minutes. Embarassing isn't really the word...but it's getting close.

I am having a bit of trouble with bluetooth latency going back to the microcontroller board. Not sure if it's in the bluetooth module, or if it's in the PDA. I suspect it's in the PDA, and that the PDA is wanting to buffer chars for a bit before sending them over hte wireless link.

That's all for now.

[matttay]

Quick correct: the total range of correction from teh autopilot is shown in green on the graph. It ranges from about 0 to -130, so that's roughly the same as about 13 clicks of trim.

[matttay]

Weather was bad tonight. I worked some more on the desktop autopilot.

The screen shot below shows the waypoint sequencer added, along with live map in the lower left (thanks to USGS), and the FlightGear simulator window in the lower right (I just moved the window over, it's a standalone app).

I found one bug that I know would have taken a long time to find flying at the field, so I'm happy about that.

The airplane is still the J3, and it's flying out of an airport someplace near San Jose. I've been able to dial up thunderstorms and turbulence and insance winds and watch the autopilot cope (or not). Soon I'll start looking for model airplane parameters rather than full size. The waypoints are about a mile apart, so this isn't a small, tight course by any stretch.

Note that in the gains for the heading, it's all zeros. I went into this thinking aileron position would be a function of heading error. Instead, I ended up with bank being related to heading error.

Waypoint targets are 100 m in diameter. Max bank limit is 20 degrees.No particular reason for either at this point.

I'm about at the max sample rate using the easy (web based) interface to FlightGear. As time permits I'll move to the high speed interface, where I shoudl be able to reduce most loops down quite a bit if needed. Note that FlightGear appears to be running the internal physics simulations at 1200 Hz, so there's merit in in trying to get this to run faster.

[clolson]

Hi Matttay,

It's good to hear that you were able to get up to speed with FlightGear and make it do useful things.

It's refreshing to hear that someone with some network understanding can get up to speed and talking to FlightGear in a pretty small amount of time. If you'd like some hints/tips for optimizing your connection and use of FlightGear, feel free to drop me a note.

For what it's worth, the built in flight dynamics engine of FlightGear runs at 120 hz.

I've been using FlightGear to visualize flight paths and actual control surface deflections commanded by my autopilot. In addition it's possible (with a bit of hackery) to drop virtual bread crumbs in the sky so you can see your route and if you are flying a circuit, see the repeatability of your autopilot.

FlightGear has a multiplayer interface and a google tracking map tied to that, so that's another way you can leverage FlightGear to do fun things ... especially if you bring a net connection to the field with you ... it would be possible for anyone in the world with a web browser to live track your UAV (if it's feeding it's live telemetry into FlightGear and if that copy of FlightGear is connected to the multiplayer system.)

If you are looking for smaller aircraft, take a look at the Rascal 110 that is modeled in FlightGear. It's not perfect (and is really way too squirrelly on the ground) but once airborne it's not bad. My Rascal 110 is powered with an OS 160 FX so it's way overpowered and airborne before the rpm's can even come up to full throttle, so some of that is probably reflected in the FlightGear dynamics model.

http://youtube.com/watch?v=sAzDpq5gnVY

For what it's worth, I used the Rascal flight dynamics to tune the gains for an initial stab for my real autopilot (MicroGear) which uses the same autopilot xml configuration file / and autopilot algorithm as FlightGear. The result wasn't perfect, but it actually flew right out of the box. I thought that was kind of cool, and yet another way to abuse FlightGear.

Regards,

Curt.

[matttay]

Whoa! I didn't know you were the author, nor did I know the author liked RC. I've been super pleased with the http interface into FG. What a great way to let someone start tweaking in minutes. A lot of times you download something with high hopes, it fails to install, then it crashes a few times, then you can't make the simplest thing work, and on and on. This has been one of those rare occasions where everything has just worked, and worked as expected. Congrats.

As I was watching the autopilot zip over the USGS map, I saw a lake on the map and out the window of FG at the same time. Made me smile. Has anyone done any sort of synthetic vision system for remote flying? I have UDP latency around 500 mS from air to ground, and because it's cellular, reliability is pretty good. How good is your terrain database? I've been playing with a web service from the USGS that lets you send a lon/lat, and it replies back with an terrain height in about half a second.

Thanks for the offer for help on some more advanced interfacing help. I think tonight I'll play with UDP. I see how to get FG to send all the stuff I was getting over HTTP via UDP, and I see how to get the ports and intervals set. But it's not clear how to send stuff back (such as elevator position). Do I define another xml protocol and set another option via command line and then just start pumping the values over the right port and FG figures everything out from there?

What control update rates do you would be possible over UDP? Seems like 20-30 Hz shoudl be pretty doable on a snappy machine with FG running VGA with fancy stuff turned off, yes?

Again, really nice work.

[clolson]

Whoa! I didn't know you were the author...

I'm one of many authors, but have been in it from the start and largely carried it on my own shoulders in the early days.

... nor did I know the author liked RC.

I bought my first airplane (Sig Kadet Mk I) with money I earned from a summer job after my 9th grade year. But way back when I was a kid, there was a guy that used to fly in the early evenings near my house. Every time we'd hear the engines fire up we'd burn rubber over to where he flew and watch and hope for a crash. Hehe, crashes seemed cool way back then when it wasn't my stuff and I had no idea the cost or effort that went into the airplanes.

I've been super pleased with the http interface into FG. What a great way to let someone start tweaking in minutes.

I turned out to be kind of a neat thing ... you turn it on and you can immediately have full control over the simulator from any remote web browser. I've used it as a remote debugger once in a while to inspect certain internal values of the sim as it runs. There's usually better ways to do that now, but it's still kind of nifty. Note that we have a very similar interface that dispenses with all the http wrappers so it's much leaner if you are talking to flightgear from a remote program or script.

A lot of times you download something with high hopes, it fails to install, then it crashes a few times, then you can't make the simplest thing work, and on and on. This has been one of those rare occasions where everything has just worked, and worked as expected. Congrats.

Well to be fair, a number of people seem to be able to make flightgear crash on their systems or have install problems, but I think it goes pretty smoothly for most people.

As I was watching the autopilot zip over the USGS map, I saw a lake on the map and out the window of FG at the same time. Made me smile. Has anyone done any sort of synthetic vision system for remote flying? I have UDP latency around 500 mS from air to ground, and because it's cellular, reliability is pretty good.

I tried once to fly an R/C airplane using FlightGear as a live synthetic view, but failed horribly. In retrospect I discovered we were getting about 1.5 second latency on our serial radio modem because our sensor was saturating and overflowing the bandwidth. And it was an extremely windy/bouncy day ... the airplane could literally turn 90-180 degrees within that amount of latency.

Now that I have MicroGear, I've been meaning to go back and work on tuning the data packets so the link is never saturated and try again, but there's always too many fun ideas and not enough time ...

How good is your terrain database? I've been playing with a web service from the USGS that lets you send a lon/lat, and it replies back with an terrain height in about half a second.

FlightGear's terrain database is derived from the USGS SRTM2 data set (probably the best free terrain data set with world wide coverage.) We simplify the terrain a bit to make it reasonable to render in real time, but FlightGear can return the terrain elevation at any point you provide. I've always thought that would be a neat extension to an autopilot ... have the ground station continuously relay up the ground height below the UAV. Of course I've only flown in MN and over the ocean so terrain has not been a big factor for me.

I should point out that if you use FlightGear as part of your ground station (which gives you a live synthetic 3d view, optional HUD, and optional 2d or 3d instruments) then you can monitor approximate height above ground yourself, even if the UAS has no idea where the ground is.

Thanks for the offer for help on some more advanced interfacing help. I think tonight I'll play with UDP. I see how to get FG to send all the stuff I was getting over HTTP via UDP, and I see how to get the ports and intervals set. But it's not clear how to send stuff back (such as elevator position). Do I define another xml protocol and set another option via command line and then just start pumping the values over the right port and FG figures everything out from there?


There is a "generic" protocol where you can define a custom set of fields via an xml config file, but I haven't played with that too much myself. There is also an FGNetFDM and FGNetCtrls structures that are already defined and flightgear is setup to be able to send or receive those structures via udp. If you poke around in the source, take a look in .../src/Network/ The specific structure definitions are "public domain" so you can suck those headers into your own code and save yourself a bit of time. (If you poke around in that same directory you can see that FlightGear can also send/receive things like nmea gps strings so you can trick other gps software into thinking it's connected to a real gps, but instead it's connected to a fake gps ... i.e. flightgear. I've even been able to slave a Garmin 295 to flightgear ... that's fun.

What control update rates do you would be possible over UDP? Seems like 20-30 Hz shoudl be pretty doable on a snappy machine with FG running VGA with fancy stuff turned off, yes?

Again, really nice work.

The network is serviced every frame. So if you are able to run at 60hz, then you can accept or generate up to 60hz data. You can shove data at FlightGear faster than it can run and FlightGear just slurps in all the accumulated messages when it services the network and uses the most recent data if there are multiple incoming messages in the queue.

Regards,

Curt.

[matttay]

Thanks! I've gone the xml + udp route for now and while packets are flowing back and forth and appear to be getting digested by both sides, my drive signals to the ailerons and elevators aren't working like they used to. However, everything is very snappy, much snappier than using HTTP.

I'm writing, for example, 0.01,0.001 + 0x0a to send a 0.01 to the elevator and 0.001 to the ailerons. But what is confusing is that is looks like it "takes", but only for a split second. Then it reverts back to its old value of 0 when the FG app sends its next round of control positions

So, my question is, when I write to set the elevator control, would you expect all subsequent reads of that value to return what I just wrote? It did appear to work that way using the http interface. I am seeing a "Error reading data." from the console dribbling out, so I'll track that down to make sure.

Thanks for any advice.

<?xml version="1.0"?>

<PropertyList>

<generic>

<input>
<line_separator>newline</line_separator>
<var_separator>,</var_separator>

<chunk>
<name>Elevator</name>
<type>float</type>
<format>%f</format>
<node>/controls/flight/elevator</node>
</chunk>

<chunk>
<name>Aileron</name>
<type>float</type>
<format>%f</format>
<node>/controls/flight/aileron</node>
</chunk>



</input>

</generic>

</PropertyList>

[clolson]

Hi Matttay,

I don't know a specific answer, but make sure you don't have something else competing to control those same values. A joystick plugged in would be an obvious example, but maybe there is something less obvious going on.

Regards,

Curt.

[Timbo337]

How stable is the software platform running C#? I wouldn't trust the framework for autopilot use, especially over public land. That is one big problem I can see with using a pda, but then again I don't have one. This is all just speculation.

[matttay]

How stable is the software platform running C#? I wouldn't trust the framework for autopilot use, especially over public land. That is one big problem I can see with using a pda, but then again I don't have one. This is all just speculation.

So far it's not at all an issue.

What makes you think a PDA is any less reliable than a hand-rolled Linux platform or any other custom platform? If you've ever ridden on an Airbus airplane, I'm sure you've had the pleasure of watching the in-flight AV system reboot to the LILO + penguin screen several times during the flight.

[matttay]

Finally had a chance to work on this some more after several long weeks away from it.

Updates are plot of flight over several waypoints, and also c# source to the autopilot. Again, I'm just runnning on FlightGear simulator, so don't panic when you see me tracking waypoints over an airport. When I last left the actual Easystar, I'd only achieved level flight via AP and hadn't started on waypoints. I'd also come to the conclusion that debugging via flying and looking at logs was taking just way too long, and thus the diversion to the Flightgear being driven by the desktop app. Next steps are to move the desktop code to the PDA, a task I've done many times. I'm not expecting surprises there and the code will likely move with zero changes.

Desktop AP is running 10 Hz for the autopilot loop. Recall there's a small hardware board that runs at 50 Hz and serves to swallow every real real-time task the system requires. The PDA, while it is responding in real time, likely cannot guarantee realtime performance 100% of the time (but then again, unless you have done worst case analysis on every driver on any platform, you cannot guarantee that on Linux, WinCE or anything else). The small micro, however, that runs at a 50 Hz rate CAN guarantee my real time needs. The upshot is that it's possible the PDA might drop updates occasionally, but the system will cope just fine. If you drop a 100 mS update, then you might delay a decision for 100 mS. But when the next sample comes, you'll be back on schedule.

Every 100 milliseconds, I take the info from flightgear, and then create artificial gyro info, and also artificial altitude info. I delay the lon/lat from flight gear by 1 second, and int the case of GPS, I throw away every 9 samples (to simulate 1 Hz update), and in the case of alt I throw away every other sample (to simulate 5 Hz update). The alt and gyro signals get noise and drift applied. The alt signal is getting fuzzed with normally distributed noise with a standev of 1.2 meters.

The jpg is a shot of the test app that runs on the desktop. It pulls down a map from the USGS, and then plots where flightgear says the plane is every 100 mS. The plane used is the RC Rascal. If you look closely on the jpg, you'll see the path is is red dots with green lines between. The red dots signify GPS updates, the green dots are the estimated location. If you look around the turn coming out of waypoint 0, you'll see how the estimate breaks down a bit.

The attached source code is the c# for the autopilot class that actually tracked the waypoints. These classes will move without change to the PDA. Recall from previous notes on benchmarking that I'm super happy with c# efficiency, and not all all worried about keeping track of so much history. There's a lot of clean up still needed here. I've gone through some pretty major restructuring. Testing all this on the sim means I can fly for hours and hours, with light wind, heavy gusts, long GPS delays, short GPS delays, and model gyro drift, altimeter noise, etc, and really learn a lot. It has been a huge time saver.

Hopefully the next time I post again it'll be with the easystar flying a course.

[capt]

subscribed