- new heater_status logging message
- run continously at low rate until configured sensor is found
- fix px4io fd bugs (fd open/close/ioctl must be same thread)
- new IMU driver structure with state machine (no sleeps in bus thread)
- verify all configured registers and trigger reset on failure
- detect if DIO1 or DIO2 are actually connected for data ready interrupt usage
- don't use CRC-16 on burst transfers except for verified lots
* 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
- keep `vehicle_control_mode` last state in commander and use appropriate flags in place of various main_state and nav_state checks
- consolidate scattered arming requirements in `arm_disarm()`
- there were a number of different requirements from arming via RC vs Mavlink that don't make any sense
- if geofence enabled require valid home before arming
- throttle requirements for manual modes
- remove unnecessary mavlink feedback that differs between arming interfaces (mavlink vs RC)
- let the preflight/prearm checks respond directly in most cases
Co-authored-by: Matthias Grob <maetugr@gmail.com>
It is more intuitive to use the roll stick as lateral control input given that drones defined this category, plus this is how consumer car / rover radio controls have been working already.
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.
90% of all real-world vehicle configs default to this and it is something that users stumble over if they configure a new system. There are valid cases where this would not be desired - for these it can be still switched off.
- store parameter type and if volatile separately (saves kilobytes of flash)
- use Bitset for tracking active and changed parameters
- use atomic for autosave_enabled flag
- compile at ${MAX_CUSTOM_OPT_LEVEL} (-O2 on non flash constrained boards)
In case of a diverge of the nav filter, both position and velocity test
ratios are large. If only one of them is too large, the nav filter is
most likely not diverging but is encountering a GNSS position reset and
it is still safe to fly in position mode.
Daniel Agar