ArduSoar - 2025

ArduSoar in 2025

The purpose of this blog is to document my process to reproduce a vehicle to run ArduSoar but with a modern twist - adding a Companion Computer with ROS 2. It’s been a while since I’ve tuned a vehicle from scratch, so here goes…

Much of the hardware of this project has been sponsored by Holybro
I’d like to give a huge shout out to Holybro for sponsoring this project. I really like the form factor of the Pixhawk 6X with Mini Baseboard. They replied within a day of reaching out where I asked for a discount on a GPS and power module. They’ve agreed to ship me the rest of the peripherals I need! The ArduPilot partner’s support of the dev team is amazing.

Goals

Preliminary goals:

  • Install ArduPilot cleanly on a Parkzone Radian with a companion computer WITHOUT a ton of extra drag
  • Swappable battery
  • Demonstrate the hardware build, configuration, tuning, and improve the documentation/tools as I go
  • Request help from others as I need (I’m far from a tuning expert) so I can learn
  • Have this blog be detailed enough that anyone who’s built an ArduPlane before be able to reproduce it

Longer term goals:

  • Improve the soaring algorithms in ArduPilot (altitude limits relative to terrain, leverage thermal drift better, improve the state estimator)
  • Leverage offboard compute on the companion computer to improve soaring capabilities
  • Improve the ROS 2 interface to better support the state information and controls channels that soaring needs
  • Add better MAVProxy visualization of what the soaring controller is doing (see the thermal estimates in the UI)

Parts List (to be updated)

Note: prices in USD

3 Likes

Regarding the parts list:

  • Airframe, go as big as you can, we use Multiplex Lentus (3m wingspan) and it is about right size for experimental Ardupilot setups that you want to hang stuff of off.
  • I would recommend modern EdgeTX radio, preferably with color display. Right now, Radiomaster TX16S is the top of the line and pretty comparable in price. I would way to see what comes this Spring as H7 based EdgeTX radios are around the corner.
  • I would replace TBS Crossfire with ExpressLRS as it actually supports MAVLink and therefore can be used as telemetry link It also is noticeably cheaper. You will probably want external ELRS module for the USB port that allows for wired telemetry instead of relying on WiFi. Nomad would be a good choice as it is dual band and will support new ExpressLRS receivers.
  • ASPD-DLVR is the better sensor right now. CAN versions have auxiliary serial ports and I2C you can use for additonal sensors.
  • M10 GPS will be good choice unless you need/want sub 1m precision of RTK setup though that will significantly increase the cost. I have seen Holybro M10Micro recommended in the GPS Roundup thread.
  • Power module - avoid analog power modules combined with power supply, common power and measurement ground causes significant issues at low current draws you will get in a powered glider.
  • Rangefinder - you will need about 12-15m range for automatic landing (pretty much the only reason to have a rangefinder on a plane as it isn’t used for much else IIRC). I tested 7m range 24GHz rangefinder and it was activating slightly too late to be useful.
  • Telemetry - ExpressLRS supports mavlink telemetry. I would consider secondary telemetry link through mobile network using RPi Zero.

Hi there, all the parts above I already had on hand:) Yes, I also have a Multiplex Cularis 2.7m but have had struggles with tip stalling on the Cularis at high wing loading. Longer term, I’m looking at either a Gracia 2.7m or Fascination 3.6 as both have been used in FPV soaring.

MAVLink telemetry over the radio would be great, and Crossfire is very bandwidth limited. I have a feeling ELRS is in my future to replace all of my old 433 Rangelink hardware, as well as 4G LTE for farther flights.

On the TBD parts, Holybro has agreed to sponsor the project and provide the remaining parts

  • Micro M9N GPS without case
  • PM02D power monitor (digital)
  • SIK Telemetry v3 43MHZ 100mW
  • MS4225DO airspeed sensor

I’d love some recommendations on rangefinders for landing from the other devs.

Next up is some flight reports and logs!

1 Like

Hardware Setup

The initial hardware setup is focused on getting flying with parts I have on hand. The local makerspace is still closed, but when they open back up, I plan to do some 3D printing and laser cutting.

