Coder Social home page Coder Social logo

px4 / px4-user_guide Goto Github PK

View Code? Open in Web Editor NEW
282.0 53.0 1.6K 594.5 MB

PX4 User Guide

Home Page: https://docs.px4.io/en/

License: Other

JavaScript 16.13% Jupyter Notebook 57.08% TeX 12.25% Vue 0.24% Python 3.01% HTML 8.93% CSS 2.37%
hacktoberfest

px4-user_guide's Introduction

PX4 User Guide

This repo contains the source code for the PX4 User Guide. The guide is intended for people who want to:

  • Add PX4-powered controllers to their drones
  • Learn how to fly and plan missions using PX4
  • Learn how to extend PX4 to support new features

Note

Contributions and Translations to this guide are very welcome!

px4-user_guide's People

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

px4-user_guide's Issues

Missing information in setup and sensor calibration procedure

Documentation for the setup and sensor calibration procedure is not providing the following information:

  • Magnetometer calibration should be done with usb disconnected and the vehicle in a flight configuration and failure to do this can result in a "mag sensors inconsistent" error. This is a particular problem with the pixracer where USB connection can produce large levels of magnetic interference.
  • Raw comparison data for all sensors can be logged by setting SDLOG_MODE = 1 and SDLOG_PROFILE = 64
  • Sensors with poor performance can be disabled using the CAL_..._EN parameter

Providing this information would help prevent user issues like this one PX4/PX4-Autopilot#8098

Doc Bug: Full Parameter Reference · PX4 User Guide · FW_PSP_OFF Description

FW_PSP_OFF description currently says:

An airframe specific offset of the pitch setpoint in degrees, the value is added to the pitch setpoint and should correspond to the typical cruise speed of the airframe.

The word "speed" might be replaced with:

"... typical cruise pitch angle (angle of attack) of the airframe."

A similar change could be made to the description of FW_RSP_OFF by replacing "speed" with "roll angle".

Bug Page: Full Parameter Reference · PX4 User Guide

Proposed flight mode docs structure and iconography

This proposal is that we simplify the structure to make it easier to navigate, and use better iconography to provide needed context when you are within the document.

Background

The current structure for Flight Modes Overview sorts flight modes by vehicle, type of mode (e.g. auto, manual). It is quite hard to read because it is so large. When you are inside the document and reading a particular flight mode it is easy to lose track of the fact that you're in MC or FW. There is also repetition of some of the grouping information (auto, manual, assisted).

My thought is that while it is useful to know there are different categories of modes and to group the modes by category, it is not necessary to have this grouping marked by a heading in the TOC.

Proposal: Improve structure:

  1. List the modes in each category in the category overview like this:
    image

  2. Remove the headings for manual, assisted, auto modes in the TOC so everything is just sorted by vehicle (but still grouped with others in same category)

    • With only one parent heading, it is much easier to know you are in MC or FW
    • There is no duplication of the information about categories.
      image

Proposal: Improve icons:

The proposal is to add a bar of icons in each of the modes. This will provide additional context in the same way that the GPS icon currently does (though we should if possible change that because it implies "GPS" and we support other position technologies).

We could have icons for:

  • Requires position
  • Requires remote control (manual or assisted) - I don't think we need an "assisted" icon.
  • Does not require remote control (Auto) - ie remote control crossed out?
  • Vehicle (e.g. MC icon indicates this is MC mode)
  • Other ?

For example:

image

@tubeme @bkueng @barzanisar - What do you think? What icons should we use?


Discussion was originally here (closed PR).

New diagrams for acrobatic mode

Hi @tubeme ,

The diagram for MC acro mode:

  • Right stick Has move left right - actually it will rotate left or right around the specified axis with a specified rotation.
  • Left stick says "climb/ascend". Again it is the same thing, a rotation up/down around the axis BUT if the vehicle is upside down it would actually be the opposite "up and down" relative to ground.

The diagram for FW acro mode is closer, though same issue with up and down being relative to the vehicle, not ground frame. In this case, spelling of "Glyde" should be "Glide".

Do you think these can be updated?

Doc on VIO/Vision systems

PX4 supports vision fusion/VIO, but this fact is not easily discoverable (there is no obvious/easy way to find out that this is supported and how to go about setting it up).

Specifically nothing "canonical" shows up in search on vision or VIO and nowhere can you find a statement about our level of support. There is information about this in the EKF doc, but it is buried, and only covers parameters, not hardware. There is also this doc for LPE that I find confusing: Using Vision or Motion Capture Systems

