SITL - battery now reports good, heading wrong in RTL

Today I moved a new (faster) computer into my workshop. Spend the day migrating files, etc.

I did clean installs of all our favorites applications - including Mission Planner. (and the beta updates)

Now that I figured out my stupid mistake for running SITL, I thought I’d try the new computer on a SITL of my little test mission using spline and loiter waypoints.

TIP: On a clean Mission Planner install, don’t forget to “Set Home Here” or you’ll find yourself trapped in Australia…

For no possible reason I can imagine - this install on a new PC corrects the problem where the battery voltage showed in red.

On my old PC, a un-install and re-install of Mission Planner did not clear this problem. But come to think of it - my “Set Home Here” didn’t revert to Australia either.

Are there persistent files that aren’t removed in an uninstall?

Lastly - a small issue to report. On all my flights at this park, I launch the copter facing south. Before descending on RTL, the copter always yaws to this same heading.

On the SITL, I couldn’t find a way to set the orientation of the copter before takeoff - it’s facing close to North. On the RTL, I sort of expected the copter to return to this heading before descending on RTL, but it didn’t - it simply kept the same heading it took on route from the previous waypoint.

As you can see on this screenshot - the copter landed with a heading West.

On my copter I set WP_YAW_BEHAVIOR to “3” to cause the copter to yaw to face the GPS course. I could not find this among the SIM_xxxx parameters in Mission Planner’s (Simulation) Config Full Parameter Tree. Probably not a high priority.

I hope this is helpful information. Thank You!

You’ve overcomplicated things a bit much. Per the SITL documentation, enter the following into the “Extra command line” text area to start your SITL vehicle stuck in Detroit on a heading of 120°:


1 Like

Yuri -

Much of the SITL documentation revolves around using MavProxy - which I haven’t yet dug into.

I’d appreciate a link to the documentation you refer to if it pertains to Mission Planner.


Yep - it’s right there as a tip.

But in my opinion - it’s way easier to simply right-click and select “Set Home Here” - so there’s no need to look up the Lat/Long of my local park.

Maybe someone can add that as a second tip.

You wanted a way to set the heading. That’s how. A one-time lookup of the coordinates would provide you a copy/paste solution that’s just as easy as and more flexible than the right click workaround.

Yuri - I can’t tell you how much I appreciate the efforts you go to to help me and other rookies get a leg up on using these wonderful tools. Thank you!

Unfortunately, the link you offered regarding the tip on setting location isn’g shedding any light on setting the copter’s initial heading. But it’s late here - maybe I’ll spot it in the morning.

The DEV documentation on SITL using MavProxy is considerably more extensive. But not helpful for my immediate needs.

I apologize if my questions sometimes come across more as complaints. I’ve been working full time for over four months learning the basics of autonomous aircraft and flight. ArduPilot is at the center of those efforts - and frankly, it’s exhausting sometimes.

For every set of questions I ask, there are always some elements that remain unanswered. I’m constantly having to decide the merits of digging in and trying to get those questions answered, or moving on and spending time on other aspects.

For example - why did SITL on my previous computer show the voltage in error in the HUD - even after a reinstallation of Mission Planner - and why did the reinstallation of Mission Planner not reset the home location to Australia? On my new computer with a fresh Mission Planner installation - the voltage error in the HUD is gone - and the initial home location is on the other side of the world. It perhaps doesn’t really matter - except if there is something like a persistent data file across reinstallation, I have to wonder if that’s something that could be a factor in the future.

I’m starting to get a feel for why things are the way they are in this world. My goal is to be among those who make it better - especially for those who are new to the field and these products.

Once again - many thanks for your efforts - above and beyond the call of duty - Thank You!

I do enjoy learning myself, and it sometimes helps me
to find the answers as much as it helps others. I’ve been frustrated a little by a lack of response here at times, so I try to pay it forward a bit when I can.

The comma separated values after home= are, in order, latitude, longitude, elevation (meters), and initial heading.

I do not know if it’s possible to dictate the final RTL heading. It’s a position target, but I’m not certain that you can dictate an exact heading at touchdown (without manually yawing to that heading).

1 Like

I’m glad we’re on the same team.

As info to any others reading this thread. The SITL command line works for setting initial heading - but all the other 3 parameters are required too - null values don’t seem to be accepted. (at least not with spaces between commas, or no spaces between commas)

