SITL Build on Windows 10 BASH Missing build_posix_sitl_default directory

[NoelStephens]

Per the following instructions:

One must install BASH on a Windows 10 system and run the following commands:

=====================================

git clone https://github.com/PX4/Firmware.git

cd Firmware

git submodule update --init --recursive

make posix_sitl_default

=====================================

And the error being encountered is:

=====================================

-- Configuring incomplete, errors occurred!

/bin/sh: 1: cd: can't cd to /mnt/c/Dev/Firmware/build_posix_sitl_default

make: *** [posix_sitl_default] Error 2

=====================================

The directory build_posix_sitl_default does not exist within the mast PX4 tree.

What I have done:

Installed and verified BASH shell is working.

Installed and verified make command is working.

Installed and verified cmake command is working.

Is there additional files I must obtain to get the build_posix_sitl_default directory or is there something else wrong?

[DanWilson00]

Windows 10 Anniversary Update installs Ubuntu 14.04 by default which installs an older CMake (< 3.1.0). See the workaround here - http://askubuntu.com/questions/610291/how-to-install-cmake-3-2-on-ubuntu-14-04

I had to also sudo apt-get install git make unzip g++ python-jinja2 python-empy

After this make posix_sitl_default worked

[lovettchris]

Yeah, the python dependency in the PX4 build is new. I just did "sudo apt-get install python-dev". Ultimately we point people to the PX4 build instructions.

[NoelStephens]

Hi guys,
Thanks for the potential fixes... neither fix helps with this issue. Ran through the instructions provided by Dan and also made sure python was installed... still the exact same error... which is the:
/bin/sh: 1: cd: can't cd to /mnt/c/Dev/Firmware/build_posix_sitl_default

I am so confused why PX4 can be compiled on Windows... or for that matter why no flight module software to date cannot run under a Windows OS.

Hmm, ok... so I guess I will scrap that virtual machine back to the original default and retry the entire process once again... but I am thinking there is another issue with the most recent updates.

Already ran into Unreal issues... which has to do with versions, project files, and how some of the plugin code seems to take an abnormally long time to load seemingly small maps (with AirSim included).

First time my dual Xeon with 40 cores and 512GB of Ram has spent any duration of time with all 40 logical processors maxed...

Also noticed that an abnormal amount of network traffic is generated during various portions of compiling...mostly on the Unreal side...

Let you guys know what happens with a clean install... might even include screenshots of OS version, pulling the PX4 repository, getting python, updating CMake for BASH for Windows, and the final error that you arrive to when you attempt to make the PX4 under BASH for Windows according to the directions.

(there really needs to be a Win64 PX4 version)

[clovett]

Are you on a Windows inside build by any chance? I have head trouble with build 15033 to 15040.

The make error 2 you reported sounds like your px4 build development is not set up right.

Most flight controller hardware doesn't use windows our Linux. px4 is actually using a tiny realtime os called NuttX which runs on a Cortex M4 chip. So they use gcc to cross compile that, and gcc runs best on Linux. There is an unsupported way to build it on windows using mingw but it is slow. Then they built a version of px4 for simulators that recompiles a bunch of the px4 nuttx code to run on a real os and it was just easier to do that on Linux because the whole Linux toolchain was already being used...

[NoelStephens]

Hi Clovett,,

The virtual machine is the most recent version of Windows 10 with all updates per the MSDN Jan 2017 ISO image, and as such it has the required patches already installed as well as I make sure to run updates until there are none left. (side note: tried this on another development system that had the Windows Driver Framework installed and evidently that makes compiling boost a very difficult task due to the way the make files search for the ctype.h file).

Regarding the reason for PX4 not running on any Windows OS, I guess I have just been running all Microsoft stuff since most ancillary operating systems (especially Linux/Unix/BSD derived) have been known to have back door exploits hidden within them that most people are unaware; of which, many exploits have existed for years (some over a decade) with most people unaware of the exploits.

Windows NanoServer runs a very small footprint that requires a minimum of 512MB of RAM and can be retrofitted to use less than 16GB of storage space (they say 32GB but it can work under 16GB just fine) of course the CPU requirements being x64 is always an issue when looking at ARM vs Intel/AMD. However with newer SoC designs and chips (i.e. Intel Edison), the types of requirements needed today for most boards that many UAV/Drones utilize are not quite the same as they were half a decade ago.

