I am not sure what is missing when i try to set up a docker container with mapping my local_src directory to the container.
The steps that I took are pretty much the same as in the documentation here.

1.) pull docker file:
docker pull px4io/px4-dev-ros:2017-05-31

2.)
xhost +
docker run -it --privileged \
-v <src_to_local_firmware>:/src/firmware/:rw \
-v /tmp/.X11-unix:/tmp/.X11-unix:ro \
-e DISPLAY=:0 \
-p 14556:14556/udp \
--name=px4_ros_sim px4io/px4-dev-ros:2017-05-31 bash

I also tried to pull different images of the px4-dev-ros (the latest and v1.0). In all attempts I successful entered the container and the Firmware was in the /src/firmware as expected, but I was not able to build anything but received the error that no Makefile was found (despite having a Makefile in the directory)

Topic is complete bollox. Should be tidied up. Pull in this section from the linked topic here

Bug Page: Initial Configuration · PX4 Developer Guide

currently it is not possible to merge due to broken tree.

I try to run mavros with gazebo, but, i did not find the file integrationtests/setup_gazebo_ros.bash in the firmware, i am a green hand in ros

Since 2 days the Docker page and others from "Testing and CI" category are no longer accessible.
Check this commit:
5a329d1#diff-e75fb246c17ec91f37861dccb8d751bf

In http://dev.px4.io/flow_lidar_setup.html or Devguide/flow_lidar_setup.md there is description about using locap position estimator. Hoever untill SYS_MC_EST_GROUP parameter is set to lpe all the lpe parameters mentioned in the documentation won't be visible. So I think setting SYS_MC_EST_GROUP parameter to appropriate setting and doing a reboot should be added to the documentation.

There is a missing zip file "design files" on this page -

* Left and right 3D-printed motor mount ([design files](parts/motor_mounts.zip))

Any idea where they might be located?

Bug Page: TBS Caipiroshka · PX4 Developer Guide

As it currently stands the documentation on interface to ROS with gazebo is not quite correct.

First, the second instruction on launching gazebo with ROS wrappers

make posix_sitl_default

would not compile the sitl_gazebo submodule. If the user has not previously built the sitl_gazebo package, the instruction should be

make posix_sitl_default gazebo

which would force the makefile to build the sitl_gazebo package alongside

Second, even if the above correction is applied, the simulation still would not run properly if the

mavros_posix_sitl.launch

file is run, specifically mavros would be unable to connect to the simulated drone in gazebo.

I've personally found a workaround to this problem and is currently able to run mavros and gazebo in both Ubuntu 14.04 and 16.04 using Gazebo 6 and 7. It is as follows

1. create a catkin workspace in a folder

mkdir catkin_ws && cd catkin_ws
catkin init 
mkdir src

2. clone both the firmware and the sitl_gazebo package into the src folder of the workspace

cd src
git clone https://github.com/PX4/Firmware.git
git clone https://github.com/PX4/sitl_gazebo.git
cd Firmware
git submodule update --init --recursive
cd ../..

3. build the catkin workspace with both packages, source the workspace, and run

catkin build
source devel/setup.bash
roslaunch px4 mavros_posix_sitl.launch

I realize that the sitl_gazebo package is contained within the Firmware folder as a submodule, and thus this methods is quite inefficient in terms of space usage, however this remains the only method I know of that could run mavros with gazebo, and as such I would like the ask the devs if this can be the recommended method on the devguide.

If so, I would happily submit a pull request to update the devguide, if not, then this can be a reference to others as a workaround for the current system

Some docs here: PX4/PX4-Autopilot#7625

From @LorenzMeier on slack:

1. Install gstreamer to your system (homebrew is broken, better by hand)
2. In Tools/sitl_gazebo:

diff --git a/CMakeLists.txt b/CMakeLists.txt
index a590fef..dc19cee 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -20,7 +20,7 @@ include(GNUInstallDirs)
 list(APPEND CMAKE_MODULE_PATH /usr/local/share/cmake/Modules)
 list(APPEND CMAKE_MODULE_PATH "${CMAKE_CURRENT_LIST_DIR}/cmake")
 
-option(BUILD_GSTREAMER_PLUGIN "enable gstreamer plugin" "OFF")
+option(BUILD_GSTREAMER_PLUGIN "enable gstreamer plugin" "ON")
 
 ## System dependencies are found with CMake's conventions
 find_package(PkgConfig REQUIRED)

3. Make a clean build
4. Do

make posix gazebo_typhoon_h480

