The best approach would be to use VSCode dev environement (that is docker) but the process is really transparent
For WSL, we should rewrite it once again as the installation is quite confusing specially with WSL installation … that a recurrent issue that the tools we are supporting got they own installation change …
@geofrancis yes ArduPilot is getting more complex, that is the price to have a more reliable autopilot unfortunately
Devil’s advocate - I’ve set up the build environment on two computers running different versions of Windows and, at one point, even different versions of WSL, and I had no trouble at all. As long as you follow the docs carefully, it isn’t hard.
It’s somewhat defensible that if one doesn’t have at least a modicum of comfort on the Linux command line, one probably shouldn’t be altering the firmware.
I haven’t used the VS Code + docker environment, but that does sound like good practice.
Unfortunately, that isn’t that simple. For example, we got case of people having upgrade the WSL from 18.04 to 20.04 so they are still on Python2 when our install script expect Python3.
With windows11 our docs about xserver on WSL is wrong and doesn’t work.
But that get us back on one of the point I mention earlier : make the install script failure more appealing will help people to understand what failed and find an easy solution. In most case, the error is writen on the screen and just need a googling, but most don’t even see it …
My point is to try and bring it back down to a level where its not limited to professional software developers, I’m more than familiar with command line, but thats all on servers and routers using commercial software I have never had to compile anything.
@khancyr my point is it doesn’t have to be. Starting from a known working that works is much better than having to figure it out before you can start. there is no reason the environment cant be premade in some way that its ready to go out the box.
for example, to get the SR04 sonar working under water, I could have tested it by just editing one number in the sr04 driver, but instead it took 4 months and lots of asking around for someone to look at it.
that is what is wrong … our dependencies changed from time to time and as I said setting up a VM environment isn’t simple either
Regarding the ease (or difficulty) of getting into the ardupilot code to modify it I can comment on it as I just went through the process in last few days.
The code (that I was interested in) was very understandable and fairly easy to navigate once the structure of the project was understood. I can’t complain about it.
Then there is the build system… It runs great. It works, but after few days of looking I think that’s where some barrier to entry is. Perhaps it is necessary considering the number and diversity of build targets, but as someone who wrote lots of python code in the past (mostly deployment rather than build though) I was expecting to pick it up much more quickly. Maybe I just need to read some waf/wscript material first.
Yeah… waf is interesting it is sort of a black box at times… But really there are generally just a few points in it people need to edit to add a library to the compilation. Everything else rarely gets changed.
However, if you mean using the ./waf BLAH commands are difficult that would be good to know?
Regarding waf, no, “waf build” commands etc are straight forward and IMO easy to use.
Adding a library that gets rebuilt with ardupilot (in the libraries folder) is pretty simple and described well elsewhere on this forum.
However, what I found more difficult is adding an externally compiled shared library.
My external library lives in the modules folder. It doesn’t get rebuilt with ardupilot. While the build is going on I need waf to pass - I with my include path during compiling, - Lpath and - lgpio to the linker with it being important that - lgpio is at the very end of the command line.
I found a way to do it by tweaking some internal variables in the python code. Anyone interested how I did it can see it here changes to add pigpio library · lukolszewski/ardupilot@d59b10c · GitHub
It works, but I believe there probably is a more elegant way to accomplish the same. However, that more elegant solution is not obvious to me now (I’ll probably see it when I spend time on waf/w script docs).
As a side note, why in the world did the creators of waf/wscript chose those names? Everyone knows “waf” is a “Web application firewall” and wscript is a Windows scripting language… 
I found this when I was getting my hoverboards working with ardupilot, it lets you edit and compile hoverboard controller binaries from source without any installation, this would be amazing for arudupilot making code changes and testing far more accessible. we already have the custom firmware builder why not let users edit the code directly?
https://pionierland.de/hoverhack/
Any updates to @geofrancis idea to build a virtual box container with a preinstalled ardupilot? I feel like it would help out newbies like me get started and cut down on number of questions or issues about running Ardupilot.
For example, I reinstalled Ardupilot multiple times, tried it on WSL2, WS1, and carefully followed the instructions. And I have Windows 11, which should be easier to setup. However, I am having multiple issues in SITL like Copter falling from the sky in Circle mode. Documented in Various Issues with my SITL · Issue #25895 · ArduPilot/ardupilot · GitHub and earlier in Copter in SITL is spinning (yawing) after takeoff - #2 by P_L100
I wander if the instructions on Ardupilot’s website are up-to-date. For example, command “git checkout Copter-…” which @amilcarlucas told me to use is not found in the official instructions. The git commands listed there gets you the dev build.
I have struggled to even get a working SITL. My point is having a pre-built VirtualBox would help people like me, and I feel it will cut down on questions in the forum from people who are having similar issues. Anyone has a pre-build VirtualBox with a working SITL?
I don’t mean to sound too harsh, but if you’re having struggles as fundamental as those, one has to wonder what you hope to gain by having a development environment set up in the first place.
The provided instructions and scripts are pretty robust and should result in a clean environment on any reasonably configured Linux system, virtual machine, or container. However, a complete novice to Linux, git, and/or software development at large may well struggle, since there needs to be some fundamental understanding of what’s happening in the first place…
What is it that you need from a dev environment that Mission Planner’s SITL cannot do?
EDIT:
I just spun up a brand new Ubuntu 22.04 LTS container (which is what you’d get under WSL2) and followed the wiki instructions verbatim. In 5 minutes, I was connected to a SITL instance. Here’s a consolidated list of commands, only the last of which contains a flag that isn’t explicitly listed in the documentation (but can be found by listing flags, per the documentation with the -h switch). I used --no-mavproxy because I was running this development environment on a networked server without its own display.
sudo apt update
sudo apt upgrade -y
sudo apt install git
git clone --recurse-submodules https://github.com/ArduPilot/ardupilot.git
cd ardupilot
Tools/environment_install/install-prereqs-ubuntu.sh -y
(logout, login)
cd ardupilot/ArduCopter/
sim_vehicle.py -w
(Ctrl-C to kill default instance)
sim_vehicle.py --no-mavproxy
The wiki doesn’t go down the rabbit hole of teaching you how to use git because (in part) it’s very reasonable to assume that if you want to use a development environment, you’re already familiar enough to, for example, check out a branch.
I’m not sure what would be gained by forcing a developer to maintain a ready-made image when the prereqs script creates this environment in a matter of minutes. Anyone who struggles to follow these instructions would likely struggle equally to use/install a disk image.
Thank you for the response. To clarify, I was not seeking to make a dev environment. I use the same git clone command and link that you used. I don’t know why I got a dev environment. In the post I mentioned, @amilcarlucas told me how to switch to the stable version and the issues I mentioned still persisted. Anyways, that was in a prior build. Since then, I tried a build on VirtualBox. Also, to clarify, in both cases my SITL is not having issues starting or arming or taking off. One issue I have had was after I typed these commands and then switched to Circle Mode:
mode GUIDED (accepted)
arm throttle (accepted)
takeoff 10 (accepted)
…waited until reaches the height and wait little longer
mode CIRCLE (accepted)
…drone rapidly decreases altitude and “hits the ground…”
I have an open ticket about this and provided an update that I found a workaround - see update #4 in (Various Issues with my SITL · Issue #25895 · ArduPilot/ardupilot · GitHub). There I posted a link to a forum where another person had this issue and was advised to use “rc 3 1500” before Circle Mode. Could you please run the aforementioned commands and tell me if the copter crashes? Do you have to use “rc 3 1500” to have it work fine?
Also, could you please let me know what happens to the copter after you run “attitude 0.9961947 0.0871557 0 0 0.5” on your recent build. The issue I have had was that the copter does not stop after the roll. It keeps on drifting, sometimes making a “U” or half “U” shape and keeps on going, albeit at a very slow speed, but nevertheless. I think the expected behavior is a drift of 5 seconds only (per SITL_DRIFT parameter and related timer), but mine keeps going. It bothers me because I want to start using more commands, learning to use pymavlink and I don’t want the various issues to compound into a behavior that would be totally off from the expected behavior of an Ardupilot copter. Please let me know what you get when you repeat my steps and what else can you advise? Thanks.
Again, lots of fundamental misunderstanding.
You get a development environment the moment you clone the repository with git and run the install script. “Development environment” means that you have installed all of the files and tools that it takes to build ArduPilot from source code. It has nothing to do with the version that is checked out.
When you first ran the SITL script, you had the master branch checked out (which is the default behavior). So, you got a 4.5-dev version. The git checkout command that Amilcar showed you is a means of version control WITHIN the development environment.
Circle mode is descending into the ground because you have no throttle input. It’s neither bug nor issue. You need to attach a joystick or use an RC override command to set the throttle to neutral (hover), or the Copter will descend, exactly as intended by the firmware.
The guided mode attitude command example works just fine on a brand new SITL instance in both Copter 4.5-dev and 4.4.4.
There is no SITL_DRIFT parameter, and the only one similar controls an induced GPS error in the simulation, which, if you messed with it, might explain weird behavior.
Again, I pose the question to you - what is it that running a development environment (ArduPilot from the command line on a virtual machine or container) is buying you that Mission Planner’s SITL cannot do?
All you have to do to use Mission Planner’s SITL is go to the SIMULATION tab and click the button that looks like a quadcopter. Choose “stable” at the dialog prompt since you want 4.4.4.
If you want to use MavProxy to interact with that instance, open it and type:
link add tcp:localhost:5762
I took screenshots from Ardupilot page on simulation. Please see what it says
Also, the first google results to e.g. “ardupulot simulation” or “ardupilot sitl” point to dev page. Also, when read about airsim or webots on ardupilot website, it points you to dev installation as one of the steps.
I later became aware of Mission Planner’s simulation tab and I used it, but you can see how multiple sources are first pointing a user to a dev installation.
Also, regarding documentation, please see the Ardupilot’s page on circle mode - it does not mention “rc 3 1500” - Circle Mode — Copter documentation.
How can a new user be expected to know that? Without explicit instruction mentioning that, it s not intuitive to know that to switch to circle mode I need to enter rc command, as for example to land, I just type mode land, I do not need to add rc command.
Also, regarding the attitude command that produced continuing drift and not in the constant direction of a roll, you are saying this is a normal behavior in a windless environment? Again, not intuitive and that’s why I brought it up.
I feel like the contributors think the people posting what seem to them as basic questions assume that they have not read documentation. But have not realize how the current instructions are setup. And e.g. in dev build, one page says not to do waf clean and another says to do it. And in the example of circle mode, some things are not mentioned.
I will concede that your Google searches likely led you to the Developer page instead of Mission Planner’s SITL page, fair enough.
Now that you’re aware of it, frankly, you’re probably wasting both of our time continuing to use the command line.
As for the remainder of your frustrations:
See the note at the bottom of the linked page regarding circle mode and altitude control being similar to loiter and altitude hold modes. There is no need to specifically call out an RC override command for SITL because the mode isn’t designed for use in simulation. So, the note describes how to control it on an actual vehicle. If you want to replicate manual control in a simulator, you connect a joystick, just like any other simulator…
The attitude command behavior that you describe is not reproducible here. I agree that it’s not expected behavior, but you mentioned parameters that don’t exist, so I don’t know how to attempt to reproduce it.
I just ran Mission Planner’s Simulation. Again, when I reached an altitude of 10, I switched to circle mode and the copter fell. I also tried it after I ran “Fly to Here”. Once it reached that point, I switched to Circle mode and it fell.
I have another computer. I installed Mission Planner there. Followed the same steps and I got the same result. I recorded my steps in a short video. I also uploaded the bin file. I uploaded both files and they can be found here: Ardu Issue 01.06.2024 - Google Drive
Let me know if you are having the same issue after following my steps.
Again, that’s because the throttle is uncommanded. It’s NOT a bug. You NEED the RC override (as you’ve already discovered!) or a joystick to use circle mode.
Modes like loiter, altitude hold, and circle rely upon active pilot RC input for altitude control. What you discovered in rc 3 1500 is a way to “fake” a neutral throttle input in SITL.
You’re beating your skull against the wall proving expected behavior here.
I did not forget about the rc command. I thought that it is was only required as a command line when using dev version/command line. Wrong assumption I see. That is good to know.
How do I perform this override in Mission Planner? The docs only have 1 line mentioning “override” and it says that servo tab contains channel 5-14 and allows overrides, but did not see anything about channel 3 overrides. So how is it done in Mission Planner?
And what are the steps in Mission Planner to perform an attitude command, e.g. roll 10 deg? And what behavior is expected after rinning that command. Thanks.
Use MavProxy as I described above to issue the commands.
Mission Planner is abstracting away all of the git clone/checkout/scripting madness, but it doesn’t directly provide the low level access you seem to desire to learn these commands.
Another option is to connect a joystick or gamepad, as I’ve been saying. That will give you a mock RC interface to use in the semi-autonomous modes that are frustrating you.
Thanks. I tried to connect my joystick to SITL. But it is not recognizing it. I have RadioMaster Zorro. And actually I set it up on my actual flight controller and in fact flew a drone running ardupilot outdoors, and ALT mode, Pos Hold, and RTL mode with success. But when using MP’s simulation, radio calibration inputs do not respond to my joystick movements or switches and same result when I try to calibrate it in MP. Maybe it’s been a while and I forgot some step in getting my joystick working on ardupilot. I think having the joystick linked would perhaps produce SITL’s drone behavior that I would expect.