Autopilot and Raspberry Pi

Here’s what ArduSoar used:

Looks like acrylic with 4 bolts. There was no raspberry pi because all processing was onboard the Pixhawk.

I had some 3/16" aircraft plywood available for a mount, and need to install a Pi Zero 2W too, so here’s what I did.

This is my “scroll saw” jig, which I learned from a jeweler.

You can cut out rough shapes

5 minutes later, we have a plate that can sit on the fuse.

On the underside, I marked out a position for the ZeroW, I drilled 3mm holes (the Pi is 2.5mm but I don’t have any 2.5mm bolts on hand). The bolts are ~8mm with flathead. With a bit of dremel work, the flatheads sit flush in the plywood, and I can VHB tape the autopilot on the other side.

I found that covering the plywood in packing tape provides a more sticky surface for the VHB tape.

To attach the plywood to the fuse, because I don’t yet have bolt hardpoints in the radian fuse, I used more tape. I’m working on modeling up the hard points for 3d printing with blind nuts that I will glue into the fuse.

Here’s what it looks like all wired up.

The pi is not yet wired, but that will connect via an open TELEM port and powered directly off the autopilot. It’s super low draw. The Pixhawk 6X mini baseboard has this servo breakout board that is relatively bulky, but I found a nice gap for it next to the ESC later to get it flush.

The power module (CubePilot Power Brick Mini) has Xt60’s soldered on directly which make it hard to pack in, and only provides power. It’s an analog sensor and the 6X needs I2C, so I don’t yet have voltage/current measurement. Once the Holybro PM02D arrives, it will be more compact and supply voltage/current readings to the autopilot.

As it stands now, things are nice and flush, but the 6x is just a few mm too big to put on the cover.

Switching to 1.5mm plywood would allow me to use the stock radian cover, however that feels too flimsy for vibration, so I plan to design a new mount that loweres the autopilot into the fuse a bit. For now, I’ll fly without the stock fuse cover.

Until I get hardpoints put in, every time I disconnect the battery, I have to add new tape on the autopilot. Good enough for a maiden to assess CG, trim, and initial tune.

Here’s what the servo adapter looks like next to the ESC. There’s a nice slot for it in the foam.

With everything fit, it was extremely noseheavy, so I found some “ballast” - a runcam 2!

The crossfire RX fits nicely near the servos, and the antennas will have largely unobstructed signal here.

Ideally, the servo breakout would live in this bay, but I don’t want to splice the many-pin JST-GH until I get a crimper. So instead, I made servo extensions, and used the handy clips to keep them connected. That will be a later project one my JST-GH crimper arrives.

With the lid closed, and a zip tie added to secure the crossfire, I’m ready for a maiden flight in DCM (no GPS, no airspeed sensor). I want to check trim, check the power setup runs on on 4s without overheating (it’s specced for 3s or 4s and I live at ~6000 feet elevation) and check FBWA can level the plane.

2 Likes

Configuration in mission planner

The radian does not have ailerons. Hmm, luckily I found RUDDER_ONLY.

I followed those instructions. Here’s the mixes on my transmitter running OpenTX


Elevator INPUT is reversed per usual, but on the MIXER tab, I have moved the rudder input to be combined on channel 4. THis means that my roll and yaw sticks do the same thing. I can arm with either, and I can control the roll/yaw with either.

Because I don’t have a GPS or airspeed sensor, EKF3 is unhappy (pre-arm failures).
I disabled GPS arming check. I set AIRSPEED_USE to 0.
In hindsight, I should change GPS_TYPE from 1 to 0.

Next, because EKF3 wasn’t going to work, I forced the plane in DCM.
AHRS_EKF_TYPE is now 0.

And, the final param file:
mav.parm (21.7 KB)

At the field, I turned on SERVO_AUTO_TRIM at the recommendation of Henry.

2025-01-03 - Flights 1, 2, 3

All prepped and charged up!

I’m planning to use stick arming, but have concerns that it might disarm in flight. The plane has no idea it’s flying because it has no ability to measure speed.