So the proposal is a high level doc for this topic, with the following properties:

  • Name (?): "Vision-Based/ Indoor Navigation"
  • Doc lives in PX4 User guide > Advanced Features. Should also be linked from Concepts/Features.
  • Doc covers required hardware and links to info on setup
  • Doc covers parameters to enable in both LPE and EKF2
  • Doc covers technology overview - ie what do you need to do to get what sort of accuracy/behaviour
  • Maybe small section on "up and coming features"
  • Anything else?

In addition, we'll migrate the EKF doc into the PX4 User Guide.

Multicopter PID Tuning Guide > Motor band limiting - what is lower side

Multicopter PID Tuning Guide > Motor band limiting

Where it says:
"If one of the rotors leaves this safety band, the total thrust of the system is lowered so that the relative percentage that the controller did output can be satisfied. As a result the multi rotor might not climb or lose altitude a bit, but it will never flip over. The same for lower side, even if commanded roll is large, it will be scaled to not exceed commanded summary thrust and copter will not flip on takeoff at near-zero thrust.?

What is the lower side? what is summary thrust?

@bkueng Can you suggest someone to help with this.

Document all failsafes

Fix up autopilot hardware and flightcontroller sections

  1. We need to provide users with information to make it easy for them to make a decision about what flight controller to use.

    • Currently this is Flight Controller Selection.
    • This needs a lot of work. It currently is a history less on on pixhawk, which is not particularly useful + a little on snapdragon etc.
    • Modify to be more "selection centric" and link to devguide Autopilot Hardware
  2. We may additionally need to provide more general information about different autopilot hardware.

    • Currently we have this guide section which provides an overview of the different series of autopilots. The original intention was that this would be detailed info about autopilots but that info is in the devguide (we don't want to duplicate) and actually not super useful for most users.
    • This shouldn't duplicate all the info in the devguide on this topic
    • Need to decide if this is necessary and if so, how it differs from the first section.
  3. We need to make it clear that there are other hardware that can run PX4 (e.g. crazyflie2.html, bebop).

    • Possibly need to add instructions in framebuilds for those. Not entirely appropriate since we don't actually have to build a frame - but I don't want people to miss those.

Compatible RC Systems needs info about other boards than Pixhawk

getting_started/rc_transmitter_receiver.md covers what an RC system is, and provides compatibility information for Pixhawk/PX4.

We need to clarify if the compatibility is independent of the board or not. Ie will the same receivers work on every board or will some not have the necessary ports? Similarly, even if a port is present, is there work that needs to happen in PX4 to add support on a particular board?

Doc Bug: Flying 101 · PX4 User Guide

The actual steps for takeoff, particularly in FW are not clear. So for example this says that you "use this mode" but it would be better as steps:

  1. Switch to mode XXXX
  2. Arm vehicle (usually be engaging the arming switch)
  3. What next? In MC you can switch to takeoff mode. For FW you should AFAIK just select the takeoff mode. What about for catapult or hand launch? I think you need to put into the mode then it won't actually take off until it feels acceleration due to launch detect.

Bug Page: Flying 101 · PX4 User Guide

Fix up precision land flight mode parameters

NOTE: This isn't in master yet, so I will add a big fat note on the released docs and put on hold the rest of this for now See PX4/PX4-Autopilot#8160

Precision land was merged in #98 and updated in #99. As part of that the parameters were linked to the full parameter reference. But ...

@ndepal None of the parameters mentioned appear in the parameter reference - e.g. LTEST_MODE, LTEST_SCALE_X, LTEST_SCALE_Y etc.

Can we get them added? Not only does this force proper documentation (exhaustive), but it means that all the links I just added to the reference will actually work :-0.

Actions

  • Make sure that the parameter reference for all precland parameters is generated
  • Update the precland docs to have tabular docs for the main relevant parameters (as per other flight modes)
  • Add either dedicated flight mode doc for this mode, or more likely a link in the top level flight mode docs.
  • Fix doc to make it clear that only the MarkOne beacon can be used. As per #99 (comment)

[Improvement] About centered stick and rudder control in FW Altitude mode

Hi, the descriptions below in FW Altitude modes are not easy to understand for novices.

Centered sticks (inside deadband):

Pitch input is used to control the altitude. If zero pitch input – autopilot holds current altitude against wind.
RPY sticks gives level flight.
Throttle stick controls the airspeed of the aircraft if an airspeed sensor is connected. Without an airspeed sensor the user cannot control throttle (in which case the vehicle will fly level at cruise throttle (FW_THR_CRUISE), increasing or decreasing throttle as needed to climb or descend).

Outside center:

Pitch stick controls altitude.
Throttle sets airspeed.
If roll/pitch sticks are non-zero the vehicle does a coordinated turn (manual yaw input is added to rudder control input to control sideslip).

  1. In 'Centered sticks' paragraph, although the paragraph is about 'centered' sticks but the content describes the variation of sticks (not centered). So it is ambiguous to novices for exact meaning.

  2. In the last sentence above description, it is not sure to novice that the rudder control is basically automatically calculated by the coordinated turn or not. If it is yes, it'd rather specify such as that the rudder control input is calculated automatically by coordinated turn and additionally manual yaw stick input is added to it.

  3. The sentence "RPY sticks gives level flight" is ambiguous.

Bug Page: Altitude (FW) · PX4 User Guide

Add Snapdragon build log

We have build log from test team, but need to confirm whether there are better sets of information to post. Question is with Mark Charlebois

Need VTOL Config for Tiltrotor and Tailsitter

We have /en/config/vtol_quad_configuration.html which describes how you tune and configure a quadplane. We need to have similar (or extend this) so that it covers tuning/parameters for the other forms of VTOL vehicle.

Doc Bug: Flight Modes · PX4 User Guide

Flight Mode Overview > Manual/Stabilized mode - @tubeme the image isn't quite right.

  1. On right, text "Level Flight / Stabilized" - "Stabilized" is miss-spelled in image.
  2. The left stick is labeled rate controlled. But actually only the yaw input is rate controlled, not the throttle.

IMO for this case having the text label "Angle" and "Rate controlled" isn't useful because it won't mean anything to most users. You and I know that angle implies that the vehicle will move left/right or forward/back at a constant speed for the current throttle, but not a new user.

UPdate relevant docs on how to find out if a serial port is being used

From #111 (comment)

A way to check if serial port is in use is run:

mavlink status

in the nuttx terminal and check what is the port of every stream.

This would be useful to add in ulanding and leddarone docs above where we say "If you are connecting the radar device to TELEM2 then make sure to set the parameter SYS_COMPANION to 0. ..." as a more general way to work out if there is an issue with using a port.

However there may be other places where this would be useful, so do a review. E.g. debugging, any other rangefinder that uses ports.

Multicopter PID Tuning Guide review

Hello,

I'm trying to understand the Multicopter PID Tuning Guide and I have some questions:

"Set all MC_XXX_P to zero (ROLL, PITCH, YAW)" if these parameters do what they advertise, I don't understand how this will work since they will output 0.
"The gains actually have an intuitive meaning, e.g.: if the MC_ROLL_P gain is 6.0, the copter will try to compensate 0.5 radian offset in attitude (~30 degrees) with 6 times the angular speed, i.e. 3 radians/s or ~170 degrees/s." working this example and replacing 6 with 0, it will output 0 degrees/s.

"Keep the multi rotor in your hand and increase the thrust to about 50%, so that the weight is virtually zero. "
In which mode? Manual Stabilized?

I Gain Tuning
If the roll and pitch rates never reach the setpoint but have an offset, add MC_ROLLRATE_I and MC_PITCHRATE_I gains, starting at 5-10% of the MC_ROLLRATE_P gain value.

How can I see the roll and pitch rates? what about setpoint? Are we still in the situation where I keep the drone in my hand, titled, with 50% throttle ?

Feed Forward Tuning
Typical value is 0.8…0.9. (For aerial video optimal value may be much smaller to get smooth response.)

If typical value is 0.8 - 0.8, why the default is 0.5 ?

@hamishwillee @dagar

Thanks,
Nicolae

[For improve] Procedure Clarification - Doc Bug: Airspeed · PX4 User Guide

Hi, Thanks for User Guide.

The airspeed calibration procedure need more clarification of meaning for novices to do it.
Following is my question during my calibration failures:

  1. Cover the sensor (i.e. with your hand). --> For what? To protect wind from the sensor?
  2. Blow across the sensor. --> By mouth?, or some blowing device is needed?
    As the 'Create air pressure!' is displayed, how many times should we blow by mouth?
    And how much is the separation distance form the tip to mouth in side? 1 cm is enough?

Bug Page: Airspeed · PX4 User Guide

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.