Replace flight controller with autopilot

shiv-tyagi · Feb 22, 2023 · cde5209 · cde5209
1 parent 1005702
commit cde5209
Show file tree

Hide file tree

Showing 81 changed files with 136 additions and 136 deletions.
diff --git a/common/source/docs/common-3dr-radio-v1.rst b/common/source/docs/common-3dr-radio-v1.rst
@@ -67,7 +67,7 @@ This is not usually required, but if desired see: :ref:`common-configuring-a-tel
 Updating the Firmware
 ---------------------
 
-Using Mission Planner, with the module connected to the flight controller for power and the base USB unit plugged into the computer:
+Using Mission Planner, with the module connected to the autopilot for power and the base USB unit plugged into the computer:
 
 - determine the USB COMM port the base radio is using and enter that into the port selection box of Mission Planner along with the baud rate (57600 is defualt for the radios).
 - WITHOUT connecting anything in Mission Planner, use the SETUP/Optional Hardware/Sik Radio utility tab to "Upload Firmware (local)" which will download the latest firmware and write it to the radios.

diff --git a/common/source/docs/common-accelerometer-calibration.rst b/common/source/docs/common-accelerometer-calibration.rst
@@ -45,7 +45,7 @@ Calibration steps
    -  You should calibrate the board mounted in the vehicle if possible. 
    -  However, you may need to calibrate the board before it is mounted if the size/shape of the vehicle makes this difficult.
    -  The level position is the most important to get right as this will be the attitude that your controller considers level while flying.
-   -  You can recalibrate this Level position using Mission Planner after you have installed the flight controller and are ready to fly. Place the vehicle in its level flying attitude and use the **Calibrate Level** button.
+   -  You can recalibrate this Level position using Mission Planner after you have installed the autopilot and are ready to fly. Place the vehicle in its level flying attitude and use the **Calibrate Level** button.
 
 .. note:: this **Calibrate Level** operation can only correct up to a 10 degree difference between the initial calibration and the final position in the vehicle, and only corrects pitch and roll differences, not yaw.
 

diff --git a/common/source/docs/common-airvolute-DroneCore-Suite.rst b/common/source/docs/common-airvolute-DroneCore-Suite.rst
@@ -15,7 +15,7 @@ It consists of a control part called **DroneCore.Pilot** and power part called *
 **DroneCore.Pilot** - top board for control of the aircraft containing
 
 -  **Jetson Xavier NX** Companion Computer
--  CubePilot Cube flight controller running ArduPilot firmware
+-  CubePilot Cube autopilot running ArduPilot firmware
 -  Internal 5V power supply
 -  Power selector
 -  Peripheral connectors
@@ -44,7 +44,7 @@ Various software libraries (coming soon) further enrich the possibilities for th
 
 DroneCore.Suite provides easy to use ROS based software stack supporting development of autonomous applications.
 
-Out of the box the device is configured to fly a Quadcopter (though flight controller calibration is needed).
+Out of the box the device is configured to fly a Quadcopter (though autopilot calibration is needed).
 
 
 .. image:: ../../../images/airvolute_droneCore.Suite_top_view_9219.jpg
@@ -111,9 +111,9 @@ Block Diagram
     :target: ../../_images/airvolute_DroneCore.Pilot_block_diagram.svg
 
 
-**DroneCore.Pilot** is based on Cube Orange - the widely used flight controller by Hex.aero running on ArduPilot (or optionally PX4 flight stack) and Nvidia Jetson Xavier NX. Their rich interfaces allow connecting most sensors and other peripherals for drones available on the market.
+**DroneCore.Pilot** is based on Cube Orange - the widely used autopilot by Hex.aero running on ArduPilot (or optionally PX4 flight stack) and Nvidia Jetson Xavier NX. Their rich interfaces allow connecting most sensors and other peripherals for drones available on the market.
 
-**DroneCore.Power** contains 4 FOC DroneCAN ESCs with motor identification feature able to be configured for all common BLDC/PMSM drone motors on the market and a telemetry interface providing real time data to the flight controller. Furthermore it provides battery voltage and current measurements as well as individual cell voltages.
+**DroneCore.Power** contains 4 FOC DroneCAN ESCs with motor identification feature able to be configured for all common BLDC/PMSM drone motors on the market and a telemetry interface providing real time data to the autopilot. Furthermore it provides battery voltage and current measurements as well as individual cell voltages.
 
 Useful links
 ============

diff --git a/common/source/docs/common-ap-periph-usage-examples.rst b/common/source/docs/common-ap-periph-usage-examples.rst
@@ -78,9 +78,9 @@ On the CAN node you need to set:
 - :ref:`OUTx_FUNCTION <dev:OUT1_FUNCTION>` to a value of 50 plus the servo number for each output you want to be enabled as PWM output
 - :ref:`OUTx_FUNCTION <dev:OUT1_FUNCTION>` = 0 for any outputs you do not have connected. Do not leave them at the default of 33 + ESC number
 
-For example, if you had an elevator servo on SERVO2 on the main autopilot and you want this to appear on the first output of the CAN node (on the node's pin marked “1”) then you would set OUT1_FUNCTION = 52 (that is 50 + the servo number on the flight controller). If you wanted a rudder that is on SERVO4 to appear on output 4 then you would set OUT4_FUNCTION=54.
+For example, if you had an elevator servo on SERVO2 on the main autopilot and you want this to appear on the first output of the CAN node (on the node's pin marked “1”) then you would set OUT1_FUNCTION = 52 (that is 50 + the servo number on the autopilot). If you wanted a rudder that is on SERVO4 to appear on output 4 then you would set OUT4_FUNCTION=54.
 
-.. note:: It is also recommended to set OUTn_MIN to 1000, OUTn_MAX to 2000, and OUTn_TRIM to 1500. That will allow you to use the SERVOn_MIN, SERVOn_MAX, and SERVOn_TRIM values on the main autopilot to control the outputs range and center in the usual way. It is possible to use other values on the node, but it gets more complicated to understand the mapping of the PWM values, so using 1000, 1500, 2000 is recommended. Doing this also means the PWM value in your flight controller logs matches what is output by the node.
+.. note:: It is also recommended to set OUTn_MIN to 1000, OUTn_MAX to 2000, and OUTn_TRIM to 1500. That will allow you to use the SERVOn_MIN, SERVOn_MAX, and SERVOn_TRIM values on the main autopilot to control the outputs range and center in the usual way. It is possible to use other values on the node, but it gets more complicated to understand the mapping of the PWM values, so using 1000, 1500, 2000 is recommended. Doing this also means the PWM value in your autopilot logs matches what is output by the node.
 
 Combining DShot and PWM outputs
 -------------------------------

diff --git a/common/source/docs/common-basic-operation.rst b/common/source/docs/common-basic-operation.rst
@@ -4,7 +4,7 @@
 Simple Overview of ArduPilot Operation
 ======================================
 
-This is a very basic overview of the functions of ArduPilot firmware running on a autopilot. Shown below is a simple block diagram of the basic functional operation. This will give you a better understanding of ArduPilot basic functions as you configure your system.
+This is a very basic overview of the functions of ArduPilot firmware running on an autopilot. Shown below is a simple block diagram of the basic functional operation. This will give you a better understanding of ArduPilot basic functions as you configure your system.
 
 .. image:: ../../../images/block-diagram.jpg
     :target: ../_images/block-diagram.jpg

diff --git a/common/source/docs/common-blheli32-passthru.rst b/common/source/docs/common-blheli32-passthru.rst
@@ -154,6 +154,6 @@ First ensure that you have an appropriate version of BLHeli32 or BLHeli_S instal
 
 Set the following parameters to enable BLHeli32 and BLHeli_S bi-directional DShot:
 
-- :ref:`SERVO_BLH_BDMASK <SERVO_BLH_BDMASK>`: a bitmap used to enable BLHeli32 or BLHeli_S bi-directional DShot support. On flight controllers without IOMCU this would normally be set to 15 to indicate four active channels. On flight controllers with an IOMCU this can be set to 3840 to indicate four active AUX channels (bi-directional DShot will only work on the AUX outputs).
+- :ref:`SERVO_BLH_BDMASK <SERVO_BLH_BDMASK>`: a bitmap used to enable BLHeli32 or BLHeli_S bi-directional DShot support. On autopilots without IOMCU this would normally be set to 15 to indicate four active channels. On autopilots with an IOMCU this can be set to 3840 to indicate four active AUX channels (bi-directional DShot will only work on the AUX outputs).
 
 - :ref:`SERVO_BLH_POLES <SERVO_BLH_POLES>` defaults to 14 which applies to the majority of brushless motors and normally does not need to be changed. Adjust as required if you're using motors with a pole count other than 14 to calculate true motor shaft RPM from ESC's e-field RPM (small motors might have 12 poles).
diff --git a/common/source/docs/common-camera-runcam.rst b/common/source/docs/common-camera-runcam.rst
@@ -40,7 +40,7 @@ Setup
 
   When the camera is connected correctly and the serial port configured correctly you will see a message similar to the following at boot: ``APM: RunCam initialized, features 0x0077, 2-key OSD`` otherwise you will see ``APM: RunCam device not found``.
 
-  The camera must be powered and fully booted in order to accept commands. This can take some time and the delay between the flight controller booting and the camera being probed can be controlled through :ref:`CAM_RC_BT_DELAY <CAM_RC_BT_DELAY>`. The camera will be probed repeatedly until :ref:`CAM_RC_BT_DELAY <CAM_RC_BT_DELAY>` elapses, but once that has expired the camera will not be probed again.
+  The camera must be powered and fully booted in order to accept commands. This can take some time and the delay between the autopilot booting and the camera being probed can be controlled through :ref:`CAM_RC_BT_DELAY <CAM_RC_BT_DELAY>`. The camera will be probed repeatedly until :ref:`CAM_RC_BT_DELAY <CAM_RC_BT_DELAY>` elapses, but once that has expired the camera will not be probed again.
 
 * Some split-style cameras support three modes - video standby, video start and picture mode. It is not possible to tell from the RunCam device protocol whether this is the type of camera in use and so this must be configured. Set :ref:`CAM_RC_TYPE <CAM_RC_TYPE>` = 2. Most other cameras should be fine with the default, however some of the later cameras have a bug where video start/stop protocol commands are not properly supported and a workaround has to be used. Cameras known to have this problem are the RunCam Split4k and require setting :ref:`CAM_RC_TYPE <CAM_RC_TYPE>` = 3. In addition to this problem RunCam Hybrid cameras have a QR code mode which can also cause problems for recording control. For RunCam Hybrids set :ref:`CAM_RC_TYPE <CAM_RC_TYPE>` = 4. Note that RunCam are bringing out new cameras all the time and seem to change the video controls with almost every camera, so if you are having issues - particularly with video control - try one of the other camera types for :ref:`CAM_RC_TYPE <CAM_RC_TYPE>`.
 
@@ -67,4 +67,4 @@ Split-style cameras differ significantly from regular RunCams in terms of what g
 OSD Menu and OSD Interaction
 ============================
 
-One of the features of the ArduPilot implementation of OSD menu control is that the flight controller will switch off the regular flight OSD when the camera OSD is entered. It will also prevent arming whilst in OSD mode. When the OSD menu is exited the regular flight OSD will be re-enabled and arming allowed.
+One of the features of the ArduPilot implementation of OSD menu control is that the autopilot will switch off the regular flight OSD when the camera OSD is entered. It will also prevent arming whilst in OSD mode. When the OSD menu is exited the regular flight OSD will be re-enabled and arming allowed.
diff --git a/common/source/docs/common-connecting-sport-fport.rst b/common/source/docs/common-connecting-sport-fport.rst
@@ -56,7 +56,7 @@ ______________________________________________________________________
 
 .. note:: F7/H7 boards can have the FPort connected to the UARTs RX pin, instead of the TX pin as shown above, and use the UART's SWAP option. F4 boards do not have this SWAP capability See :ref:`common-Fport-receivers` for more information.
 
-.. note::  some autopilots, like the Cube Orange flight controller, have level shifters on their UART pins used on their Telemetry ports. This requires a 10K pulldown resistor externally on the receiver's SPort signal to work properly. 
+.. note::  some autopilots, like the Cube Orange autopilot, have level shifters on their UART pins used on their Telemetry ports. This requires a 10K pulldown resistor externally on the receiver's SPort signal to work properly. 
 
 .. _frsky_cables:
 

diff --git a/common/source/docs/common-cuav-c-rtk2.rst b/common/source/docs/common-cuav-c-rtk2.rst
@@ -18,7 +18,7 @@ Other characteristics
 - Multi-satellite and multi-frequency receivers
 - UAVCAN/Dronecan protocol
 - Supports camera hotshoe and shutter trigger
-- Compatible with ArduPilot/PX4 flight controller software, and using a CUAV X7 series flight controller, it is plug and play.
+- Compatible with ArduPilot/PX4 autopilot software, and using a CUAV X7 series autopilot, it is plug and play.
 - HS_USB C and micro-SD disk interfaces
 
 Key Features
@@ -69,7 +69,7 @@ Key Features
 - Anti-jamming
    - Active CW detection and removal Onboard band pass ﬂter
 - Support flight control type
-   -  Compatible with flight controllers running ArduPilot/PX4 firmware
+   -  Compatible with autopilots running ArduPilot/PX4 firmware
 - Interfaces
    - 1 Hotshoe
    - 1 Shutter in

diff --git a/common/source/docs/common-cuav-neo-3-pro.rst b/common/source/docs/common-cuav-neo-3-pro.rst
@@ -4,7 +4,7 @@
 NEO 3 Pro GPS
 =============
 
-NEO 3 pro is DroneCAN standard GPS developed by CUAV. It integrates industrial-grade compass, barometer, flight controller status light, buzzer, and safety switch all in one package. It has the characteristics of high safety and strong interference resistance.It integrates ublox m9n module and can receive signals from GPS, Galileo, GLONASS and Beidou at the same time.
+NEO 3 pro is DroneCAN standard GPS developed by CUAV. It integrates industrial-grade compass, barometer, autopilot status light, buzzer, and safety switch all in one package. It has the characteristics of high safety and strong interference resistance.It integrates ublox m9n module and can receive signals from GPS, Galileo, GLONASS and Beidou at the same time.
 
 .. image:: ../../../images/cuav-gnss/neo-3-pro.jpg
 	:target: ../_images/neo-3-pro.jpg
@@ -99,7 +99,7 @@ Connect to CUAV v5+
 
 .. note::
 
-    The connection to other flight controllers is similar.
+    The connection to other autopilots is similar.
 
 Enable CAN port, DroneCAN, and Configure for NEO-V2 Pro
 =======================================================
@@ -129,31 +129,31 @@ If you need to set up NEO 3 pro or upgrade its firmware, you need to enable SLCA
 
     ArduPilot 4.0 or later firmware supports SLCAN.
 
-- Please connect NEO 3 pro to the flight controller's CAN1 interface.
-- Open mission planner and connect flight controller.
+- Please connect NEO 3 pro to the autopilot's CAN1 interface.
+- Open mission planner and connect autopilot.
 
 Modify the following parameters in the Full Parameter tab of Mission Planner.
 
 **for CUAV V5+/nano:**
 
 - :ref:`CAN_SLCAN_CPORT<CAN_SLCAN_CPORT>` set to 1
 - :ref:`SERIAL7_PROTOCOL<SERIAL7_PROTOCOL>`  set to 22
-- Reboot flight controller
+- Reboot autopilot
 
 .. note::
 
-   CUAVV5 / NANO / FMUV5 flight controller running ArduPilot4.0 or later firmware will have two USB interfaces, one is flight controller's console port (SERIAL0) running MAVLINK  and one is an SLCAN interface port; if there are not two ports showing in the Mission Planner Comm Port drop-down box, please uninstall the driver and reinstall. If you continue to have problems, see :ref:`troubleshooting-composite-connections` 
+   CUAVV5 / NANO / FMUV5 autopilot running ArduPilot4.0 or later firmware will have two USB interfaces, one is autopilot's console port (SERIAL0) running MAVLINK  and one is an SLCAN interface port; if there are not two ports showing in the Mission Planner Comm Port drop-down box, please uninstall the driver and reinstall. If you continue to have problems, see :ref:`troubleshooting-composite-connections` 
 
 **For Pixhawk series / FMUv2 / FMU V3 / FMU V4**
 
 - :ref:`CAN_SLCAN_CPORT<CAN_SLCAN_CPORT>` Set to 1
 - :ref:`CAN_SLCAN_TIMOUT<CAN_SLCAN_TIMOUT>` Set to 0 (no timeout, reboot to return to normal operation)
 - :ref:`CAN_SLCAN_SERNUM<CAN_SLCAN_SERNUM>` Set to 0
-- Please do not reboot the flight controller until your operation is complete.
+- Please do not reboot the autopilot until your operation is complete.
 
 .. note::
 
-    STM32F4 does not support dual virtual USB ports, so  flight controllers using STM32F4 processor can only be used for SLCAN after the MAVLink connection on USB is closed; after writing the above settings, the USB interface becomes an SCLAN port; MAVLink connections can be made again after a reboot. Until then the USB connection can be used for SLCAN operations.
+    STM32F4 does not support dual virtual USB ports, so  autopilots using STM32F4 processor can only be used for SLCAN after the MAVLink connection on USB is closed; after writing the above settings, the USB interface becomes an SCLAN port; MAVLink connections can be made again after a reboot. Until then the USB connection can be used for SLCAN operations.
 
 NEO-V2 Internal Configuration
 =============================

diff --git a/common/source/docs/common-cuav-neo-3.rst b/common/source/docs/common-cuav-neo-3.rst
@@ -4,7 +4,7 @@
 NEO 3  GPS
 ==========
 
-Neo 3 is a UAV positioning module developed by  CUAV. It integrates industrial-grade compass, barometer, flight controller status light, buzzer, and safety switch all in one package. It has the characteristics of high safety and strong interference resistance.It integrates ublox m9n module and can receive signals from GPS, Galileo, GLONASS and Beidou at the same time.
+Neo 3 is a UAV positioning module developed by  CUAV. It integrates industrial-grade compass, barometer, autopilot status light, buzzer, and safety switch all in one package. It has the characteristics of high safety and strong interference resistance.It integrates ublox m9n module and can receive signals from GPS, Galileo, GLONASS and Beidou at the same time.
 
 .. image:: ../../../images/cuav-gnss/neo-3.jpg
 	:target: ../_images/neo-3.jpg
@@ -98,7 +98,7 @@ Connect to CUAV v5+
 
 .. note::
 
-    The connection to other flight controllers is similar.
+    The connection to other autopilots is similar.
 
 Pinouts
 =======