* update uavcan hardpoint: add ability to use it via mavlink cmd and during mission and removed send_command() dedicated for usage via mavlink console
* uavcan hardpoint: allow gripper ID 0
---------
Co-authored-by: Andrew Brahim <35986980+dirksavage88@users.noreply.github.com>
Commit 5fe82aa added mutex protection in ~Mavlink() to fix a race
condition when start_helper() deleted an instance without holding the
mutex. However, this caused a deadlock because stop_command() and
destroy_all_instances() already hold mavlink_module_mutex when calling
delete, and the mutex is non-recursive.
Fix by moving instance cleanup to the callers:
- All callers now hold the mutex and remove the instance from
mavlink_module_instances BEFORE calling delete
- The destructor no longer touches mavlink_module_instances
- Event handoff remains in destructor (works because `this` is already
removed from the list when destructor runs)
This hopefully fixes the original race condition while avoiding the
deadlock that caused USB mavlink to hang on reconnect.
* Changed GZMixingInterfaceESC to GZMixingInterfaceMotor
- GZMixingInterfaceMotor checks if there are more than 8 motors configured if its less than 8 it behaves exactly the same as GZMixingInterfaceESC, else it behaves as a PWM motor interface
- This change allows drones with more than 8 motors to be simulated by Gazebo
Fixes#25080
* code quality fix
* Changed GZMixingInterfacMotor back to GZMixingInterfaceESC and changed variable names to match ESC terminology
* formatting issue resolved
* updated interface to support 16 ESCs, allowing the first 8 to report telemetry
* rebased
* moving raptor
bump
compiles and raptor mode appears
hovering with RAPTOR seems to work
Using Raptor to execute offboard commands works (using multirobot f03825a5795a77c5a095f799eeb8e0b646fe7176 to feed the trajectory_setpoint). Requires more testing
simplified rotmat
runtime inference frequency multiple
arming request response reflects actual readiness
adjusting to fit IMU gyro ratemax
relaxing control timing warning thresholds for SITL
Using mode registration to signal if offboard commands should be forwarded to trajectory_setpoint instead of just hardcoding vehicle_status.nav_state == vehicle_status_s::NAVIGATION_STATE_OFFBOARD
adopting new "request_offboard_setpoint" in raptor module
replace offboard seems good
mc_raptor: overwrite offboard parameter
separate raptor config
addendum
Raptor off by default
RAPTOR readme
Loading raptor checkpoint from tar works.
check if load was successful
refactoring: cutting out the pure C interface to allow direct testing of the policy input/output behavior from the file, without fully loading it into memory first
adapter not needed anymore
ripping out test observation mode (not used in a long time)
fixing warnings
bump RLtools to fix the remaining warnings
Loading RAPTOR checkpoint from sdcard seems to work on FMU-6C
embedding Raptor policy into flash works again
also printing checkpoint name when using the embedded policy
cleaner handling of the checkpoint name
back to reading from file
ripping out visual odometry checks
cleaner
more debug but no success
bump rlt
bump
pre next rebase
we can publish the no angvel update because we latch onto it with the scheduled work item anyways
this kind of runs on the 6c
still bad
SIH almost flying
saving stale traj setpoint yaw
new error. timestamp not the problem anymore
bump rlt; SIH works with executor
shaping up
bumping blob (include tar checkpoint)
cleaning up
fixing formatting
update readme
* moving raptor
bump
compiles and raptor mode appears
hovering with RAPTOR seems to work
Using Raptor to execute offboard commands works (using multirobot f03825a5795a77c5a095f799eeb8e0b646fe7176 to feed the trajectory_setpoint). Requires more testing
simplified rotmat
runtime inference frequency multiple
arming request response reflects actual readiness
adjusting to fit IMU gyro ratemax
relaxing control timing warning thresholds for SITL
Using mode registration to signal if offboard commands should be forwarded to trajectory_setpoint instead of just hardcoding vehicle_status.nav_state == vehicle_status_s::NAVIGATION_STATE_OFFBOARD
adopting new "request_offboard_setpoint" in raptor module
replace offboard seems good
mc_raptor: overwrite offboard parameter
separate raptor config
addendum
Raptor off by default
RAPTOR readme
Loading raptor checkpoint from tar works.
check if load was successful
refactoring: cutting out the pure C interface to allow direct testing of the policy input/output behavior from the file, without fully loading it into memory first
adapter not needed anymore
ripping out test observation mode (not used in a long time)
fixing warnings
bump RLtools to fix the remaining warnings
Loading RAPTOR checkpoint from sdcard seems to work on FMU-6C
embedding Raptor policy into flash works again
also printing checkpoint name when using the embedded policy
cleaner handling of the checkpoint name
back to reading from file
ripping out visual odometry checks
cleaner
more debug but no success
bump rlt
bump
pre next rebase
we can publish the no angvel update because we latch onto it with the scheduled work item anyways
this kind of runs on the 6c
still bad
SIH almost flying
saving stale traj setpoint yaw
new error. timestamp not the problem anymore
bump rlt; SIH works with executor
shaping up
bumping blob (include tar checkpoint)
cleaning up
fixing formatting
update readme
updating gitignore
* fixing format and declaring submodules as cmake dependencies
* adding uORB message documentation
* fixing comment alignment
* Adding option to restrict mc_raptor to not listen to the trajectory_setpoint (use the position and yaw at activation time as reference instead)
* bump RLtools; relax timing thresholds and adding real world readme
* smooth traj tracking performance
* Measuring trajectory_setpoint timing (providing stats in raptor_status); reverting accidental .gitignore modification
* More ideomatic way of setting the path to the policy checkpoint
* Reset trajectory_setpoint on raptor mode activation
* Adding internal trajectory generation (feeding trajectory_setpoint over Mavlink is too noisy). Quite agile trajectory tracking, good performance
* stable flight
* Update msg/versioned/RaptorInput.msg
Co-authored-by: Hamish Willee <hamishwillee@gmail.com>
* adopting message formatting conventions
* sort raptor.px4board
* Archiving RegisterExtComponentRequestV1.msg
* Add message versioning for VehicleStatus v2 and RegisterExtComponentRequest v2
* fixing formatting
* making internal reference configurable via command
* RAPTOR docs wip
* raptor internal reference documentation
* Finishing RAPTOR docs first draft
* adding logging instructions
* Fixing missing command documentation test error
* fixing format
* adding motor layout warning
* raptor minimal subedit - prettier, images etc
* Improve intro
* Fix up Neural_Networks version
* Mentioning "Adaptive" in the RAPTOR documentation's title
* Adding clarifications about the internal reference trajectory generator
* Removing "foundation policy" wording
* Fixing new-line check
* Removing redundant (evident through directory hierarchy) raptor_ from filenames
* Unifying Neural Network docs (mc_nn_control and mc_raptor) under the "Neural Network" topic
* Fix to standard structure
* Making the distinction between mc_nn_control and mc_raptor more clear and fixing the comparison table
* Removing trajectory_setpoint forwarding flag from external mode registration request and from the vehicle status
* Trivial layout and wording fixes
* fixing docs error
---------
Co-authored-by: Hamish Willee <hamishwillee@gmail.com>
Silvan Fuhrer