We are trying to avoid (for security reasons) having to depend upon a virtual machine running something like Ubuntu that then runs PX4... but mayhaps this is the only way for the time being.

There is some very awesome work done on this project thus far...just so anyone reading this understands I am by no way knocking the project... great idea...

Ok... my new VM finished updating and will run through the process once more... ;)

[NoelStephens]

Ok,
I think I figured out one of the things I missed:
The instructions per line item 2:

"Type bash at Windows command prompt. Follow these steps for Linux and follow the instructions under NuttX based hardware to install prerequisites."

It would seem that I interpreted that as being "For windows use BASH and for Linux follow these instructions"...

Now that I have run through setting up a fresh new OS and got to step #2, it occurred to me that one must run through the NUTTX steps for the Linux install instructions using the Windows BASH command prompt.

Just a note for the SITL instructions in compiling all of this under the Windows BASH, further clarification that the same NUTTX steps used for a Linux distribution should be implemented using Windows BASH.

Some of us 'too-literal' folks might tend to separate line item 2 into two instructions. One being the Windows BASH invocation (first sentence) for a Windows build and the other being a Linux distribution that requires the additional steps (second sentence) provided by the included link.

:)

So, my gut was telling me that I most likely missed something...and most likely it was the NUTTX steps under the Linux distribution instructions that was causing the error...

Getting everything applied/downloaded and will let you know....but just to clarify... my previous attempts did not include the Linux-NUTTX steps...which I would bet is the culprit causing all of my woes... for now. :)

Update on one more semi-confusing point
Speaking of the instructions for SITL and step 2 with the Linux tool chain instructions, at the bottom of the NUTTX instructions it points one to the following Arch and CENTOS.

For those that are more experienced in Windows development and all of the intricacies involved rather than the various Linux/BSD/Unix offshoots... which of the two (Arch vs CENTOS) paths/instructions should one take? Both are Linux derivatives but I believe NUTTX is a BSD derived kernel...? (maybe not been awhile since I have dug around in the Linux/BSD/Unix world).

Anyway, just any form of note in the original AirSim SITL instructions regarding which portions of the Linux tool chain for NUTTX's last stages of setup could be useful (use Arch instructions or CENTOS or neither/skip).

Just one minor thing that could help other more "Windows oriented" developers manage their way through setting up a simulated PX4 module.

[NoelStephens]

Ok,
The missing Linux tool chain step was the missing element. Per my update in the previous post, the following commands will do everything needed to setup the PX4 tool chain build environment, get the firmware, and compile it:
Install Windows Bash as per the instructions for SITL.
After creating the first account under Windows BASH, exit the CMD session (i.e. type exit and then exit again until the command window closes).
Re-open a new command window, run bash, and then execute the following commands:
(you might do one at a time to just make sure it all works out)
+++++++++++++++++++++++++++++++++++++++++
sudo apt-get remove modemmanager

sudo apt-get install python-serial openocd
flex bison libncurses5-dev autoconf texinfo build-essential
libftdi-dev libtool zlib1g-dev
python-empy -y

sudo apt-get remove gcc-arm-none-eabi gdb-arm-none-eabi binutils-arm-none-eabi gcc-arm-embedded
sudo add-apt-repository --remove ppa:team-gcc-arm-embedded/ppa

sudo usermod -a -G plugdev $USER

pushd .
cd ~
wget https://launchpad.net/gcc-arm-embedded/5.0/5-2016-q2-update/+download/gcc-arm-none-eabi-5_4-2016q2-20160622-linux.tar.bz2
tar -jxf gcc-arm-none-eabi-5_4-2016q2-20160622-linux.tar.bz2
exportline="export PATH=$HOME/gcc-arm-none-eabi-5_4-2016q2/bin:$PATH"
if grep -Fxq "$exportline" ~/.profile; then echo nothing to do ; else echo $exportline >> ~/.profile; fi
. ~/.profile
popd

sudo apt-get install python-jinja2

git clone https://github.com/PX4/Firmware.git
cd Firmware
git submodule update --init --recursive
make posix_sitl_default
+++++++++++++++++++++++++++++++++++++++++

After all of the above commands I was able to invoke the PX4 firmware using the following command:

./build_posix_sitl_default/src/firmware/posix/px4 ./posix-configs/SITL/init/lpe/iris

Anyway, for anyone else having issues with building PX4 under Windows BASH, follow the above instructions and you should be good to go. As a side note, running it under a virtual machine with standard snapshots for various stages will save many hours of troubleshooting in the event you want to do a sanity check and roll-back to a previous state.

Thank you Chris, Dan, and Clovett for the additional info that helped point me in the right direction to get a PX4 firmware built and running under Windows BASH.

Cheers,

N

[lovettchris]

Awesome, sounds like you got it working. Welcome to the wonderful world of PX4 development :-) I'm a long time windows only guy, having been at Microsoft for 20 years now, but I have to say I'm really enjoying the learning about the cross-platform world of Research. The other day I had IntelliJ debugging jMavSim, Eclipse debugging the Pixhawk hardware, QTCreator debugging QGroundControl and Visual Studio debugging our Simulator all at the same time. 4 different IDE's. Yikes!

But I have to say BashOnWindows is the best thing Windows has done in a long time. It make my life much easier having the real Linux toolchain available on the same machine. All I wish now is that they would add USB serial port support so I can also flash the Pixhawk firmware from there. I also love the new cross-platform Visual Studio Code IDE. It has a nice markdown editor, and git integration, C++ and C# intellisense, very nice. Snappy too. But I digress.

I added a bit more clarification to the SITL setup so folks don't miss the need to install the full PX4 toolchain.

[NoelStephens]

Well I got it working and have been fiddling with getting the right version of Unreal to load the right map and all of that. Either case, I think once there are at least one or two flight modules migrated to something more like Windows IoT Core, like the Navio SDK for Windows IoT Core, it will become fathoms easier for us more Windows oriented/minded folks. I don't mind learning new things, but keeping up with all iterations of the major operating systems, their quirks, intricacies, and the like... it can be a little much for those who have more strict schedules.

After running through the hoops on this one, other than the SITL instructions for a "Windows BASH PX4 Flight Module instance" the only other thing worth suggesting would be to include a simple, small terrain, Unreal project that already has everything setup. This has nothing to do with your project and the instructions, but has a lot to do with the Unreal engine and its intricacies and crevices to avoid...which I can say now by experience that trying to use the existing binaries offered by Epic rather than building your own doesn't seem to work and using the most recent branch I think works, but have been dealing with some performance issues during load time that I believe is more related to the engine content pipeline...but then again it has been almost a decade since I built an actual game using that tech and I went with some of the more complicated terrain...so it is most likely the initial build for the assets that causes the delay. I should have just created my own simple map and taken it from there...but the "bling bling" of the pretty terrain maps available and a little bit of rushing through the Unreal side of this puzzle...and patience on the initial loads of more complicated maps is the most probable cause to my issues on that end.

I like Epic and they have awesome tech... always liked Tim Sweeney's architecture and his vision for game engine development as it pertains to the editor and the experience a developer walks away with....but just out of curiosity sake...was there ever a time that anyone on this project thought to use the Unity engine? Was it the ability to leverage from C++ that made Unreal more attractive or was it just an Engine that someone on this team was familiar with and decided to use?
(just very curious as to why Unreal vs Unity )

Really, the flight modules need to become more "Windows Centric".... there definitely needs to be like a Windows IoT Core or Windows Nanoserver as a base operating system that hosts a flight module...

When that wall comes down... it becomes exponentially easier to make a drone "100% Microsoft".... in regards to all of the operating systems circling around a single drone's existence...

As of right now... it is like 25% Microsoft and 75% all things Linux/Unix/BSD.... and that last ~75%....in most cases...is at least two different variations of Linux/Unix/BSD. Which makes most drone developers have to develop for at least 2 but most times 3 operating systems... the main processing board typically runs a form of Linux\BSD, the Flight Module typically runs something like NUTTX, and the client/management application typically runs on Windows, Android, or iOS.

When that development path can be all Windows...then you have developers focusing on developing drone stuff and not figuring out quirks or the like in 3 operating systems and the development tools that follow them...which can consume a very large portion of the developer's time.

Your project brings us that much closer... so for sure... hats off to you all....

Will let you know when I get it actually running in Unreal.

Cheers,

N