FAQ - Revision history

Flixr: add USB/DFU flashing entry

2016-05-01T19:57:44Z

add USB/DFU flashing entry

← Older revision		Revision as of 13:57, 1 May 2016
Line 121:		Line 121:
	:it will be effective after your next login or simply write:		:it will be effective after your next login or simply write:
	:$newgrp dialout		:$newgrp dialout

			==Can't flash autopilot==
			:If you are trying to flash your autopilot board via USB and get e.g. <tt>can't find STM32 (autopilot) device</tt>
			:'''Solution''': Check if your board is recognized by the kernel and you have sufficient rights on the device (should normally be set by [[Udev]] rules).
			:See also [[DFU#Troubleshooting]]

	==What does the name "Paparazzi" mean?==		==What does the name "Paparazzi" mean?==
	:The original name of the project reads "PaparaDzIY" (http://www.nongnu.org/paparazzi/gallery_v0.html) which might be a French abbreviation, but the meaning of that name seems to be lost. In cases where the name "Paparazzi" is ~~unfavorably~~ (i.e. for serious applications not dealing with taking unasked pictures of persons) the use of the abbreviation PPRZ can be recommended.		:The original name of the project reads "PaparaDzIY" (http://www.nongnu.org/paparazzi/gallery_v0.html) which might be a French abbreviation, but the meaning of that name seems to be lost. In cases where the name "Paparazzi" is unfavourably (i.e. for serious applications not dealing with taking unasked pictures of persons) the use of the abbreviation PPRZ can be recommended.

	[[Category:User_Documentation]]		[[Category:User_Documentation]]

Philipan: Updated information about data logging

2016-04-08T08:13:00Z

Updated information about data logging

← Older revision		Revision as of 02:13, 8 April 2016
Line 113:		Line 113:

	==Do Paparazzi autopilots support onboard datalogging with an uSD or SD card?==		==Do Paparazzi autopilots support onboard datalogging with an uSD or SD card?==
	:This depends on the board you are using. Writing to an SD card takes a considerable amount of processor resources, enough to significantly impact critical timings and autopilot performance on usual processors. For this reason, onboard datalogging is not supported on those autopilots. If logging is needed for these processors (say for use without a datalink) then a second board that "sniffs" the datalink telemetry is needed (see [[Data Logger]]). However, Recently introduced boards like the [Apogee/v1.00] using a faster processor and an on board SD card tray allow logging of flight recorder information and individual data of sensors if activated in the air frame file.		:This depends on the board you are using. Writing to an SD card takes a considerable amount of processor resources, enough to significantly impact critical timings and autopilot performance on usual processors. For this reason, onboard datalogging is not supported on those autopilots. If logging is needed for these processors (say for use without a datalink) then a second board that "sniffs" the datalink telemetry is needed (see [[Data Logger]]). However, Recently introduced boards like the [[Apogee/v1.00]] using a faster processor and an on board SD card tray allow logging of flight recorder information and individual data of sensors if activated in the air frame file.

	==Telemetry not working==		==Telemetry not working==

Philipan at 08:11, 8 April 2016

2016-04-08T08:11:31Z

← Older revision		Revision as of 02:11, 8 April 2016
Line 113:		Line 113:

	==Do Paparazzi autopilots support onboard datalogging with an uSD or SD card?==		==Do Paparazzi autopilots support onboard datalogging with an uSD or SD card?==
	:~~Currently, writing~~ to an SD card takes a considerable amount of processor resources, enough to significantly impact critical timings and autopilot performance. For this reason, no onboard datalogging is supported on ~~current~~ autopilots. If logging is needed ~~on the aircraft~~ (say for use without a datalink) then a second board that "sniffs" the datalink telemetry is needed~~. Support for this is available in Paparazzi. For information,~~ see [[Data Logger]].		:This depends on the board you are using. Writing to an SD card takes a considerable amount of processor resources, enough to significantly impact critical timings and autopilot performance on usual processors. For this reason, onboard datalogging is not supported on those autopilots. If logging is needed for these processors (say for use without a datalink) then a second board that "sniffs" the datalink telemetry is needed (see [[Data Logger]]). However, Recently introduced boards like the [Apogee/v1.00] using a faster processor and an on board SD card tray allow logging of flight recorder information and individual data of sensors if activated in the air frame file.

	==Telemetry not working==		==Telemetry not working==

Philipan: Added a question on the name Paparazzi

2016-04-08T07:59:04Z

Added a question on the name Paparazzi

← Older revision		Revision as of 01:59, 8 April 2016
Line 122:		Line 122:
	:$newgrp dialout		:$newgrp dialout

			==What does the name "Paparazzi" mean?==
			:The original name of the project reads "PaparaDzIY" (http://www.nongnu.org/paparazzi/gallery_v0.html) which might be a French abbreviation, but the meaning of that name seems to be lost. In cases where the name "Paparazzi" is unfavorably (i.e. for serious applications not dealing with taking unasked pictures of persons) the use of the abbreviation PPRZ can be recommended.

	[[Category:User_Documentation]]		[[Category:User_Documentation]]

IHaveADrone: come on guys, at least get the spelling of the project name right (misc. typos)

2015-08-13T18:13:18Z

come on guys, at least get the spelling of the project name right (misc. typos)

← Older revision		Revision as of 12:13, 13 August 2015
Line 11:		Line 11:
	: This simple script will run ''git describe'' to find the next reachable tag and print something like ''v5.1.1_testing-43-ge060371''.		: This simple script will run ''git describe'' to find the next reachable tag and print something like ''v5.1.1_testing-43-ge060371''.
	: The output contains the most recent reachable tag, number of commits since then, SHA1 of that commit and whether the working directory was dirty.		: The output contains the most recent reachable tag, number of commits since then, SHA1 of that commit and whether the working directory was dirty.
	: If you have an older version of ~~Paparazi~~ that does not contain that script you can just run <tt>git describe --match "v[0-9].[0-9]*" --dirty --always --long</tt>		: If you have an older version of Paparazzi that does not contain that script you can just run <tt>git describe --match "v[0-9].[0-9]*" --dirty --always --long</tt>

	==What equipment and components are suggested==		==What equipment and components are suggested==
Line 38:		Line 38:

	==Can I use a Sirf, Trimble, etc. instead of the u-Blox GPS receiver?==		==Can I use a Sirf, Trimble, etc. instead of the u-Blox GPS receiver?==
	:Yes, but it would require a tremendous amount of work as some of the navigation code is dependent on some of the UBX messages. NMEA does not provide messages in the desired form and substantial calculation would be required for conversion. Any of the other proprietary protocols would work but you would need to write your own protocol handler. u-Blox (~~Hobbykings~~ costs <14€) offers great performance, size, and speed as well as the ability to easily configure the internal Kalman filter parameters to expect significant acceleration in 3-D space - a very important feature.		:Yes, but it would require a tremendous amount of work as some of the navigation code is dependent on some of the UBX messages. NMEA does not provide messages in the desired form and substantial calculation would be required for conversion. Any of the other proprietary protocols would work but you would need to write your own protocol handler. u-Blox (Hobbyking's costs <14€) offers great performance, size, and speed as well as the ability to easily configure the internal Kalman filter parameters to expect significant acceleration in 3-D space - a very important feature.

	==Does Paparazzi use DGPS, WAAS, EGNOS, or MSAS?==		==Does Paparazzi use DGPS, WAAS, EGNOS, or MSAS?==
Line 67:		Line 67:
	:Any controller can be used, the exact PWM value that is sent to the controller for 0-100% throttle is completely configurable in the airframe file so all controllers are compatible and any controller will arm properly with or without the use of an R/C transmitter. Upon each boot, the autopilot immediately sends whatever you have defined as 0% throttle (typically around 1200μs) and maintains that signal until a manual or autonomous command is given. Most modern controllers are "auto calibrating" which is an undesirable feature for R/C pilots and even more so for autonomous systems but can be dealt with. The calibration is done by defining the PWM value at boot to be 0% power and then defining some initial arbitrary mid-range value such as 1500μs to be 100% until a higher value is seen. The net result of this behavior is that the motor is given full power at any command above 50% throttle until 100% throttle has actually been commanded at least once. This is not an issue for planes that routinely take off at 100% throttle but can disrupt the throttle tuning and altitude control on any flights where 100% throttle has never been commanded. [http://www.castlecreations.com/products/products_fly.html Castle Creations Electronic Speed Controllers] can be configured for "fixed endpoints" so the ESC does not need to "learn" the endpoints at first takeoff this providing a consistent and predictable throttle response. By default this range 1250-1850μs but can be set at different values where needed.		:Any controller can be used, the exact PWM value that is sent to the controller for 0-100% throttle is completely configurable in the airframe file so all controllers are compatible and any controller will arm properly with or without the use of an R/C transmitter. Upon each boot, the autopilot immediately sends whatever you have defined as 0% throttle (typically around 1200μs) and maintains that signal until a manual or autonomous command is given. Most modern controllers are "auto calibrating" which is an undesirable feature for R/C pilots and even more so for autonomous systems but can be dealt with. The calibration is done by defining the PWM value at boot to be 0% power and then defining some initial arbitrary mid-range value such as 1500μs to be 100% until a higher value is seen. The net result of this behavior is that the motor is given full power at any command above 50% throttle until 100% throttle has actually been commanded at least once. This is not an issue for planes that routinely take off at 100% throttle but can disrupt the throttle tuning and altitude control on any flights where 100% throttle has never been commanded. [http://www.castlecreations.com/products/products_fly.html Castle Creations Electronic Speed Controllers] can be configured for "fixed endpoints" so the ESC does not need to "learn" the endpoints at first takeoff this providing a consistent and predictable throttle response. By default this range 1250-1850μs but can be set at different values where needed.

	: For quadrocopters a ESc with a very low latency is highly ~~recomendet~~. That can be a cheap standard ESC with a upgraded firmware (which uses I2C as input) or a high quality esc (mocrocopter ESC)		: For quadrocopters a ESc with a very low latency is highly recommended. That can be a cheap standard ESC with a upgraded firmware (which uses I2C as input) or a high quality esc (mocrocopter ESC)

	==Can traditional throttle stick programming be done on the ESC once connected to the autopilot?==		==Can traditional throttle stick programming be done on the ESC once connected to the autopilot?==

Flixr: /* How do I check which Paparazzi Version I'm using */

2014-05-31T10:26:35Z

How do I check which Paparazzi Version I'm using

← Older revision		Revision as of 04:26, 31 May 2014
Line 9:		Line 9:
	==How do I check which Paparazzi Version I'm using==		==How do I check which Paparazzi Version I'm using==
	: Run ./paparazzi_version from you paparazzi directory.		: Run ./paparazzi_version from you paparazzi directory.
	: This simple script will run ''git describe'' to find the next reachable tag and print something like ''v3.9.~~2_testing~~-1-~~g72f4b21~~''.		: This simple script will run ''git describe'' to find the next reachable tag and print something like ''v5.1.1_testing-43-ge060371''.
	: The output contains the most recent reachable tag, number of commits since then, SHA1 of that commit and whether the working directory was dirty.		: The output contains the most recent reachable tag, number of commits since then, SHA1 of that commit and whether the working directory was dirty.
	: If you have an older version of Paparazi that does not contain that script you can just run <tt>git describe --match "v[0-9].[0-9]*" --dirty --always --long</tt>		: If you have an older version of Paparazi that does not contain that script you can just run <tt>git describe --match "v[0-9].[0-9]*" --dirty --always --long</tt>

Propcoder: Fixed PWM, PPM timing unit from ms to us.

2014-02-26T08:55:13Z

Fixed PWM, PPM timing unit from ms to us.

← Older revision		Revision as of 02:55, 26 February 2014
Line 65:		Line 65:

	==What Electronic Speed Controllers (ESC) are compatible?==		==What Electronic Speed Controllers (ESC) are compatible?==
	:Any controller can be used, the exact PWM value that is sent to the controller for 0-100% throttle is completely configurable in the airframe file so all controllers are compatible and any controller will arm properly with or without the use of an R/C transmitter. Upon each boot, the autopilot immediately sends whatever you have defined as 0% throttle (typically around ~~1200ms~~) and maintains that signal until a manual or autonomous command is given. Most modern controllers are "auto calibrating" which is an undesirable feature for R/C pilots and even more so for autonomous systems but can be dealt with. The calibration is done by defining the PWM value at boot to be 0% power and then defining some initial arbitrary mid-range value such as ~~1500ms~~ to be 100% until a higher value is seen. The net result of this behavior is that the motor is given full power at any command above 50% throttle until 100% throttle has actually been commanded at least once. This is not an issue for planes that routinely take off at 100% throttle but can disrupt the throttle tuning and altitude control on any flights where 100% throttle has never been commanded. [http://www.castlecreations.com/products/products_fly.html Castle Creations Electronic Speed Controllers] can be configured for "fixed endpoints" so the ESC does not need to "learn" the endpoints at first takeoff this providing a consistent and predictable throttle response. By default this range 1250-~~1850ms~~ but can be set at different values where needed.		:Any controller can be used, the exact PWM value that is sent to the controller for 0-100% throttle is completely configurable in the airframe file so all controllers are compatible and any controller will arm properly with or without the use of an R/C transmitter. Upon each boot, the autopilot immediately sends whatever you have defined as 0% throttle (typically around 1200μs) and maintains that signal until a manual or autonomous command is given. Most modern controllers are "auto calibrating" which is an undesirable feature for R/C pilots and even more so for autonomous systems but can be dealt with. The calibration is done by defining the PWM value at boot to be 0% power and then defining some initial arbitrary mid-range value such as 1500μs to be 100% until a higher value is seen. The net result of this behavior is that the motor is given full power at any command above 50% throttle until 100% throttle has actually been commanded at least once. This is not an issue for planes that routinely take off at 100% throttle but can disrupt the throttle tuning and altitude control on any flights where 100% throttle has never been commanded. [http://www.castlecreations.com/products/products_fly.html Castle Creations Electronic Speed Controllers] can be configured for "fixed endpoints" so the ESC does not need to "learn" the endpoints at first takeoff this providing a consistent and predictable throttle response. By default this range 1250-1850μs but can be set at different values where needed.

	: For quadrocopters a ESc with a very low latency is highly recomendet. That can be a cheap standard ESC with a upgraded firmware (which uses I2C as input) or a high quality esc (mocrocopter ESC)		: For quadrocopters a ESc with a very low latency is highly recomendet. That can be a cheap standard ESC with a upgraded firmware (which uses I2C as input) or a high quality esc (mocrocopter ESC)

NeoFromMatrix: /* Can I use a Sirf, Trimble, etc. instead of the u-Blox GPS receiver? */

2014-01-13T20:36:40Z

Can I use a Sirf, Trimble, etc. instead of the u-Blox GPS receiver?

← Older revision		Revision as of 14:36, 13 January 2014
Line 38:		Line 38:

	==Can I use a Sirf, Trimble, etc. instead of the u-Blox GPS receiver?==		==Can I use a Sirf, Trimble, etc. instead of the u-Blox GPS receiver?==
	:Yes, but it would require a tremendous amount of work as some of the navigation code is dependent on some of the UBX messages. NMEA does not provide messages in the desired form and substantial calculation would be required for conversion. Any of the other proprietary protocols would work but you would need to write your own protocol handler. u-Blox (~~starts at 20€~~) offers great performance, size, and speed as well as the ability to easily configure the internal Kalman filter parameters to expect significant acceleration in 3-D space - a very important feature~~. If you find a more capable receiver, let the group know about it, but this is not the place to save $40~~.		:Yes, but it would require a tremendous amount of work as some of the navigation code is dependent on some of the UBX messages. NMEA does not provide messages in the desired form and substantial calculation would be required for conversion. Any of the other proprietary protocols would work but you would need to write your own protocol handler. u-Blox (Hobbykings costs <14€) offers great performance, size, and speed as well as the ability to easily configure the internal Kalman filter parameters to expect significant acceleration in 3-D space - a very important feature.

	==Does Paparazzi use DGPS, WAAS, EGNOS, or MSAS?==		==Does Paparazzi use DGPS, WAAS, EGNOS, or MSAS?==

NeoFromMatrix: /* What equipment and components are suggested */

2014-01-13T20:35:16Z

What equipment and components are suggested

← Older revision		Revision as of 14:35, 13 January 2014
Line 20:		Line 20:
	# A 2.4 GHz R/C Transmitter and Receiver with a 3-position switch and PPM output for selecting Manual/Stabilized/Auto.		# A 2.4 GHz R/C Transmitter and Receiver with a 3-position switch and PPM output for selecting Manual/Stabilized/Auto.
	# A pair of [[Modems]] along with any enclosures and antennas		# A pair of [[Modems]] along with any enclosures and antennas
	# [~~http://www.mouser.com/search/ProductDetail.aspx?R=TTL-232R-3V3virtualkey62620000virtualkey626-DLP-TTL-232R-3V3 FTDI~~ USB-~~TTL~~] ~~cable~~ for connecting the modem to your USB port and/or for serial flashing of bootloader code or tunnel access to the GPS receiver		# A [[Serial_Adapter\|USB <-> UART]] adapter for connecting the modem to your USB port and/or for serial flashing of bootloader code or tunnel access to the GPS receiver
	# A standard Mini-B and Micro-B USB cable		# A standard Mini-B and Micro-B USB cable
	# Lots of [[Other_Hardware#Wiring\|very durable wire, crimpers, and molex pins or pre-crimped wire.]]		# Lots of [[Other_Hardware#Wiring\|very durable wire, crimpers, and molex pins or pre-crimped wire.]]

Openuas: /* What equipment and components are suggested */

2014-01-13T15:00:55Z

What equipment and components are suggested

← Older revision		Revision as of 09:00, 13 January 2014
Line 18:		Line 18:
	# One of the [[Autopilots]] from one of the [[Get_Hardware\|Paparazzi vendors]] or build your own from the downloadable plans/gerbers		# One of the [[Autopilots]] from one of the [[Get_Hardware\|Paparazzi vendors]] or build your own from the downloadable plans/gerbers
	# If it is not already included with the AP a external [[IMU]]		# If it is not already included with the AP a external [[IMU]]
	##2.4 GHz R/C Transmitter and Receiver with a 3-position switch and PPM output for selecting Manual/Stabilized/Auto.		# A 2.4 GHz R/C Transmitter and Receiver with a 3-position switch and PPM output for selecting Manual/Stabilized/Auto.
	##A pair of [[Modems]] along with any enclosures and antennas		# A pair of [[Modems]] along with any enclosures and antennas
	##[http://www.mouser.com/search/ProductDetail.aspx?R=TTL-232R-3V3virtualkey62620000virtualkey626-DLP-TTL-232R-3V3 FTDI USB-TTL] cable for connecting the modem to your USB port and/or for serial flashing of bootloader code or tunnel access to the GPS receiver		# [http://www.mouser.com/search/ProductDetail.aspx?R=TTL-232R-3V3virtualkey62620000virtualkey626-DLP-TTL-232R-3V3 FTDI USB-TTL] cable for connecting the modem to your USB port and/or for serial flashing of bootloader code or tunnel access to the GPS receiver
	##A standard Mini-B and Micro-B USB cable		# A standard Mini-B and Micro-B USB cable
	##Lots of [[Other_Hardware#Wiring\|very durable wire, crimpers, and molex pins or pre-crimped wire.]]		# Lots of [[Other_Hardware#Wiring\|very durable wire, crimpers, and molex pins or pre-crimped wire.]]

	==Are internal combustion engines supported?==		==Are internal combustion engines supported?==