Should give you a video stream and geo-tagged images

• Camera: https://github.com/PX4/sitl_gazebo/blob/master/src/gazebo_gst_camera_plugin.cpp
• Geotagging: https://github.com/PX4/sitl_gazebo/blob/master/src/gazebo_geotagged_images_plugin.cpp

Gimbal and camera setup stuff seems to be a common pain point for regular users that want to do something productive with PX4 (more than a flying toy).

• http://discuss.px4.io/t/gimbal-configuration-and-documentation/832/3
• https://dev.px4.io/advanced-gimbal-control.html

jiapei:Devguide$ npm install
npm WARN enoent ENOENT: no such file or directory, open '....../px4/Devguide/package.json'
npm WARN Devguide No description
npm WARN Devguide No repository field.
npm WARN Devguide No README data
npm WARN Devguide No license field.

cheers
Pei

Mavlink Streams

It would be nice if this page provided more info on setting up mavlink streams.

Additional information could include:

• Available stream name + descriptions
  • see below for a list I extracted from the source code
• More details on how to configure start up streams( config.txt, extras.txt)
  • This is kind of here but not really for mavlink
• How to set/unset streams via mavlink
  • And mavros
  • Especially since the way you request streams has changed(mavlink deprecations)
• A note to user so they are aware of this bug( is says it's closed but it's still an issue for me)
  • PX4/PX4-Autopilot#3291

Available Streams

Bug Page: MAVLink Messaging · PX4 Developer Guide

Plugins for heading anchors and richquotes are in conflict:
erixtekila/gitbook-plugin-richquotes#25

This is just for tracking.

@bkueng Could you create a page or section for the SD card recommendations and a brief explanation why this matters (500 ms allowed block time per SD card standard and associated buffering needs?)

I think that would be very valuable for developers.

Doc is: https://dev.px4.io/en/simulation/gazebo.html

1. Docs say supports standalone use (without ROS) or SITL + ROS. Would it be more correct to say Gazebo supports integration to SITL either with or without ROS.
2. What can you do with Gazebo for testing that you can't do with the basic simulator?
   • Why is it better?
   • What vehicles can you simulate.
   • Is changing/simulating a vehicle configured in SITL or Gazebo or both? How? I think something to do with the start commands make posix_sitl_default gazebo_tailsitter but don't know what arguments are/options.
   • Can you simulate all the things I mentioned in #181 - wind, compass failure, GPS failure etc - and if so, in what way/where?
