* 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
- currently the main change is that it reduces the max number of ORB multi instances to 4, but usage will be expanded as needed
- limits number of EKF2 multi instances to 2.
- enabled on all cortex m4 boards
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
- control allocation module with multirotor, VTOL standard, and tiltrotor support
- angular_velocity_controller
- See https://github.com/PX4/PX4-Autopilot/pull/13351 for details
Co-authored-by: Silvan Fuhrer <silvan@auterion.com>
Co-authored-by: Roman Bapst <bapstroman@gmail.com>
This ensures that FMU-side power controls are not interfering with IO-side power controls of DSM receivers if they happen to be OR-ed in the schematics
VER is on BASE
REV is on FMU
ver|rev
bas|fmu
{0x0000, hw_mft_list_v0500, ...(hw_mft_list_v0500)},
{0x0001, hw_mft_list_v0501, ...(hw_mft_list_v0501)}, <-- was wrong
This falsly selected the NO I/O version
Tim
Lorenz Meier
Daniel Agar
Peter van der Perk
David Sidrane
Andrew C. Smith
dino
Jukka Laitinen
Julien Lecoeur
JacobCrabill
Beat Küng
Nicolas de Palezieux
Matthias Grob
flbernier