Tag Archives: technology

2026/02/08 · 14:52

Experimenting with an AI aviation assistant

I’ve written before about using AI tools for various tasks, and I’ve been pretty clear that they still need human supervision for anything factual. But I’ve been experimenting with something that feels genuinely useful: an AI assistant that can actually do useful things on my behalf, not just answer questions.

I’ve been using Claude as an AI tool for a while. It was sort of the gateway drug for me; its writing and reasoning skills have been a better fit for my needs than any of its competitors. Then I started experimenting with Claude Code, the Claude-based AI coding tool, and have lately been using Claude Cowork (both of these will be the topic of future posts). But all of these tools basically work by executing specific instructions you give.

The assistant tool I wanted to try is now called OpenClaw. It was Clawdbot, but Anthropic didn’t like that intrusion on their trademark. Then the creator picked the (dumb) name “Moltbot,” but realized it was dumb and changed it again.

Whatever you call it, the basic idea is simple: an open-source project that runs on your own hardware and connects to your choice of messaging apps. I have it set up on a Mac mini in my office, and I talk to it through WhatsApp. Intstead of only the AI being a chatbot you visit in a browser, it’s more like having an assistant sitting at a computer 24/7, waiting for instructions. The assistant can do things on a schedule or on demand, and its capabilities are limited mostly by how willing you are to give it access to stuff.

I set it up on a Saturday afternoon; t only took about 30 minutes to set up OpenClaw on my Mac mini. I started by telling it to create skills to read and send email and calendar messages in Microsoft 365, then connected it to my robichaux.net mail account. I fooled around a little by asking it to do various cleanup tasks in my mailbox and my reminders app, all of which it did well.

A winter escape attempt

The next morning, I had a flight planned KHSV-KTLH to take Cecelia to visit Florida State‘s campus. The weather was forecast to be awful (remember the big winter storm in late January 2026? Yep, that was the weekend), with low ceilings, potential icing, and en route IMC pretty much non-stop. I used my normal combination of EzWxBrief, Foreflight, and skew-T diagrams to check the weather, and decided that we should leave Huntsville about 10. At that time, it was raining, about 40º at ground level, with a 3500′ ceiling. There was a line of moderate precipitation diagonally across our path for about 45 nm, but there was no forecast icing and the freezing level wasn’t a problem, so off we went. After a normal takeoff and climb out to our planned altitude, we bumped along through periods of showers until, sure enough, things smoothed out about 50 nm along. Then I had some time to think.

See, the current conditions at Tallahassee were 200′ ceilings. They were forecast to improve to at least 600′, and I’d filed Valdosta as an alternate, but I wanted to keep a really close eye on on the conditions as I went. That got me thinking about my helpful assistant.

Teaching old bots new tricks

Claude, Claude Code, Moltbot, and many other tools can be extended with “skills.” Skills are basically plugins that give the AI new capabilities. Some skills come built-in, and others you can create yourself—or, more interestingly, you can ask the AI to create them for you. A skill is essentially a self-contained module that extends what the AI can do. Skills can include code, configuration, and documentation. The AI can read the skill’s instructions and use it appropriately. Think of it like teaching someone a new procedure—once they learn it, they can apply it whenever it’s relevant. The important bit is that skills persist across conversations, so the AI “remembers” how to do things you’ve taught it.

Now, luckily my plane is well-equipped. I have onboard ADS-B datalink weather, where the FAA uplinks ground weather data that can be displayed on my cockpit displays and iPad. I also have Starlink, so I can see pretty much every kind of weather data available on the Internet. But, well, I wanted more. I wanted my new bot to do some of the work and check the conditions to tell me if and when they changed, and for that, I’d need a skill.