3. As I understand it ROS adds ability to use offline mode and drive the vehicle remotely using scripts/components. So I guess the main reasons for us are to add automation both for "super flight modes" (as per dronekit) and for automated testing.
   • Is that correct?
   • Anything else that makes it useful?
   • If you install ROS (as per the "interfacing" doc can you still invoke Gazebo "as normal" in this doc
4. When you have Gazebo started, do you fly it in just the same way as for the Basic simulation - e.g. via GCS? What I'm heading towards here is that it might be worth separating out the doc on "how to fly the sim" for use by both.
5. Gazebo 8 is coming along. Do we have a plan to support it.
6. Gazebo 7 is recommended everywhere. Would we be better off presenting the Gazebo 7 option and having Gazebo 6 as an "aside" - or to put it otherwise, why do we ever suggest Gazebo 6?
7. In the section Change World it says "The current default world is the iris.wold located in the directory worlds. The default surrounding in the iris.world uses a heightmap as ground. This ground can cause difficulty when using a distance sensor. If there are unexpected results with that heightmap, it is recommended to change the model in iris.model from uneven_ground to asphalt_plane."
   • How do you change the iris model?
   • How do you change the default world?
   • The video shown here has an interesting world, not just an empty plane. How do I get a world like that?
8. In extending and customising section it says: "To extend or customize the simulation interface, edit the files in the Tools/sitl_gazebo folder. The code is available on the sitl_gazebo repository on Github."
   • What customisation might you want to do
   • Are there any good docs on customisation
   • Do you edit in the repo or in the subfolder? I guess you do basic tests in the subfolder but you have to commit to the repo to get changes into the master?

RTL will transition to MC regardless of the NAV_FORCE_VT parameter: https://github.com/PX4/Firmware/blob/master/src/modules/navigator/rtl.cpp#L326-L328

Not sure if this is intended or a bug - but either the implementation or docs need to be updated.

Would be nice if pyulog was included in ubuntu_sim_nuttx.sh

In #285, I mention that a section about MAVLink would be helpful somewhere. On Slack, @hamishwillee mentioned creating a "Setting up MAVLink Ports & Streams" section in the "Simulation" topic.

In my opinion, that could be a new section in "Concepts", that would clarify the following points:

• How exactly does the MAVLink connection work?
  • Here we could have a simplified image (maybe the same as here?) showing that the PX4 on SITL broadcasts on 14550 (meant for QGC), but also that the SITL startup file (as shown here can specify other MAVLink interfaces.
  • We would also explain that usually (AFAIK, at least), we use (src: 14556, dst: 14550) for QGC and (src: 14557, dst: 14540) for others like Mavros or DroneCore.
  • I'd like to know here if the startup file is only for the SITL or also for the PX4 itself. In other words, does my Pixhawk use (src: 14556, dst: 14550) and (src: 14557, dst: 14540) by default, or not? I don't know how this actually works.
  • We would explain here that the client usually waits for a broadcast on 14550 or 14540, but it can also connect directly if it knows the port on the PX4 side (which is usually 14556 or 14557 in the SITL config files).
• How to configure a MAVLink interface?
  • Here, assuming that the PX4 also has a startup script, we would explain in details the kind of commands we can do. Or at least point to a detailed reference.
• MAVLink protocol and alternatives
  • I would see something explaining what MAVLink provides or not, maybe links to useful resources, and a comparison with using FastRTPS (e.g. "MAVLink is more stable, but FastRTPS is more flexible").

Let me know what you think and if I should start such a section. Maybe all of this belongs to the "Simulation" section, but I don't know how it works with the hardware, as I've only been using SITL.

One reason why I see it more as a concept is that I would like to link it from different places (basically everytime one need to understand how QGC, Mavros or DroneCore connects to the PX4).

Our team is using a Snapdragon Flight. We followed the PX4 installation instructions found on http://dev.px4.io but were having many issues, particularly with the proprietary ESC board; namely, we could not get any communication to the motors through the board. We contacted Intrinsyc for help on this and they told us to follow the installation instructions found on the ATLFlight/PX4 fork (found here). When we followed these instructions (in particular, the instructions for Building with FC_ADDON drivers) everything seemed to work as intended.

The instructions on this page are very different than what is listed on the current PX4 dev documentation, and it took us many weeks and having to contact the vendor in order to determine the proper installation procedure.

Why is there a discrepancy between what is on the PX4 dev documentation and what is on the ATLFlight repo? What is the difference between eagle_legacy_default and eagle_default? Do the instructions on the PX4 dev docs need to be updated so others do not have this problem in the future?

To use any other airframe and load its correct mixer is necessary to edit the line 34 of px4.config

For example, if u want to load the hexa mixer:
linux_pwm_out start -m ROMFS/px4fmu_common/mixers/hexa_x.main.mix

I think this information should be in airframe_reference section

Verified in commit dc8caea from master

I tried to follow the integration testing example, but already failed on the first line. I do not see any "setup_gazebo_ros.bash" file within integrationtests folder.

Hey,
I try to create an own application for my DroPix, so I started with the "Hello Sky" Tutorial. First my compiler wants a CMakeList.txt file which is not described in the tutorial, but I was able to create one on my own 😆

px4_simple_app.c

#include <px4_config.h>
#include <px4_tasks.h>
#include <px4_posix.h>
#include <unistd.h>
#include <stdio.h>
#include <poll.h>
#include <string.h>

#include <uORB/uORB.h>
#include <uORB/topics/sensor_combined.h>
#include <uORB/topics/vehicle_attitude.h>

__EXPORT int px4_simple_app_main(int argc, char *argv[]);

int px4_simple_app_main(int argc, char *argv[])
{
    PX4_INFO("Hello Sky!");
		
    return OK;
}

CMakeLists.txt

px4_add_module(
	MODULE examples__px4_simple_app
	MAIN px4_simple_app
	STACK_MAIN 2000
	SRCS
		px4_simple_app.c
	DEPENDS
		platforms__common
	)

nuttx_px4fmu-v2_default.cmake

# Tutorial code from
# https://px4.io/dev/px4_simple_app
examples/px4_simple_app

Compiler prints correctly compiled:

-- Building and including px4io-v2
-- Configuring 
-- Version: 1.0.6
-- To change the version modify the file configure.ac
-- micro-CDR without check endianness
-- NuttX: px4fmu-v2 nsh cortex-m4
-- ROMFS: px4fmu_common
-- Configuring done
-- Generating done
-- Build files have been written to: /Firmware/build/px4fmu-v2_default

and the upload seems to work:

Firmware chris$ make px4fmu-v2_default upload
[0/1] uploading /Firmware/build/px4fmu-v2_default/nuttx_px4fmu-v2_default.px4
Loaded firmware for 9,0, size: 1031060 bytes, waiting for the bootloader...
If the board does not respond within 1-2 seconds, unplug and re-plug the USB connector.
Attempting reboot on /dev/tty.usbmodem1 with baudrate=57600...
If the board does not respond, unplug and re-plug the USB connector.
Found board 9,0 bootloader rev 4 on /dev/tty.usbmodem1
ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff type: ÿÿÿÿ
idtype: =FF
vid: ffffffff
pid: ffffffff
coa: //////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////8=

sn: 002d00323334510b32363238

Erase  : [====================] 100.0%
Program: [====================] 100.0%
Verify : [====================] 100.0%
Rebooting.

but I do not have the px4_simple_app in my Builtin Apps now:

nsh> help
help usage:  help [-v] [<cmd>]

  [           date        free        mount       rmdir       true        
  ?           df          help        mv          set         umount      
  break       echo        kill        mw          sh          unset       
  cat         exec        ls          ps          sleep       usleep      
  cd          exit        mkdir       pwd         test        
  cp          false       mkfatfs     rm          time        

Builtin Apps:
  adc
  bl_update
  bst
  camera_feedback
  camera_trigger
  commander
  config
  cu
  dataman
  ekf2
  ets_airspeed
  fmu
  frsky_telemetry
  fw_att_control
  fw_pos_control_l1
  gnd_att_control
  gnd_pos_control
  gpio_led
  gps
  hardfault_log
  hmc5883
  l3gd20
  land_detector
  lis3mdl
  ll40ls
  load_mon
  logger
  lsm303d
  mavlink
  mc_att_control
  mc_pos_control
  mixer
  mpu6000
  mpu9250
  ms4525_airspeed
  ms5525_airspeed
  ms5611
  mtd
  navigator
  nshterm
  param
  perf
  pwm_input
  pwm
  pwm_out_sim
  px4flow
  px4io
  reboot
  rgbled
  sdp3x_airspeed
  send_event
  sensors
  sercon
  serdis
  sf0x
  teraranger
  tone_alarm
  top
  ulanding_radar
  uorb
  ver
  vmount
  vtol_att_control
nsh> 

Where is my fault? 😩🤔

Some time ago the Tutorials section had information about configuring the land detector, which is missing at the moment. The source file is still there, though.

Apparently it is important to do an orb_copy after every successful poll. If neglected it can cause busy loops, which in turn can lead to vehicle crashes. This is something that may be non-obvious to new developers and I feel it is important to document this. I assume there are other such examples that are obvious to seasoned developers.

This information should be presented to anyone reading the hello_sky uORB tutorial.

As per #280

This should be done after autopilot migrate to the user guide.

Broken link...
This page:
https://dev.px4.io/en/advanced/realsense_intel_driver.html
Contains this link:
RealSense_ROS repository
That points here:
https://github.com/PercATI/RealSense_ROS
and there is no there, there.

A couple lines below that, there is another broken link.
"Follow instructions given in here".
where the word "here" is a link that's also broken.

Is there an alternate location for these files? Or an equivalent option?

Cheers,
-Randy

Hello,

I believe it would be useful for newbies to understand the entire build process.
Having a Makefile which invokes cmake to generate a build Makefile is not common.
I spent a little time understanding what is going on behind the scenes.

This also has the benefit to use whatever CMake generator you like (e.g. Eclipse).

Here is a quick example on how to have separate directories for

• source
• build
• install

I'm going to assume that the source is in $HOME/aero-src/px4, build in $HOME/aero-build/px4, install in $HOME/aero-install/px4.

mkdir -p $HOME/aero-build/px4
cd $HOME/aero-build/px4
cmake \
-DCMAKE_INSTALL_PREFIX=$HOME/aero-install/px4 \
-G"Unix Makefiles" \
-DCONFIG=posix_sitl_default \
$HOME/aero-src/px4

make -j8
make install

# Running PX4
cd $HOME/aero-install/px4
$HOME/aero-install/px4/bin/px4 \
$HOME/aero-install/px4/share/px4 \
$HOME/aero-install/px4/share/px4/posix-configs/SITL/init/ekf2/solo

Generating an Eclipse project which can be imported:

rm -rf $HOME/aero-build/px4
mkdir -p $HOME/aero-build/px4
cd $HOME/aero-build/px4
cmake \
-DCMAKE_INSTALL_PREFIX=$HOME/aero-install/px4 \
-G"Eclipse CDT4 - Unix Makefiles" \
-DCONFIG=posix_sitl_default \
$HOME/aero-src/px4

If you like the idea, I can prepare a PR.

For beginners in debugging, like me, it would be very helpfull to have a manual how to connect the probe on a PX4 (for example Pixhwak) and start the first debugging with Qt Creator on a Linux System (Ubuntu).
I found a few hints on the "pixhawk.org" site and as a electric engineer I also like the "try and error" system. But sometimes you get a moment where nothing will work and then it get's really frustrating.
So it would be nice if I could found something at the very nice PX4 Developer guide.

Thanks and best regards,
Markus

I just added a language switcher plugin in #134. This works locally and on my test gitbook site. HOwever it is not working/displaying on the live site.

Hey,

i just noticed that the link behind the SYS_COMPANION under 2. in https://dev.px4.io/en/ros/offboard_control.html links to the old parameter site https://pixhawk.org/firmware/parameters#system, which offers a link to go back to the new guide https://dev.px4.io/en/advanced/parameter_reference.html.

Updated circuit diagram - with labels showing on what device we're connecting
#263 (comment)

@crossa Make Chinese version match English version
#263 (comment)

Create PCB that replaces the breadboard
@crossa @TSC21

The current documentation in the DevGuide in regards to External Position Estimation is quite outdated. In particular since EKF2 is now feature complete and the default estimation engine, the guide should at least be extended to cover external position estimation under EKF2 in addition to the existing docs for LPE.

The current documentation on ecl EKF is quite extensive and cover some of the material already.

@bkueng Do we need still Motor Map · PX4 Developer Guide ?

The Airframe reference is far more complete and useful. We could redirect links to here to the Airframes reference instead.

If we do keep this, we should update it to link to the Airframes ref.

[Note: this is my first post in github... please let me know (gently) all the things I did wrong so I can make sure to not repeat them.]

in dronekit-example.md, the home position is set using the global frame:
home = vehicle.location.global_frame
however, the Mavlink commands are using the global relative frame:
# takeoff to 10 meters wp = get_location_offset_meters(home, 0, 0, 10); cmd = Command(0,0,0, mavutil.mavlink.MAV_FRAME_GLOBAL_RELATIVE_ALT, mavutil.mavlink.MAV_CMD_NAV_TAKEOFF, 0, 1, 0, 0, 0, 0, wp.lat, wp.lon, wp.alt)

The code as is causes the UAV to climb to your current home MSL + 10 meters.
Changing the home to:
home = vehicle.location.global_relative_frame
...causes the UAV to behave as expected.

Not as much as a problem but rather a suggestion.
Maybe it would be pertinent to concatenate the information found at https://dev.px4.io/en/concept/mixing.html and adding a new frame -> mixer file

Bug Page: Adding a new Airframe · PX4 Developer Guide

Weekly Dev Call time and "location" seems to be inconsistent with respect to forum info.

Bug Page: Contributing & Dev Call · PX4 Developer Guide

In this link
Under Run it for Snapdragon Flight,

to launch mini-dm, the command should be:
${HEXAGON_SDK_ROOT}/tools/debug/mini-dm/Linux_Debug/mini-dm

instead of ${HEXAGON_SDK_ROOT}/tools/mini-dm/Linux_Debug/mini-dm

DESCRIBE PROBLEM WITH DOCS HERE

Bug Page: 远距离视频流 · PX4 Developer Guide

The scheduling concepts used in PX4 should be documented and best practices and considerations should be explained. Getting this wrong can cause vehicle crashes, such as in PX4/PX4-Autopilot#7801, which even end up in stable releases.

On a wider scope, I think it would be extremely valuable if there were a chapter/tutorial on "how to make your application safe" where crucial considerations and tools are covered that help ensure new features do not cause problems down the road. This should include checking the stack with top, -fstack-usage, http://nuttx.org/doku.php?id=wiki:howtos:run-time-stack-checking, checking the increase in CPU caused by this feature, testing features thoroughly in HITL, and any other tools that I have not yet learned about.

In the Mavlink shell paragraph on the System Console page, I think it should be mentioned that the Mavlink shell is available in QGC now (since which version?).
Right now, I think the only mention of it is on the sensor/topic debugging page.

We need to add docs for i2c, UART, CAN, etc. and how to use the respective drivers.

It is possible to share a UART port with MAVLink. We need docs explaining how. Context was a discussion in the bridge docs - reproduced below.

+> Note If the selected UART port is busy, it's possible that the MAVLink application is already being used. If it is the case, you can stop MAVLink from NuttShell by typing:

@hamishwillee Will this happen because MAVLink is being used by "accident" and should not be (e.g. it is a configuration issue and the port should be dedicated to the bridge), or will it happen because the port must be shared?

• If the former, then I'd say that is a bug, and in "real use" this should not happen as part of the normal flow. In this case would this not be a troubleshooting bug while we start moving from MAVLInk to RTPS where needed?
• If it is actually a shared port and this could happen intentionally then turning off MAVLink isn't really a solution - right?

@vilhjalmur89 It can be either of them.

• For first case you probably selected the wrong port for either the bridge or mavlink. So stopping mavlink is good enough for testing, but is not a real solution.
• For second case some documentation is needed for how to run the bridge and mavlink on the same port.

The doc has some questions that it would be good to answer: https://dev.px4.io/en/simulation/sitl.html

1. This is "Basic Simulation".

   • In what way is it basic?
   • What can you do with this simulation and what can't you do that you might expect to be able to
   • What can't you do this with simulation that you can with Gazebo and with ROS + Gazebo (which presumably count as "advanced".

2. Some things I might like to do that I can't see from information provided (please advise if possible or not, and if possible, how):

   • How connect to a GCS
     • Looks like QGC auto detects if on same machine. (is there any way to see "how" QGC is connected?)
     • What UDP is it connecting to? udp:127.0.0.1:14550 ?
     • Are any other GCS known to work - MAVProxy?
     • What if I want to connect GCS from another computer - can I do that?
   • What UDPs are exposed? (e.g. to connect companion computer). Can I add more?
   • How can I change the vehicle simulated? What are the options? (I'm guessing just use QGC firmware, but then the vehicle would need to be calibrated ...)
   • Are there sets of parameters I can preload for different testing?
     • What options are available there.
     • How do I load them?
     • Can I use QGC to play with parameters?
   • How can I test various fail states - loss of GPS, crossing geofence,
   • How can I test changes in environment - wind, vibration, magnetic interference, overheating
   • How can I test additional components - rangefinders, gimbals, optical flow sensors, parachutes etc

3. The simulation is demonstrated with commander takeoff.

   • Why is this used for demo - is it just because it is a basic command you can send from the shell?
   • Are there other good commands you can use to move the vehicle around? Or would that all be done via GCS.

4. The command make posix_sitl_default jmavsim - what are the "bits" ie "posix_sitl_default" and jmavsim. Are there options for these - e.g. to simulate some other vehicle

5. In simulating a wifi drone you can broadcast the IP on the local network.

   • Is the IP address for companion computer still exposed?
   • Does this change anything else - ie does this limit or change usage in other ways?
   • What is the URL that QGC on another computer would look for to connect to this vehicle?

6. In extending and customising:

   • It says "To extend or customize the simulation interface, edit the files in the Tools/jMAVSim folder. The code can be accessed through the jMAVSim repository on Github." - are you saying that you should edit the files in the jMAVSim repo or the Tools/jMAVSim folder - it seems both!
   • What extension/customisation might someone reasonably want to do?

7. The "Important Files" sections says the following

   • Why are these important - what can you do with them?

   The startup script is in the posix-configs/SITL/init folder and named rcS_SIM_AIRFRAME, the default is rcS_jmavsim_iris.
   The root file system (the equivalent of / as seen by the) is located inside the build directory: build_posix_sitl_default/src/firmware/posix/rootfs/
   

I got this started in virtualbox with QGC and the latest PX4. However as soon as it takes off I get "Failsafe enabled: no local position" essages. Lots of drifting of my vehicle. EFK Fusion timeouts reported. GPS seems OK in that QGC shows 10 satellites. Is there something I can do to simulation to get everything to work "out of the box" in terms of flying the vehicle?

Looks like the timesync and vision pages got lost due to force push or something.

In the config file is the class tag missing.

# @type Flying Wing

should be something like

# @type Flying Wing
# @class VTOL

We should get rid of these. The "disarmed" messages are misleading and annoying.

Page here
The Drag Specific Forces chapter mentions EKF2_AID_MASK bit 4, but that is used for "4: vision yaw fusion", https://dev.px4.io/en/advanced/parameter_reference.html
EKF2_BCOEF_X and EKF2_BCOEF_Y do not exist.