I took off in MANUAL mode without a hitch - very out of trim, but typical for this cheap foamie.

Here’s the logs and flight report. I’ll be uploading them all here as I go. Here’s a picture of a flyby (I flew one-handed for this, hope you like it).

Key notes from the first flight:

  • I can’t turn sharp in FBWA at all, I thought the default was 45 degrees roll?
  • The plane is stable in FBWA, but has heavy oscillations in roll/yaw. The yaw servo wags full deflection if I do anything but glide at low speed resulting in instability. Overall, I’m quite bummed the default parameters for ArduPilot fly this poorly and need to work with the dev team. I would expect a reasonably stable tune, especially given the massive dihedral on the radian.
  • The minimum pitch angle (descent) seems good, the max pitch angle (ascent) is much too shallow - this can climb almost vertical.
  • Full throttle is totally overkill for autonomous flight, I should find a way to limit this during navigation to something like 50-75%
  • Auto trim didn’t seem to work well, it still was pitching up to near stall in MANUAL mode.
  • I couldn’t disarm until I connected USB and clicked the ARM/DISARM buttun in mission planner. What a safety hazard. I’m going to switch to switch arming.

When I landed, I went back home and checked the logs. Here’s what I was seeing.

In FBWA, you can see the rudder (servo 4) outputs oscillating terribly. That was log 1 12-31-1979 5-00-00 PM.bin.

Upon inspection of the code, I realize that:

  1. SERVO_AUTO_TRIM likely won’t work because the AHRS has no idea how fast the vehicle is moving, and requires 8m/s groundspeed and estimated airspeed, so I manually add some pitch down and roll right trim in the trim tab
  2. I can’t tell why my roll angle seemed shallow in FBWA, but don’t bother checking further.

For the roll/yaw oscillations, my first guess was that the value of YAW2SRV_DAMP was too high, so I cut it in half per the recommendation on RUDDER_ONLY.

Second flight has the same exact behavior of rudder servo oscillations. I quickly land, and cut YAW2SRV_DAMP all the way to zero. No effect. Sigh… At least the trim is decent now through a manual trim in mission planner.

Third flight, I fly circles in FBWA, trying to see why it doesn’t seem to roll at 45 degrees. Here’s the plots for that circle that I thought were useful- I knew I commanded max roll input in FBWA, and here’s the target and achieved roll angle.

25 degrees. Huh… I know there’s some stall prevention code in ArduPilot. A quick search on the wiki - ah yea, 25 degrees is the limit. This must be it! Reading further down, I see stall prevention is active at low speeds. Again, the AHRS doesn’t know the speed of the vehicle without GPS or airspeed, so that’s another thing. So, now, I have disabled STALL_PREVENTION.

So, the obvious problems are fixed, but I still have this terrible oscillation. I did try adjusting the roll P gain after the 3rd flight in Mission Planner, but regardless of what I typed or clicked in the tuning page, the value did not change, even after a reboot of the vehicle and mission planner.
Best to look at the logs and find root cause or run auto tune rather than fight this.

Overall, it’s great to get this bird in the air, despite all the workarounds. We have nasty weather coming soon, and I wanted to some log data to review for the poor weather. The vehicle flies great with the current CG, battery, and wing loading in MANUAL. Much easier to launch than my fully loaded Cularis, so I have a feeling I’ll be doing a lot of the development on the radian.

That happens because you don’t have any airspeed source (pitot probe or GPS based estimate). I observed the same behaviour in SITL with a fully equipped plane.

It may be due to lack of airspeed sensor.

Stick disarming is disabled by default for planes and IIRC locked out if you don’t have an airspeed sensor as in flight disarm is quite problematic.

1 Like

Seems risky - what if the airspeed and GPS fail in flight? Now, the plane can’t fly straight and level. I’d be interested to try to tune it so it won’t crash in FBWA.

I’ve confirmed auto trim and autotune rely on GPS/airspeed in the source code. I don’t understand why it’s treated as mandatory. Seems like a good use for an option bit.