I started simply by asking “Do you have a source for aviation weather data?” It didn’t—but instead of just saying “no,” it went looking. It found the NOAA Aviation Weather Center APIs (https://aviationweather.gov/data/api/), which provide access to METARs, TAFs, PIREPs, AIRMETs, SIGMETs, and all the other alphabet soup that pilots live by. Then it offered to create a skill to access those APIs. I said sure, go ahead. A few minutes later, I had a working skill that could fetch current weather for any airport.

Moltbot’s first self-developed skill

Now, this may not seem earth-shattering. After all, in the plane I have the same data available from the ADS-B datalink and via the Starlink connection and (when in range) via VHF radio. And the skill itself is dirt-simple; it’s a small Python script that hits an open REST API. The point wasn’t to get the data to me, it was to get it to the bot so it could do stuff with it.

Armed with this skill, I could ask the bot to alert me if something changed. This is a valuable trick, since it meant I could carry on flying and let the bot tell me if anything interesting happened with the weather.

Moltbot task to alert me on weather changes

I set that alert when I was about 1:15 away. It ran for a while and… nothing changed.

Adding leverage to the skill

When I didn’t get any alerts, it was easy to confirm on ADS-B that the weather hadn’t changed. That was good, in that it meant the alert mechanism hadn’t failed, but it was bad in that I wouldn’t be able to land at Tallahassee. However, the fact that the bot’s based on a really powerful LLM started to come in handy right about now.

Letting the bot do the work for me

This simple query did several things that I didn’t explicitly ask for. It searched for airports, sure, and tried to figure out which ones had rental cars, but it also looked up the weather at each one and summarized it so I know that Panama City, Gainesville, and Jacksonville might be legitimate options because their weather was better. The LLM was smart enough to skip smaller airports like Perry-Foley, even though they were closer, because they don’t have rental cars. Armed with this information, when I checked in with Tallahassee Approach I told them I’d continue to KTLH but that my alternate would now be Panama City.

In the event, the weather had improved; I broke out at about 600′ and made one of my nicer landings.

Planning

Then I started thinking of other things I often need to do, including planning multi-leg flights. A few more exchanges and I ended up with an additional skill to calculate flight time between two airports (taking winds, altitude, and airspeed into account). Of course this is simple math, and probably not as accurate as Foreflight’s planner because it doesn’t take climb and descent into account. But who cares? Now I can do things like this:

From there it’s a very short step to generating a calendar invitation with the leg lengths and times. Voila! Now my wife knows when and where my route will take me, I have an estimate that I can use to figure out where (or if!) I might get to eat en route, and I can easily block my calendar appropriately when I’m traveling on a workday. It’s as simple as telling the bot “Schedule me for Angel Flight mission 2026-xx-yy from HSV to GAD to MCB to HSV” and it does the rest. (I didn’t try to automate flight plan filing, although there is an API for that).

Adding web browsing and purchasing

Inspired by some of the other stuff I’ve seen people doing with OpenClaw I decided to empower it further by giving it the ability to browse the web. To do this safely, I set up a Bitwarden password vault. I don’t use Bitwarden for anything else so the bot can’t access anything I haven’t given it explicit permissions for. I added credentials for Aircraft Spruce, Planelogix, and Aviation Oil Outlet, then a unique Visa card number I generated.

The first result went really well: it successfully navigated to Aircraft Spruce’s web site, figured out that I needed Tempest AA-48108 filters (since it remembered I had a Baron that has IO-470 engines), logged in as me, and added 2 filters to the cart. It couldn’t complete the checkout because Spruce uses a CAPTCHA, but one click later it had ordered.

Then I told it to get me some oil:

In the background I could see it open the Aviation Oil Outlet page, so I went off to do something else (teaching the bot how to access my airplane’s dedicated Outlook.com email account, which means now it can see my personal and airplane mail). It then seemed to be stuck so I prompted it… and oops, now we have a problem.

See, this is the problem

I’ve been using gen AI tools for a good while now, so this is a familiar problem. Just like a human might, these tools can lose awareness of the context they should be in (or they can have insufficient context to make the correct decision). In this case, the bot assumed it had enough of the correct context, and it didn’t, so now I have an extra order to cancel. This is not a big deal in the grand scheme of things, but it’s a pattern I expect to recur as I give the bot more autonomy.

Maybe I should have put this warning up front: don’t give the bot access to anything you can’t afford to lose. This includes money, API keys, crypto, your fund of cat pictures, or whatever. In this case, my email is backed up, the one-time Visa number has a hard (and small) limit, and the sandbox the bot’s in doesn’t have access to anything important. The security of tools like this is fluid, because while OpenClaw’s maintainers are busy fixing bugs and adding protection, attackers are busy figuring out new ways to steal your lunch money. If you’re not already deeply aware of and comfortable with web and application security, you probably shouldn’t install OpenClaw or its (inevitable) successors.

and yet…

While I was typing the preceding two paragraphs, OpenClaw successfully figured out how to cancel the excess set of filters it ordered, and it finished ordering my oil. I think I’ll keep it around for now.

2 Comments

Filed under aviation

Tagged as , , , ,

2025/05/09 · 07:41

Flying Friday: flying with Starlink

tl;dr: Starlink is an amazing addition to my airplane that makes my flying safer.

Last year, I bought a Starlink Mini antenna with the intention of using it in the plane. For $50/month, it sounded too good to be true… and it was, since Starlink nerfed the service after about a month by reducing its speed limit to 100mph. Over that speed, you’d get a petulant message telling you to slow down. The least expensive plan that would work at Baron speed was $250/month, and it wasn’t worth it to me.

The good news is that Starlink was apparently paying attention to the GA community and introduced a new “local priority” plan. For $45/month, you can use Starlink in motion, over land, at speeds of up to 250mph. You buy data in blocks of 50GB, for $20 each, so $65/month gets you up to 50GB of in-motion data. That’s about perfect for what I wanted.

The Starlink Mini hardware draws between 20 and 40 watts in normal operation, with a draw of up to 60W at startup. I have a 28V airplane, so I bought a 100W-capable USB-C PD cigarette-lighter plug and I was in business. I’m still working on a mounting solution that I really like; I’ll post more about that another time. Here’s a teaser picture of one attempt that didn’t work very well.

I wrote an article that should appear in next month’s Aviation Consumer that talks about how the system works in more detail. Instead I wanted this post to reflect on two recent flights where having Starlink in the plane made a measurable difference.

Before I get to that, let me briefly digress about in-flight weather data. The FAA operates a system called ADS-B. Part of that system is a subsystem called FIS-B that rebroadcasts weather data from the ground to airborne aircraft. This includes both information about current conditions, but also forecasted warnings. The most important thing to know about this data is that it is not guaranteed to be in real time. There is typically a delay of between 5 and 20 minutes for radar updates. The data comes from the National Weather Service network of WSR-88D radar systems and then is processed in various ways. That processing takes a while. And so what you see in FIS-B is what things looked like at the time that radar image was taken. As famous aviation writer Richard Collins was known to say, “The only weather report you can trust is what you see out the window.” Many pilots have come to grief by trying to use this time-delayed radar image to navigate around storms and instead ending up in the storm area.

I don’t have onboard radar, but I do have onboard lightning detection. The combination of the FIS-B radar data, the onboard lightning detection, and my eyeball usually works pretty well to help me make tactical decisions. But eyeballs and sferics don’t do any good for long-distance planning. FIS-B has a lower-resolution radar feed that includes the entire continental US, but that’s also time-delayed. My electronic flight bag (EFB) app, ForeFlight, has higher-resolution radar layers available via the Internet, but that doesn’t help in flight… until now.

The first case was when I was flying back from Dallas for work. There were storms forecast for western Mississippi and northwestern Alabama, and it looked like I would, just maybe, beat them home. I wanted to have a plan in place in case I didn’t, though.

Enter Starlink. Here’s a sample screen shot from the RadarScope app, showing minimally-processed output from the WSR-88D at Hytop. This data is still not quite real time, but it’s much higher resolution than the FIS-B feed. RadarScope lets me see additional radar data types, not just reflectivity, so it’s much easier to figure out whether the radar returns actually represent a growing storm, a more benign area of rain, or a dangerous full-grown embedded thunderstorm cell. I pulled up RadarScope and was able to look at the radars across AL, MS, and TN to get an idea of what the storm line was doing. Then I swapped over to watch a Facebook Live broadcast by local meteorologist Brad Travis. He was predicting the storm arrival time, severity, and impact across the area west of Huntsville, exactly where I was going to be flying. The combination of updated radar data and a real-time review of that data by an expert told me it was time to land and wait the storm out. I diverted to the airport at Haleyville, waited about an hour in dry safety while the storm blew through, and had an uneventful return to Huntsville.

The second case was on a recent trip to visit my mom and sister in Galveston. The weather at Galveston had been gusty and cloudy thanks to two large low-pressure systems with a high trapped in between them. Here’s a comparison of what I saw from FIS-B versus what I saw in Foreflight radar data. First the ForeFlight image: there’s a storm cell to the upper-right of my flight path (past KBMT), and another off to the left, but no serious precipitation, and no storms, along my route of flight.

Compare that to what I was seeing from FIS-B. Some of the difference is one of scale (I had the Aspen display set to a 100nm scale, and it’s a physically smaller display). Some is due to the different resolution of the data. But the FF image made it obvious that I’d have good clearance from the storms to my southwest.

On the way home, I had the same problem; those two low-pressure areas were boiling up a 400-mile-long line of storms to my north. I planned to leave Galveston southbound and then turn east to fly along the lower edge of the Louisiana coast. Unfortunately, the weather at Lake Charles, and to the north, was terrible, so I ended up getting routed to Grand Isle. Here’s ForeFlight, showing the FIS-B data. You can see how much lightning there is in and around the straight-line path from Galveston to Huntsville.

You might wonder why this image shows the FIS-B data. It turns out that the local priority plan for Starlink only works over land and in coastal waters and I was about 40 miles offshore, well outside the 12-mile coastal-water limit. I didn’t get service back until I was nearly to Grand Isle. In fairness, FIS-B is only available in CONUS too; for example, if you fly to Canada or the Bahamas, you won’t have FIS-B weather data.

Starlink complaining that I’m out over the water

There were a number of pop-up thunderstorms along my route; the easy availability of updated and timely radar data helped me proactively ask for route changes to stay well away from them.

I’m not even touching on the utility of being able to use the Internet in cruise flight. Running behind schedule? Call the FBO and tell them. Diverting for weather? Book a hotel at your new destination. Bored passengers? Let them watch Netflix. All of the same capabilities that make in-flight Internet so useful on commercial flights apply here too, but to me, the safety benefits of getting better-quality weather data, and more of it, and in less time, make Starlink a must-have.

1 Comment

Filed under aviation

Tagged as , , ,

2025/01/02 · 08:28

2024 year in review: flying

On the surface, by comparison with last year, this year was sort of mixed. I didn’t fly as many hours (110 vs 128 last year), and I didn’t go to as many interesting places. However, with that said, it was still a terrific year.

The biggest highlight was passing my commercial multi-engine check ride with FAA examiner Charles Welden. I was having lunch one day with my friend John Blevins, a fellow pilot and a great American, and he asked how my training was going. I told him I hadn’t had any luck lining up a multi-engine instructor who was a) qualified in my plane and b) available when I was. John chuckled and said he had me covered. He did, as he introduced me to Anand Iyer out of Atlanta. Anand is a Ph.D. candidate at Georgia Tech, a former NASA employee, and a terrific instructor. I spent two weekends flying and studying with him and then popped down to Shelby County to take my check ride. It was by no means easy, but it was doable. Mr. Welden was a personable and fair examiner and I’m looking forward to (spoiler alert) going back down to Shelby County to do my seaplane rating later in 2025.

