- As it is always only used for the vehicle command ack message
- It was a duplicate, hence making it error prone for maintainment
- The uORB message comments were updated to make the relationship with
the MAVLink message / enum definitions clear
- all sources of optical flow publish sensor_optical_flow
- sensor_optical_flow is aggregated by the sensors module, aligned with integrated gyro, and published as vehicle_optical_flow
Co-authored-by: alexklimaj <alex@arkelectron.com>
Follow me : tidied second order filter implementation
Added velocity filtered info to uORB follow target status message, and rebase to potaito/new-follow-me-task
FollowMe : Rebasing and missing definition fixes on target position second order filter
Follow Me : Remove Alpha filter delay compensation code, since second order filter is used for pose filtering now
Followme : Remove unused target pose estimation update function
Follow Target : Added Target orientation estimation logic
Follow Target : Replaced offset vector based setpoint to rate controlled orbital angle control
Follow Target : Bug fixes and first working version of rate based control logic, still buggy
Follow Target : Added target orientation, follow angle, orbit angle value into follow_target_status uORB message for debugging
Follow Target : Fix orbit angle step calculation typo bug
Follow Target : Few more fixes
Follow Target : Few fixes and follow angle value logging bug fix
Follow Target : Added lowpass alpha filter for yaw setpoint filtering
Follow Target : Remove unused filter delay compensation param
Follow Target : Add Yaw setpoint filter initialization logic and bufix for when unwrap had an input of NAN angle value
Follow Target : Add Yaw setpoint filtering enabler parameter
Follow Target : Change Target Velocity Deadzone to 1.0 m/s, to accomodate walking speed of 1.5 m/s
Follow Target : Add Orbit Tangential Velocity calculation for velocity setpoint and logging uORB topics
Follow target : Fix indentation in yaw setpoint filtering logic
Follow Target : Fix Follow Target Estimator timeout logic bug that was making the 2nd order pose filter reset to raw value every loop
Follow Target : Remove debug printf statement for target pose filter reset check
Follow Target : Add pose filter natural frequency parameter for filter testing
Follow Target : Make target following side param selectable and add target pose filter natural frequency param description
Follow Target : Add Terrain following altitude mode and make 2D altitude mode keep altitude relative to the home position, instead of raw local position origin
Follow Target : Log follow target estimator & status at full rate for filter characteristics test
Follow Target : Implementing RC control user input for Follow Target control
Follow Target : edit to conform to updated unwrap_pi function
Follow Target : Make follow angle, distance and height RC command input configurable
Follow Target : Make Follow Target not interruptable by moving joystick in Commander
Follow Target : reconfigure yaw, pitch and roll for better user experience in RC adjusting configurations, and add angular rate limit taking target distance into account
Follow Target : Change RC channels used for adjustments and re-order header file for clarity
Follow Target : Fix Parameters custom parent macro, since using DEFINE_PARAMETERS alone misses the parameter updates of the parent class, FlightTask
Follow Target : Fix Orbit Tangential speed actually being angular rate bug, which was causing a phenomenon of drnoe getting 'dragged' towards the target velocity direction
Follow Target : Final tidying and refactoring for master merge - step 1
Add more comments on header file
Follow Target : tidy, remove unnecessary debug uORB elements from follow_target_status message
Follow Target : Turn off Yaw filtering by default
Follow Target : Tidy maximum orbital velocity calculation
Follow Target : add yaw setpoint filter time constant parameter for testing and fix NAV_FT_HT title
Follow Target : Add RC adjustment window logic to prevent drone not catching up the change of follow target parameters
Follow Target : fixes
Follow Target: PR tidy few edits remove, and update comments
Follow Target : apply comments and reviews
Follow Target : Edit according to review comments part 2
Follow Target : Split RC adjustment code and other refactors
- Splitted the RC adjustment into follow angle, height and distance
- Added Parameter change detection to reset the follow properties
- Added comments and removed yaw setpoint filter enabler logic
Follow Target : Modify orbit angle error bufferzone bug that was causing excessive velocity setpoints when setpoint catched up with raw orbit setpoint
Follow Target : Remove buffer zone velocity ramp down logic and add acceleration and rate limited Trajectory generation library for orbit angle and velocity setpoint
Follow Target : Remove internally tracked data from local scope function's parameters to simplify code
Follow Target : Fix to track unwrapped orbit angle, with no wrapping
Follow Target : Apply user adjustment deadzone to reduce sensitivity
Follow Target : Apply suggestions from PR review round 2 by @potaito
Revert submodule update changes, fall back to potaito/new-followme-task
Follow Target : [Debug] Expose max vel and acceleration settings as parameters, instead of using Multicopter Position Controller
's settings
Follow Target : Use matrix::isEqualF() function to compare floats
Follow Target : Add Acceleration feedback enabler parameter and Velocity ramp in initial commit for overshoot phenomenon improvement
Follow Target : Implement Velocity feed forward limit and debug logging values
Follow Target : Apply Velocity Ramp-in for Acceleration as well & Apply it to total velocity setpoint and not just orbit tangential velocity component
Follow Target : Don't set Acceleration setpoint if not commanded
Follow Target : Use Jerk limited orbit angle control. Add orbit angle tracking related uORB values"
Follow Target : Add Orbit Angle Setpoint Rate Tracking filter, to take into consideration for calculating velocity setpoint for trajectory generator for orbit angle
Revert "Follow Target : Add Orbit Angle Setpoint Rate Tracking filter, to take into consideration for calculating velocity setpoint for trajectory generator for orbit angle"
This reverts commit a3f48ac7652adb70baf3a2fed3ea34d77cbd6a70.
Follow Target : Take Unfiltered target velocity into acount for target course calculation to fix overshoot orbit angle 180 deg flip problem
Follow Target : Remove Yaw Filter since it doesn't make a big difference in yaw jitterness
Follow Target : Remove velocity ramp in control & remove debug values from follow_target_status.msg
Follow Target : Tidy Follow Target Status message logging code
Follow Target : Remove jerk and acceleration settings from Follow Target orbit trajectory generation
Follow Target : Change PublicationMulti into Publication, since topics published are single instances
Follow Target : Edit comments to reflect changes in the final revision of Follow Target
Follow Target : Apply incorrectly merged conflicts during rebase & update Sticks function usage for getThrottled()
Follow Target : Apply final review comments before merge into Alessandro's PR
Apply further changes from the PR review, like units
Use RC Sticks' Expo() function for user adjustments to decrease sensitivity around the center (0 value)
Update Function styles to lowerCamelCase
And make functions const & return the params, rather than modifying them
internally via pointer / reference
Specify kFollowPerspective enum as uint8_t, so that it can't be set to negative value when converted from the parameter 'FLW_TGT_FP'
Fix bug in updateParams() to reset internally tracked params if they actually changed.
Remove unnecessary comments
Fix format of the Follow Target code
Fix Follow Perspective Param metadata
follow-me: use new trajectory_setpoint msg
Convert FollowPerspective enum into a Follow Angle float value
1. Increases flexibility in user's side, to set any arbitrary follow
angle [deg]
2. Removes the need to have a dedicated Enum, which can be a hassle to
make it match MAVSDK's side
3. A step in the direction of adding a proper Follow Mode (Perspective)
mode support, where we can support kite mode (drone behaves as if it is
hovering & getting dragged by the target with a leash) or a constant
orbit angle mode (Drone always on the East / North / etc. side, for
cinematic shots)
Continue fixing Follow Target MAVSDK code to match MAVSDK changes
- Support Follow Angle configuration instead of Follow Direction
- Change follow position tolerance logic to use the follow angle
*Still work in progress!
Update Follow Me MAVSDK Test Code to match MAVSDK v2 spec
- Add RC Adjustment Test case
- Change follow direction logic to follow angle based logic completely
- Cleanup on variable names and comment on code
follow-me: disable SITL test
Need to update MAVSDK with the following PR:
https://github.com/mavlink/MAVSDK/pull/1770
SITL is failing now because the follow-me
perspectives are no longer defined the
same way in MAVSDK and in the flight task.
update copyright year
follow-me: mark uORB topics optional
Apply review comments
more copyright years
follow-me sitl test: simpler "state machine"
flight_mode_manager: exclude AutoFollowTarget and Orbit on flash contrained boards
Remove unnecessary follow_target_status message properties
- As it eats up FLASH and consumes uLog bandwidth
rename follow_me_status to follow_target_status
enable follow_target_estimator on skynode
implement the responsiveness parameter:
The responsiveness parameter should behave similarly to the previous
follow-me implementation in navigator. The difference here is that
there are now two separate gains for position and velocity fusion.
The previous implemenation in navigator had no velocity fusion.
Allow follow-me to be flown without RC
SITL tests for follow-me flight task
This includes:
- Testing the setting for the follow-me angle
- Testing that streaming position only or position
and velocity measurements both work
- Testing that RC override works
Most of these tests are done with a simulated model
of a point object that moves on a straight line. So
nothing too spectacular. But it makes the test checks
much easier.
Since the estimator for the target actually checks new
measurements and compares them to old ones, I also added
random gausian noise to the measurements with a fixed seed
for deterministic randomness. So repeated runs produce
exactly the same results over and over.
Half of the angles are still missing in MAVSDK. Need to create
an upstream PR to add center left/right and rear left/right options.
These and the corresponding SITL tests need to be implemented
later.
sitl: Increase position tolerance during follow-me
Astro seems to barely exceed the current tolerance (4.3 !< 4.0)
causing CI to fail. The point of the CI test is not to check
the accuracy of the flight behaviour, but only the fact that the
drone is doing the expected thing. So the exact value of this
tolerance is not really important.
follow-me: gimbal control in follow-me
follow-me: create sub-routines in flight task class
follow-me: use ground-dist for emergency ascent
dist_bottom is only defined when a ground facing distance sensor exist.
It's therefore better to use dist_ground instead, which has the distance
to the home altitude if no distance sensor is available.
As a consequence it will only be possible to use follow-me in a valley
when the drone has a distance sensor.
follow-me: point gimbal to the ground in 2D mode
follow-me: another fuzzy msg handling for the estimator
follow-me: bugfix in acceleration saturation limit
follow-me: parameter for filter delay compensation
mantis: dont use flow for terrain estimation
follow-me: default responsiveness 0.5 -> 0.1
0.5 is way too jerky in real and simulated tests.
flight_task: clarify comments for bottom distance
follow-me: minor comment improvement
follow-me: [debug] log emergency_ascent
follow-me: [debug] log gimbal pitch
follow-me: [debug] status values for follow-me estimator
follow-me: setting for gimbal tracking mode
follow-me: release gimbal control at destruction
mavsdk: cosmetics 💄
1. Rename *_header_s structs to *_s, since the _header postfix is not
helpful
2. Rename the "key" string variables in the message structs to
"key_value_str" as the string actually contains not just the key but the
key and value pair information
3. Add comments on other uLog messages to clarify use (need more
improvement / can be even more simplified)
Normally _should_run for mission is only ever true if _should_run for the
normal log is. There are exceptions though:
- the log buffer fails to allocate
- there was a write failure (e.g. due to SD card removal)
In that situation, the writer would not wait anymore but busy-loop.
There was a time window where if a task with higher priority than the main
logger thread would busy-loop, it would block both logging threads and the
watchdog would not trigger if the writer was in idle state.
This can happen for fast SD card writes.
It accesses kernel internal structures directly; this needs to be
worked out with some proper userspace-kernel interface
Signed-off-by: Jukka Laitinen <jukkax@ssrc.tii.ae>
Need to log both, because on some systems the
information will come in directly as a
landing_target_pose message, and on others
it's coming in as irlock_report and then filtered
in PX4 to produce the landing_target_pose message.
If the board supports encrypting logfiles, but the parameter SDCARD_ALGORITHM is set to NONE,
the log should be written to the sdcard in plaintext format. This fixes a bug which caused
logger to hang in mutex instead.
Signed-off-by: Jukka Laitinen <jukkax@ssrc.tii.ae>
The current practice of adding topics to the default set isn't scalable,
as it affects all setups.
By making sure topics are advertised on init, logger can just discard
topics that don't exist. This does not work for all topics, so topics are
specifically marked as optional. It can be extended to more topics later
on though.
This reduces the list of topics by ~35 on a pixracer configured as quad,
and reduces RAM usage by ~1KB.
CA: fix saturation computation
Since the CA matrix is normalized, the same scale applied to be used when using the effectiveness matrix
MCRateControl: use control_allocator_status to get saturation info
Junwoo Hwang