For now, I put a PR up to the wiki clarify how to set up a plane without GPS or airspeed.

I also created this wiki on how to set up a 3-channel (rudder only plane):

Hardware Changes

I’ve installed an old Ublox M8N GPS, and re-enabled all the GPS parameters.

Autotune Results

Now that I have a GPS, I can run autotune! Sadly, results were not satisfactory.

  1. After re-running mag cal, and re-enabling all the arm checks, I couldn’t arm because the AHRS wasn’t using the configured EKF type, so I decided to keep flying in DCM
  2. I also observed the magnetic field warnings, so I had to also disable the mag pre-arm check.
  3. Autotune results were not any better than my manual tune. Autotune with GPS has roll oscillations while gliding, while DCM no-GPS had oscillations while gliding at high speeds. For normal flight speeds, my manual tune had better gains.

I plan to work with some of the other devs and users who have experience tuning PID’s on rudder only planes and gliders to chase down why autotune is not giving good results.

What about soaring

I spent time in SITL trying to understand how to use the THERMAL mode with soaring enabled, but have yet to get SITL to execute stage 2 - the power on climb. If the vehicle is between SOAR_ALT_CUTOFF and SOAR_ALT_MIN, it turns the throttle off. Once the vehicle hits SOAR_ALT_MIN, it exits LOITER and never turns the motor on.

What’s interesting is that the soaring wiki never says to use THERMAL mode, instead it says you should use LOITER mode. Why is that?

Steps to reproduce (on master).

./Tools/autotest/sim_vehicle.py -v Plane -w --map --console
param set SOAR_ENABLE 1
reboot
param ftp
# You can check SOAR_ALT_MIN=50, SOAR_ALT_MAX=50, SOAR_ALT_CUTOFF=250
mode takeoff
arm throttle
# Wait some time
mode CIRCLE
changealt 200
# Now we are at the height for stage 1. Let's watch the throttle
graph SERVO_OUTPUT_RAW.servo3_raw
# Now, engage THERMAL! 
mode THERMAL

The vehicle cuts power, glides down to SOAR_ALT_MIN, then goes back into circle mode, decided to raise altitude again, but never climbs to SOAR_ALT_CUTOFF.

I also tried AUTO mode with this mission, no luck either - that just flies at the mission altitude without any gliding.
infinite_box.txt (488 Bytes)

Oh, and SOAR_ENABLE_CH doesn’t exist anymore. I issued a PR to fix that.

I would recommend fixing AHRS and magnetometer issues first.

2 Likes

I haven’t been keeping up on the blog, but still flying! The big update is all the remaining Holybro hardware arrived today. I’ve been having issues with EKF not initializing- hopefully the new GPS/compass fixes it!

The new telem radio will help me complete autotune correctly start to finish, and the battery monitor will let me fly longer.

2025-01-17 - Flight 11

With the new hardware (GPS, voltage/current telem), I tested it out today. Overall, success! EKF3 initialized, the voltage/current work, however the SIK radio didn’t work out of the box. Later testing showed I need to manually set the baud to 57k.

Flight conditions were windy as a polar vortex arrived today. The models had some wild horizontal shear predicted across town, so I was excited to see how the models lined up with reality. Here’s a screenshot from my forecasting tool, xcskies.

From the area forecast discussion:

Flash freeze potential and threat of icy/hazardous travel conditions is increasing for the pm commute. Snow will arrive for most of the I-25 Corridor between 4 and 6pm, and then continue into Saturday morning."

The front caused some really awesome cloud formations, and there was a ton of energy in the air causing all sorts of turbulence.

Autotune worked well - without the airspeed sensor, and stall prevention turned off, I focused on keeping the plane tuning while going crosswind. Luckily, the autotune completed according to the logs, and it seems to be flying well now. Flying low in the rotor of the little sledding hill in the park with both manual and FBWA show similar visual behavior with response to turbulence. I can’t fly the vehicle better than the inner control loops anymore.

Next up, I’ll be flying in AUTO to start tuning NAVL1_PERIOD, and wire up the airspeed sensor if I have time.

3 Likes