While I didn’t travel as far north or south this year as I did last year, I still covered a fair bit of ground. I did day trips to Dallas and Houston for work; trips to Alexandria, New Orleans, Lexington, Savannah, Covington, Gainesville, St Augustine, and Panama City for fun; and Olive Branch, Newnan, Nashville, and Birmingham for Angel Flight missions. Bonus, I also flew to Starkville and Columbus a bunch for shuttling Anna back and forth. All told I flew a little under 17,000 miles.

Thankfully all the equipment and systems on the plane functioned pretty well this year. I had a couple of minor nits (like a flat inner tube on one main gear tire) but no real showstoppers. I think I had pretty close to a 100% dispatch rate, although I traveled so much for work that it’s sort of hard to tell.

One fun fact: I had a precautionary shutdown last year, the cause of which I thought was fixed at the January 2024 annual. I had to cage the engine again in May, on the way to visit my mom for Mother’s Day. My local shop did some troubleshooting and found that … I had shut down the good engine.

See, what had happened was…

The engine monitor I have in the plane has two cannon plugs on the back, one for the A/D converter for each engine. Apparently the last time the monitor was worked on, the plugs were cross-connected. So when I felt an odd vibration and saw unusual engine parameters for the left engine, it was actually showing me data for the right engine. When I shut down the left engine, it was actually the normal one. Big thanks to Andrew Yost of Revolution Flight for catching that little error. Once he got the plugs swapped into the correct positions, it got a lot easier to troubleshoot the source of the problem, a partially clogged fuel injector.

