diff --git a/docs/cmake_linux.md b/docs/cmake_linux.md index 2b462421..8d2c98f3 100644 --- a/docs/cmake_linux.md +++ b/docs/cmake_linux.md @@ -2,20 +2,20 @@ If you don't have cmake version 3.10 (for example, 3.2.2 is the default on Ubuntu 14) you can run the following: -```` +``` mkdir ~/cmake-3.10.2 cd ~/cmake-3.10.2 wget https://cmake.org/files/v3.10/cmake-3.10.2-Linux-x86_64.sh -```` +``` Now you have to run this command by itself (it is interactive) -```` +``` sh cmake-3.10.2-Linux-x86_64.sh --prefix ~/cmake-3.10.2 -```` +``` Answer 'n' to the question about creating another cmake-3.10.2-Linux-x86_64 folder and then -```` +``` sudo update-alternatives --install /usr/bin/cmake cmake ~/cmake-3.10.2/bin/cmake 60 -```` +``` Now type `cmake --version` to make sure your cmake version is 3.10.2. \ No newline at end of file diff --git a/docs/custom_drone.md b/docs/custom_drone.md index 1647d45b..58e1ca2b 100644 --- a/docs/custom_drone.md +++ b/docs/custom_drone.md @@ -5,9 +5,9 @@ The AirLib library can be compiled and deployed on the companion computer on a r ![Flamewheel](images/Flamewheel.png) Once connected you can run MavLinkTest with this command line: -```` +``` MavLinkTest -serial:/dev/ttyACM0,115200 -logdir:. -```` +``` And this will produce a log file of the flight which can then be used for [playback in the simulator](playback.md). You can also add `-proxy:192.168.1.100:14550` to connect MavLinkTest to a remote computer where you can run QGroundControl or our @@ -15,11 +15,11 @@ You can also add `-proxy:192.168.1.100:14550` to connect MavLinkTest to a remote MavLinkTest then has some simple commands for testing your drone, here's a simple example of some commands: -```` +``` arm takeoff 5 orbit 10 2 -```` +``` This will arm the drone, takeoff of 5 meters, then do an orbit pattern radius 10 meters, at 2 m/s. Type '?' to find all available commands. @@ -32,18 +32,18 @@ When you land the drone you can stop MavLinkTest and copy the *.mavlink log file Once you are happy that the MavLinkTest is working, you can also run DroneServer and DroneShell as follows. First, run MavLinkTest with a local proxy to send everything to DroneServer: -```` +``` MavLinkTest -serial:/dev/ttyACM0,115200 -logdir:. -proxy:127.0.0.1:14560 -```` +``` Change ~/Documents/AirSim/settings.json to say "serial":false, because we want DroneServer to look for this UDP connection. -```` +``` DroneServer 0 -```` +``` Lastly, you can now connect DroneShell to this instance of DroneServer and use the DroneShell commands to fly your drone: -```` +``` DroneShell ==||=> Welcome to DroneShell 1.0. @@ -55,7 +55,7 @@ Waiting for drone to report a valid GPS location... ==||=> arm ==||=> takeoff ==||=> circlebypath -radius 10 -velocity 2 -```` +``` ## PX4 Specific Tools You can run the MavlinkCom library and MavLinkTest app to test the connection diff --git a/docs/faq.md b/docs/faq.md index 53c41419..84c95ff6 100644 --- a/docs/faq.md +++ b/docs/faq.md @@ -62,14 +62,14 @@ It depends on how big your Unreal Environment is. The Blocks environment that co #### How do I report issues? It's a good idea to include your configuration like below. If you can also include logs, that could also expedite the investigation. -```` +``` Operating System: Windows 10 64bit CPU: Intel Core i7 GPU: Nvidia GTX 1080 RAM: 32 GB Flight Controller: Pixhawk v2 Remote Control: Futaba -```` +``` If you have modified the default `~/Document/AirSim/settings.json`, please include your settings also. diff --git a/docs/playback.md b/docs/playback.md index 7074eec3..148389df 100644 --- a/docs/playback.md +++ b/docs/playback.md @@ -5,9 +5,9 @@ for the purpose of comparing real and simulated flight. The [recording.mavlink](logs/recording.mavlink) is an example of a log file captured using a real drone using the following command line: -```` +``` MavLinkTest -serial:/dev/ttyACM0,115200 -logdir:. -```` +``` Then the log file contains the commands performed, which included several "orbit" commands, the resulting GPS map of the flight looks like this: @@ -20,15 +20,15 @@ Now we can copy the *.mavlink log file recorded by MavLinkTest to the PC running When the Simulator is running and the drone is parked in a place in a map that has room to do the same maneuvers we can run this MavLinkTest command line: -```` +``` MavLinkTest -server:127.0.0.1:14550 -```` +``` This should connect to the simulator. Now you can enter this command: -```` +``` PlayLog recording.mavlink -```` +``` The same commands you performed on the real drone will now play again in the simulator. You can then press 't' to see the trace, and it will show you the trace of the real drone and the simulated drone. Every time you press 't' again you can reset the lines so they are sync'd to the current position, this way I was able to capture a side-by-side trace of the @@ -46,12 +46,12 @@ in my case I was using a lower than normal cruise speed, slow takeoff speed, and wait a long time before disarming (COM_DISARM_LAND) and to turn off the safety switches NAV_RCL_ACT and NAV_DLL_ACT (`don't` do that on a real drone). -```` +``` param MPC_XY_CRUISE 2 param MPC_XY_VEL_MAX 2 param MPC_TKO_SPEED 1 param COM_DISARM_LAND 60 param NAV_RCL_ACT 0 param NAV_DLL_ACT 0 -```` +``` diff --git a/docs/px4_build.md b/docs/px4_build.md index 14de0ce5..71d4c46c 100644 --- a/docs/px4_build.md +++ b/docs/px4_build.md @@ -3,16 +3,16 @@ ## Source code Getting the PX4 source code is easy: -```` +``` git clone https://github.com/PX4/Firmware.git cd Firmware -```` +``` Oh, and if you don't have git yet just run this: -```` +``` sudo apt-get install git -```` +``` We are currently testing using the 1.6.0rc1 version, but the latest master branch should be ok too. Now to build it you will need the right tools. @@ -28,22 +28,24 @@ the PX4 firmware, just follow the BashOnWindows instructions at the bottom of th ## Build SITL version Now you can make the SITL version that runs in posix, from the Firmware folder you created above: -```` -make posix_sitl_ekf2 -```` +``` +make px4_sitl_default none_iris +``` -Note: this build system is quite special, it knows how to update git submodules (and there's a lot of them), -then it runs cmake (if necessary), then it runs the build itself. So in a way the root Makefile is a meta-meta makefile :-) +Note: this build system is quite special, it knows how to update git submodules (and there's a lot +of them), then it runs cmake (if necessary), then it runs the build itself. So in a way the root +Makefile is a meta-meta makefile :-) -It shouldn't take long, about 2 minutes. If all succeeds, the last line will link the `px4` app, which you can then run using the following: +It shouldn't take long, about 2 minutes. If all succeeds, the last line will link the `px4` app, +which you can then run using the following: -```` -make posix_sitl_ekf2 none_iris -```` +``` +make px4_sitl_default none_iris +``` And you should see output that looks like this: -```` +``` creating new parameters file creating new dataman file @@ -68,33 +70,35 @@ INFO [dataman] Unkown restart, data manager file 'rootfs/fs/microsd/dataman' si CAL_ACC1_ID: curr: 0 -> new: 1310728 CAL_MAG0_ID: curr: 0 -> new: 196616 -```` +``` -so this is good, first run sets up the px4 parameters for SITL mode. Second run has less output. -This app is also an interactive console where you can type commands. Type 'help' to see what they are -and just type ctrl-C to kill it. You can do that and restart it any time, that's a great way to reset -any wonky state if you need to (it's equivalent to a Pixhawk hardware reboot). +so this is good, first run sets up the px4 parameters for SITL mode. Second run has less output. +This app is also an interactive console where you can type commands. Type 'help' to see what they +are and just type ctrl-C to kill it. You can do that and restart it any time, that's a great way to +reset any wonky state if you need to (it's equivalent to a Pixhawk hardware reboot). ## ARM embedded tools -If you plan to build the PX4 firmware for real Pixhawk hardware then you will need the gcc cross-compiler -for ARM Cortex-M4 chipset. You can get this compiler by PX4 DevGuide, specifically this is in their `ubuntu_sim_nuttx.sh` setup script. +If you plan to build the PX4 firmware for real Pixhawk hardware then you will need the gcc +cross-compiler for ARM Cortex-M4 chipset. You can get this compiler by PX4 DevGuide, specifically +this is in their `ubuntu_sim_nuttx.sh` setup script. After following those setup instructions you can verify the install by entering this command `arm-none-eabi-gcc --version`. You should see the following output: -```` + +``` arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 7-2017-q4-major) 7.2.1 20170904 (release) [ARM/embedded-7-branch revision 255204] Copyright (C) 2017 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -```` +``` ## Build PX4 for ARM hardware Now you can build the PX4 firmware for running on real pixhawk hardware: -```` -make px4fmu-v2_default -```` +``` +make px4_fmu-v4 +``` This build will take a little longer because it is building a lot more including the NuttX real time OS, all the drivers for the sensors in the Pixhawk flight controller, and more. It is also running the compiler @@ -107,7 +111,8 @@ hardware with these brand new bits, so you don't need to use QGroundControl for PX4 has many customizable parameters (over 700 of them, in fact) and to get best results with AirSim we have found the following parameters are handy: -```` + +``` // be sure to enable the new position estimator module: param set SYS_MC_EST_GROUP 2 @@ -124,7 +129,7 @@ param NAV_RCL_ACT 0 // enable new syslogger to get more information from PX4 logs param set SYS_LOGGER 1 -```` +``` ## Using BashOnWindows diff --git a/docs/px4_logging.md b/docs/px4_logging.md index 4e6456c5..9c91c1f5 100644 --- a/docs/px4_logging.md +++ b/docs/px4_logging.md @@ -6,16 +6,16 @@ Thanks to [Chris Lovett](https://github.com/clovett) for developing various tool The following command will connect MavLinkTest app to the Simulator and enable logging of all mavlink commands to and from the PX4. -```` +``` MavLinkTest -server:127.0.0.1:14550 -logdir:d:\temp -```` +``` Sometimes you will also want to log the "output" from the Simulator that is being sent to the PX4. Specifically this will capture the "hilgps" and "hilsensor" messages that are generated by the Simulator. To do that run this as well: -```` +``` MavLinkTest -server:127.0.0.1:14389 -logdir:d:\temp\output -```` +``` You will then see log files organized by date in d:\temp\logs, specifically *input.mavlink and *output.mavlink files. diff --git a/docs/px4_sitl.md b/docs/px4_sitl.md index 8789b5c1..de1c3c0d 100644 --- a/docs/px4_sitl.md +++ b/docs/px4_sitl.md @@ -93,10 +93,10 @@ unless the home location is set to the same coordinates defined in AVehiclePawn You can also run the following in the SITL PX4 console window to check that these values are set correctly. -```` +``` param show LPE_LAT param show LPE_LON -```` +``` ## Smooth Offboard Transitions @@ -108,30 +108,30 @@ Notice the above setting is provided in the `params` section of the `settings.js This tells the drone automatically hover after each offboard control command finishes (the default setting is to land). Hovering is a smoother transition between multiple offboard commands. You can check this setting by running the following PX4 console command: -```` +``` param show COM_OBL_ACT -```` +``` ## Check the Home Position If you are using DroneShell to execute commands (arm, takeoff, etc) then you should wait until the Home position is set. You will see the PX4 SITL console output this message: -```` +``` INFO [commander] home: 47.6414680, -122.1401672, 119.99 INFO [tone_alarm] home_set -```` +``` Now DroneShell 'pos' command should report this position and the commands should be accepted by PX4. If you attempt to takeoff without a home position you will see the message: -```` +``` WARN [commander] Takeoff denied, disarm and re-try -```` +``` After home position is set check the local position reported by 'pos' command : -```` +``` Local position: x=-0.0326988, y=0.00656854, z=5.48506 -```` +``` If the z coordinate is large like this then takeoff might not work as expected. Resetting the SITL and simulation should fix that problem. @@ -145,10 +145,10 @@ Notice the above setting is provided in the `params` section of the `settings.js This is required if you plan to fly the SITL mode PX4 with no remote control, just using python scripts, for example. These parameters stop the PX4 from triggering "failsafe mode on" every time a move command is finished. You can use the following PX4 command to check these values are set correctly: -```` +``` param show NAV_RCL_ACT param show NAV_DLL_ACT -```` +``` NOTE: Do `NOT` do this on a real drone as it is too dangerous to fly without these failsafe measures. diff --git a/docs/xbox_controller.md b/docs/xbox_controller.md index ee14a0ae..b164db56 100644 --- a/docs/xbox_controller.md +++ b/docs/xbox_controller.md @@ -22,9 +22,9 @@ You can also use all the QGroundControl controls for autonomous flying at this p 3. Connect to Pixhawk serial port using MavLinkTest.exe like this: -```` +``` MavLinkTest.exe -serial:*,115200 -proxy:127.0.0.1:14550 -server:127.0.0.1:14570 -```` +``` 4. Run AirSim Unreal simulator with these `~/Documents/AirSim/settings.json` settings: ```