Google maps presents a Lat/Lon on their maps by right-clicking any point on the map. So that’s easy to find.

The only reference I found to the SITL command line syntax for operands is the first line of this file:

I couldn’t find a SIM parameter for WP_YAW_BEHAVIOR. So its unclear to me what’s controlling the copter’s heading throughout the flight. It appears to face the GPS course the entire mission - except for the final leg from the last WP to the RTL home. On this leg, the heading remains unchanged from that at the next to last WP. (the WP before the RTL home)

And as I mentioned earlier - in my field tests, RTL always results in the copter yawing to it’s launch heading before final RTL descent. This is not observed in SITL.

If you know if the SITL DEV team may find this useful info - would you help me learn how to submit it to them?

Many Thanks!

1 Like

You can find lat/lon/ele in Mission Planner on the “Plan” screen (or simply make a waypoint and copy the values).

If you really deep dive into SITL and begin building your own simulations from the build environment, you can use the file that you referenced as a shortcut to set a custom home location.

WP_YAW_BEHAVIOR is available in Copter 4.1.1 and 4.2-dev in SITL. Looks like it defaults to “Face next waypoint except RTL.”


If you’re interested in filling documentation gaps, here’s the guide on making Wiki edits.

I use “WP_YAW_BEHAVIOR,3” on my copter for most missions.

I need direction on how to set this for SITL. I thought all the parameters used by SITL were the SIM_xxxx parameters - and there isn’t one for wp_yaw_behavior. Even when selecting the DEV firmware.

I’ll check out the guide to making Wiki edits - Thanks!

The SIM parameters control simulation-only values that are otherwise unavailable (and meaningless) outside SITL. In other words, they are there to control the simulation environment, not necessarily to control vehicle behavior.

The rest of the parameter list is still valid and can be used to command behavior changes exactly like they do on a real vehicle. Changes to SITL parameters are persistent across Mission Planner sessions unless you choose the “Wipe” option before starting the simulation.

1 Like

Ah - the puzzle pieces are coming together…

I had wondered about using my copter’s parameters - but found no way to connect the copter to SITL. Then it dawned on me that I could simply use the save-to-text and load-from-text file option in Config to write the current parameters off the copter onto my PC (which I do regularly for my records anyway) but then read that file back on the Config screen once SITL is running.

It worked - sort of. A couple dozen parameters were either marked as unchangeable, or noted out of range. And about 80 parameters were reported missing from file. I ran SITL using the latest stable version and my copter is using 4.1.1.

Running the SITL mission again - much to my surprise there was no change in heading/Yaw now the the WP_YAW_BEHAVIOR was changed from “2” to “3”.

And the last leg still left the copter at it’s last heading - though descent to landing. This is definitely not proper simulation of the copter’s actual behavior.

But thanks to you Yuri - I’m starting to feel like I have a handle on this. Thank you!

I presume you are using SITL through Mission Planner’s Simulation Tab?

Once you get into things a little deeper you will find that some of your questions get answered in the more advanced tools help section. For example if you directly run SITL via command line ./build/sitl/bin/arducopter --help All of the options for the sitl binary get listed.I;m not sure if those options are listed on the Wiki in the right spots?

My preferred way to start sitl is using in WSL2.

PRs are always welcome for code or documentation! What is hard for a new user is so different than what is hard for developers. If there are things you think should be documented better you can fill out an issue to the wiki too. :slight_smile: We always need better docs!

Some parameters may require a restart after the enable or type of the parameter tree is changed to open up the rest of the parameters in that tree.

Josh - Thank you for jumping in and helping me. You bring up a good point regarding some parameters requiring a reboot to become visible because they require some something to be set to “enable” first. I was curious about how to do a reboot under SITL. I did the CNTL-F option to bring up the “temp screen” and then selected “reboot pixhawk.” That seems to have worked. It disconnected - but allowed me to reconnect. Not super elegant - but effective.

Regarding command line capabilities - or running Mission Planner under WSL2 (Windows Subsystem for Linux, I presume) - probably not too helpful for we users who are just trying to use these tools - not write code for them.

I think the whole issue of documentation and support fall back to: What’s the mission of ArduPilot?

Back when it was the software that enabled 3DR to sell drones, it was perhaps more clear - the mission was to sell 3DR products.