The biggest negative from a maintenance standpoint was the untimely death of my friend and mechanic, Jon Foote, in July. Jon took great care of me as a customer and of the airplanes he worked on, and I’ll miss him.

As I write this, the plane is down at Baker Aviation in New Smyrna Beach undergoing a comprehensive annual inspection, from which I hope I’ll emerge only a little poorer. Baker is a very-well-known Beechcraft speciality shop, and when I went there there were about two dozen Barons and Bonanzas either being worked on, waiting their turn, or waiting for pickup. I have a list of about a dozen squawks that I want them to address, time permitting– almost all small things like “replace the magnetic compass” or “adjust the microswitches for the landing-gear warning horn”. I think the flight controls, engines, and other major systems are all pretty solid, but I’ll know more once I get the preliminary report from them with borescope photos and so on.

They will also be sending oil samples to ALS for analysis of wear metals; by measuring the (hopefully microscopic!) amounts of various kinds of metal in the oil, it’s possible to analyze the wear trends and get early warning of some types of problems. It’s the same idea behind the regular bloodwork your doctor probably subjects you to: regular sampling builds a baseline for trend identification.

In 2025, my goals are to fly at least one Angel Flight mission per month; to go up to the FAA headquarters in Oklahoma City and do their aviation physiology training seminar; to fly myself to Oshkosh and the American Bonanza Society convention; and to get at least one additional rating or qualification. Onwards!

1 Comment

Filed under aviation

Tagged as , , , , ,