The limits might somewhat match the sensor, guessed based on the
original driver.
The quality is set so that spikes when sitting on the ground are not
used.
- uavcan firmware server no longer shuts down when arming (nodes might restart in flight)
- always handle UAVCAN parameters with or without the FW server active
- remove legacy ESC enumeration in FW server
- allow effectiveness matrix to select control allocator method
(desaturation algorithm)
- add actuator_servos publication
- add support for multiple matrices (for vtol)
- add updateSetpoint callback method to actuator effectiveness to allow it
to manipulate the actuator setpoint after allocation
- handle motor stopping & reversal
- add control surfaces & tilt servos
- handle standard vtol + tiltrotor
- rename MC rotors params & class to be more generically usable
- fixes and enables ActuatorEffectivenessRotorsTest
This fixes a case where the px4 startup is not stopped when the
px4 process is killled using -SIGKILL against the px4 deamon.
In that case, the currently executing command/client is killed
and properly shutting down with result -1, however, the next command
is started anyway.
This means that the next time we try to run the simulation we get a
"PX4 daemon already running for instance 0" error and PX4 doesn't start
properly.
By adding exit on error, we properly exit in the case where the startup
script gets stopped/killed.
- cmake NuttX build wrapper compile in place instead of copying source tree to build directory
- slightly faster skipping necessary copying (depending on system)
- allows debugging in place
- easier to work directly in NuttX following official documentation
- simplifies overall build which should make it easier to resolve any remaining NuttX dependency issues in the build system
- the downside is switching back and forth between different builds always require rebuilding NuttX, but I think this is worth the improved developer experience
- also no longer builds px4io and bootloader in every single build, for most users these rarely change and we're wasting a lot of build time
Remove params from airframe configs that are just set again
to the param default value or to the value that is
specified in the mc_default, fw_default or vtol_default.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
- no longer start sercon or mavlink usb by default
- on USB connection (VBUS) monitor serial USB at low rate and start Mavlink if there's a HEARTBEAT or nshterm on 3 consecutive carriage returns
- the mavlink USB instance is automatically stopped and serdis executed if USB is disconnected
- skipping Mavlink USB (and sercon) saves a considerable amount of memory on older boards
Using mixers on the IO side had a remote benefit of being able to
override all control surfaces with a radio remote on a fixed wing.
This ended up not being used that much and since the original design
10 years ago (2011) we have been able to convince ourselves that the
overall system stability is at a level where this marginal benefit,
which is not present on multicopters, is not worth the hazzle.
Co-authored-by: Beat Küng <beat-kueng@gmx.net>
Co-authored-by: Daniel Agar <daniel@agar.ca>
This avoids incremental build errors when switching between branches with
a different set of airframes.
E.g:
Aborting due to missing @type tag in file: 'Firmware/build/px4_fmu-v5_default/etc/init.d/airframes/13030_generic_vtol_quad_tiltrotor'
based on our experience with VTOL it makes sense to change the yaw mode default. You always want your VTOL to yaw in transition direction before starting the transition.
- include icm20948 on most boards by default
- create more test variants for default boards near flash limit (cuav_nora_test, cuav_x7pro_test, holybro_durandal-v1_test)
I don't think we should be broadcasting by default as we haven't done
that in the past. This suddenly spams the network with a lot of
messages, and leads to confusing situations in offices where there are
multiple PX4 SITL and QGC intances are open.
PX4 uses banks of 8 outputs as a logical structure. Boards that have
more outputs than 8 get multiple instances. This is an arbitrary choice
that helps with overall structure and enables the mixing of different
device classes (like FMU, IO or UAVCAN).
nxp_ucans32k146:Relocation for Bootloader
nxp_ucans32k146:can_boot enable CAN
nxp_ucans32k146:Save Space use Non Optimize memcpy
nxp_ucans32k146:Increase to 24K
nxp/ucans32k146:Canbootloader LED Driver
nxp_ucans32k146:Can bootloader shut down CAN
nxp_ucans32k146:Use NVMEEPROM for Paramaters
nxp_ucans32k146:Use bootloader AppDescriptor
px4 mtd:Support onchip emulated eeprom
These changes remove the two code paths to updates (forceupdate and update) and try to reboot and bootload IO independent of its state, wether it is in bootloader mode already, safety switch is off or if it is in "nominal state" (running and safety on). This ensures that there are no conditions where user error or boot sequence can prevent a successful upgrade. The only state where an upgrade will not be done is if the system is fully armed.
Previously, we did not set a remote port which meant that the default
remote port 14550 was used. This meant that the mavlink instance
talking to the gimbal was interfering with the connection to the ground
station (on 14550).
This is a hack to make sure the messages from the gimbal arrive at other
links (e.g. the ground station). It means that the gimbal does not get
flooded with all other messages that would get forwarded but messages
from the gimbal will still make it through.
* Commit for the Integration of a position controller for the a Underwater vehicle.
This module is an extension of the uuv_att_control to control an Underwater vehicle to any position, given by the SET_POSITION_TARGET_LOCAL_NED which includes x y z yaw.
Since the position control is designed for a 6DOF Robot, the roll and pitch angle are controlled to be 0.
Additionally there is a stabilization control, which holds the robot at a defined depth, and not move in any direction.
In general the idea is to have this position module to control the position of the uuv. The position module reseives the desired position of the uuv and sends appropriate attitude setpoints to the uuv_attitude_control module.
Additionally the mixer file is adapted, to include the 6 different inputs(x y z roll pitch yaw).
* Commit for the Integration of a position controller for the a Underwater vehicle.
This module is an extension of the uuv_att_control to control an Underwater vehicle to any position, given by the SET_POSITION_TARGET_LOCAL_NED which includes x y z yaw.
Since the position control is designed for a 6DOF Robot, the roll and pitch angle are controlled to be 0.
Additionally there is a stabilization control, which holds the robot at a defined depth, and not move in any direction.
In general the idea is to have this position module to control the position of the uuv. The position module receives the desired position of the uuv and sends appropriate attitude setpoints to the uuv_attitude_control module.
Additionally the mixer file is adapted, to include the 6 different inputs(x y z roll pitch yaw).
Currently not solved/missing:
- Problem with gazebo model(propeller moving chaotically).
- Mixer correct gazebo vs real life (has to be tested in the future)
- correct integration in uuv.apps (when choose which module)
- very basic controller chosen (could be improved a lot in the future)
* Remove error caused by unused variables and a different build error
* added better description of the parameter. Additionally the group is changed.
* added better description of the parameter. Additionally the group is changed.
Fixed bug about parameter
* Added EOF to the files.
* Removed parameter for direct position control for safety reasons.
* small bugfix
This commit moves the steering output from yaw to the roll channel to better reflect the lateral control input / reaction mapping. It also removes old unused parameters and modernizes the mainloop to remove unnecessary polling.
This system command will display, set and save the network
settings.
netman show - Displays the current settings.
netman update - Will check for a net.cfg file on the SD card.
If present, it will update the paramaters,
delete the file, and reboot. Using the new settings.
netman save - Saves the current settings to net.cfg on the SD card.
This file shoulf be renamed to preserver it across
reboots or editited to chech networkin paramates.
File format is name<space>value:
echo DEVICE=eth0 > /fs/microsd/net.cfg
echo BOOTPROTO=fallback >> /fs/microsd/net.cfg
echo IPADDR=192.168.0.4 >> /fs/microsd/net.cfg
echo NETMASK=255.255.255.0 >>/fs/microsd/net.cfg
echo ROUTER=192.168.0.254 >>/fs/microsd/net.cfg
echo DNS=192.168.0.254 >>/fs/microsd/net.cfg
Valid values for `proto` are `dhcp`, `static`, `falback`
Both will try dhcp for CONFIG_NETINIT_FALLBACK times
and fall back to the static address.
NETMASK - is the network mask.
IPADDR - this nodes ip address for static or fall back.
ROUTER - The default route.
DNS - The address of the dns server.
- generate PWM_MAIN 1-14
- generate PWM_AUX 1-8
- generate PWM_EXTRA 1-8
- px4io and pwm_out directly read configuration parameters
- only available and active physical outputs are actually shown for configuration
- overall saves flash despite adding many new parameters
Julian Oes
Daniel Agar
romain-chiap
Matthias Grob
Silvan Fuhrer
Beat Küng
Thomas Debrunner
Igor Mišić
Jaeyoung-Lim
bresch
mcsauder
David Sidrane
TSC21
Hyungsub
Blake McHale
Hamish Willee
echoG
achim
Yannick Fuhrer
korotkoves
Lorenz Meier
斯东Stone
Chris Lovett
Bastian Jäger
David Jablonski
Kevin Dominic Merkel
Nicolas MARTIN
Gonçalo Atanásio
garfieldG
JacobCrabill
Tim
xdwgood
JaeyoungLim
Roman Dvořák
Jakub Kákona
honglang
TheLegendaryJedi