Today, as open source software, without anyone selling it as a distribution, its not clear to me what the mission behind ArduPilot might be. The only clear financial stakeholder is CubePilot, who’s flight controllers rely on it.

If it remains the domain of students, engineers and hobbyists, it’s future relies on new adopters - like me. And if it’s a challenge for people like me with deep technical and I.T. backgrounds - I can only imagine what it’s like for average person who just wants to operate a better drone.

Without the ability to attract and retain new users, the platform will eventually collapse under it’s own weight of complexity and obscurity. That seems like such a sad possibility.

Who knows - maybe someday there’ll be a REDHAT or DEBIAN ArduPilot distribution - complete with helpful books published by O’Reilley.

I’d be really interested in the perspectives of others on this - to help me figure out how ArduPilot fits in to my own personal mission of taking up UAS as my third career.

The main issue is what documentation do you think we need? What is missing from your perspective? Please create an issue on the wiki here. We can always have better documentation, but must know specifics of the difficulty.

I’m guessing your thought is that we need to add more to the page on the MissionPlanner wiki (here)

I also want to point you towards some YouTube channels that helped me get started less than a year ago with ArduPilot.

BTW here is Copter’s Simulation page here

A lot of great discussion there regarding the purpose and value of ArduPilot. ArduPilot is used by far more than hobbyists and students.

Checkout the Partner page here to see the wide and varied use of ArduPilot in the real world. There are far far more companies using ArduPilot who do not acknowledge it or haven’t yet joined as partners. There are drone light show companies with 100s of drones, massive defense companies, and of course in the end hobbyists too! ArduPilot is for everyone!


The last thing I want to do is be critical of ArduPilot - it’s an amazing suite of software. The developers and contributors are some of the most dedicated and talented people I’ve experienced.

In many ways, ArduPilot is like the Apache web server software in the early 90’s before the developers got organized.

If you go to Amazon and search for “ardupilot” under books, there is only one book that comes up with the word “ardupilot” in the title:

Designing Purpose-Built Drones for Ardupilot Pixhawk 2.1: Build drones with Ardupilot

And that book was published in 2017 - it’s a half decade old.

If you look at the link about SITL you offered, you’ll find it leads you to a DEV section where SITL is discussed using MavProxy. How is that helpful to someone trying to use Mission Planner?

If you work through the sections on implementing FFT for dynamic filters, you’ll find it depicts charts that are not available anywhere in Mission Planner. Indeed, to get the charts needed to implement FFT one has to load the Mission Planner beta updates - and have some helpful guidance of a dedicated fellow user. It’s not in the docs.

The syntax of the command line option of SITL isn’t documented anywhere. To learn that lat, long, elevation and heading can be set requires anyone to ask for help here - and the good fortune of a helpful response.

ArduPilot is amazing software. And at the moment, I’ve hung my professional aspirations on using it. But no one in this community boasts of it’s ease to install and configure. I too built and flew my first ArduPilot vehicle by following YouTube videos. The fact that the copter flew is a testament to the sophistication of ArduPilot’s abilities - not mine.

I home to see ArduPilot succeed - and expand it’s acceptance into the UAS world beyond it’s niche uses. I have a daughter who’s an engineer at Zipline. I have to work hard to convince her that ArduPilot is serious and capable software. While some UAS operators of that scale may have forked ArduPilot and made it their own though the efforts of their own software engineer staff - it’s no where near what someone can do by loading Apache onto a LAMP stack.

As I see things today - there are two key stakeholders for ArduPilot. The hardware manufacturers such as CubePilot that rely on the existence of flight control software. No one I know of runs iNav or BetaFlight on an Orange Cube.

The other key stakeholder are the developers themselves. Unless they get a consulting gig with an organization trying to use ArduPilot in a commercial or industrial setting - there is little opportunity to be paid for their efforts. I expect many developers have incorporated their efforts with ArduPilot with their engineering academic pursuits.

My understanding that funding for documentation stopped back when 3DR went out of business. I’ve proposed to the ArduPilot Initiative that they spearhead an effort to rekindle a documentation effort. If they do - I hope they put me to work on the project.

As the scale and complexity of ArduPilot increases it will eventually collapse under it’s own weight if the level of documentation and support does not keep pace. Many of us with much invested in ArduPilot will suffer the same as experienced NetScape engineers.