![]() |
ainstein_radar_filters package from ainstein_radar repoainstein_radar ainstein_radar_drivers ainstein_radar_filters ainstein_radar_gazebo_plugins ainstein_radar_msgs ainstein_radar_rviz_plugins ainstein_radar_tools |
ROS Distro
|
Package Summary
Tags | No category tags. |
Version | 3.0.1 |
License | BSD |
Build type | CATKIN |
Use | RECOMMENDED |
Repository Summary
Checkout URI | https://github.com/AinsteinAI/ainstein_radar.git |
VCS Type | git |
VCS Version | master |
Last Updated | 2024-02-26 |
Dev Status | MAINTAINED |
CI status | Continuous Integration |
Released | RELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Package Description
Additional Links
Maintainers
- Nick Rotella
Authors
- Nick Rotella
Changelog for package ainstein_radar_filters
3.0.1 (2020-02-11)
- Minor, add missing dependency
- Contributors: Nick Rotella
3.0.0 (2020-02-06)
- Add Cartesian tracking filter tracked pose output Added publishing of tracked object poses as geometry_msgs/PoseArray msg populated from tracked Cartesian position and using Cartesian velocity to determine pose. Forward direction (+x) is defined by tracked 3d velocity direction, with other axes determined by completing a right handed frame with +z up. Unfortunately, velocities cannot be published themselves without defining a custom TwistArray message, but nothing similar is supported natively in eg RViz.
- Update Cartesian tracking filter, fix bugs and tune Updated the Cartesian tracking filter to use the measured position instead of measured unit direction, since we can measure range with most radars. Fixed other bugs in implementation and got working. Tuned resulting filter parameters to get decent tracking, now working similarly to old tracking filter (in spherical coordinates). Still need to add full Pose and Twist output; currently converting to RadarTarget for backwards-compatibility with other radar filters.
- Minor, remove outdated filter config
- Add Cartesian tracking filter, needs debugging Added a Cartesian coordinates tracking filter for radar data which stores object state as Cartesian position and velocity rather than spherical coordinate range/angles/speed. The advantage is that we can track the full Cartesian velocity by using information from the radar speed measurement (which is a projection onto the radian direction) and consecutive range/angle measurements. This unfortunately makes the KF into an EKF because the measurements are now nonlinear in Cartesian space. The filter compiles and runs but never outputs tracked targets in its current state, and thus needs debugging. Since the RadarTarget datatype is not capable of storing full 3d velocity anyway, we need to output eg Pose and Twist types instead. Since the filter stores uncertainty, we can use PoseWithCovarianceStamped and TwistWithCovarianceStamped.
- Add support for point cloud input to radar tracking Added the ability for the radar tracking filter to subscribe to either a RadarTargetArray or PointCloud2 message. Internally, subscribing to a point cloud message converts to radar message type and then calls the original radar callback. This was added for portability since radar and point cloud messages are used with radar sensors often interchangeably.
- Minor, explicitly copy header in conversion
- Minor, remove outdated nodelet plugin
- Merge branch 'master' of https://github.com/AinsteinAI/ainstein_radar
- Update combine filter example launch and fix bug Updated the radar combine filter example launch file in the ainstein_radar_filters package to show how to launch three K79 radars and run the combine filter. Also fixed a bug in which the dynamic configuration was set for all possible numbers of radars which caused runtime errors because only one of the time sync objects was valid. Now checking the number of topics and only setting that object.
- Fix race condition in KF-based tracking filter Fixed a race condition in which the KF update loop and the radar data callback were in a race condition, with the number of KFs possibly changing during processing of new incoming data. Added a mutex to synchronize these functions, however the downside is potentially slower processing speed due to blocking waits for mutex unlocks in the data callback. Should be fine for small numbers of KFs.
- Fix broken radar to point cloud conversion node
- Minor, change passthrough filter default field
- Add example launch for radar combine filter usage Added a launch file example for using the radar combine filter to sync three RadarTargetArray topics. Note that the topic names must be set as an arg and passed in through rosparam due to the parameter being a list of strings. Also note that the "slop" factor in message syncing has its default set in the cfg/ file and can be loaded using the usual dynamic reconfigure loader.
- Add up to 8 synchronized topics in combine filter Added the ability to synchronize up to 8 RadarTargetArray topics in the combine filter. In theory the approximate time synchronizer in ROS can support 9 topics, HOWEVER boost::bind (which is used to register the callback) only supports 9 total arguments, the first of which in this case must be the "this" pointer because we bind a class member function here (see https://www.boost.org/doc/libs/1_45_0/libs/bind/bind.html#NumberOfArguments) The ability to synchronize radar topics beyond 3 has not been tested with data (only checked for compilation).
- Merge branch 'master' of https://github.com/AinsteinAI/ainstein_radar
- Minor, add dynconfig update to combine filter
- Minor, needed to negate speed for K79-3D using new SNR firmware
- Refactor to clean up combine filter callbacks Refactored the combine filter's callbacks to use one central callback which works for any number of topics. This cleans up the overloaded callbacks a bit before adding the callbacks for >3 topics (to come next).
- Minor, refactor combine topic names for consistency
- Refactor combine filter for 2 or 3 topics via param Refactored the radar combine filter to approximately sync 2 or 3 topics by reading in a list of topic names and calling appropriate templated functions for setting up the time synchronizer and registering callback functions for each. This is not very clear but since the time sync variables are templated on the exact number of topics, the use of pre-defined templated variables for each number of topics seems
File truncated at 100 lines see the full file
Wiki Tutorials
Package Dependencies
System Dependencies
Dependant Packages
Launch files
- launch/k79_people_tracking.launch
- launch/o79_can_people_tracking.launch
- launch/o79_single_point_cloud_debug.launch
- launch/radar_combine_filter.launch
-
- topic_names [default: [/radar1/targets/raw,/radar2/targets/raw,/radar3/targets/raw]]
Messages
Services
Recent questions tagged ainstein_radar_filters at Robotics Stack Exchange
![]() |
ainstein_radar_filters package from ainstein_radar repoainstein_radar ainstein_radar_drivers ainstein_radar_filters ainstein_radar_gazebo_plugins ainstein_radar_msgs ainstein_radar_rviz_plugins ainstein_radar_tools |
ROS Distro
|
Package Summary
Tags | No category tags. |
Version | 3.0.1 |
License | BSD |
Build type | CATKIN |
Use | RECOMMENDED |
Repository Summary
Checkout URI | https://github.com/AinsteinAI/ainstein_radar.git |
VCS Type | git |
VCS Version | master |
Last Updated | 2024-02-26 |
Dev Status | MAINTAINED |
CI status | Continuous Integration |
Released | RELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Package Description
Additional Links
Maintainers
- Nick Rotella
Authors
- Nick Rotella
Changelog for package ainstein_radar_filters
3.0.1 (2020-02-11)
- Minor, add missing dependency
- Contributors: Nick Rotella
3.0.0 (2020-02-06)
- Add Cartesian tracking filter tracked pose output Added publishing of tracked object poses as geometry_msgs/PoseArray msg populated from tracked Cartesian position and using Cartesian velocity to determine pose. Forward direction (+x) is defined by tracked 3d velocity direction, with other axes determined by completing a right handed frame with +z up. Unfortunately, velocities cannot be published themselves without defining a custom TwistArray message, but nothing similar is supported natively in eg RViz.
- Update Cartesian tracking filter, fix bugs and tune Updated the Cartesian tracking filter to use the measured position instead of measured unit direction, since we can measure range with most radars. Fixed other bugs in implementation and got working. Tuned resulting filter parameters to get decent tracking, now working similarly to old tracking filter (in spherical coordinates). Still need to add full Pose and Twist output; currently converting to RadarTarget for backwards-compatibility with other radar filters.
- Minor, remove outdated filter config
- Add Cartesian tracking filter, needs debugging Added a Cartesian coordinates tracking filter for radar data which stores object state as Cartesian position and velocity rather than spherical coordinate range/angles/speed. The advantage is that we can track the full Cartesian velocity by using information from the radar speed measurement (which is a projection onto the radian direction) and consecutive range/angle measurements. This unfortunately makes the KF into an EKF because the measurements are now nonlinear in Cartesian space. The filter compiles and runs but never outputs tracked targets in its current state, and thus needs debugging. Since the RadarTarget datatype is not capable of storing full 3d velocity anyway, we need to output eg Pose and Twist types instead. Since the filter stores uncertainty, we can use PoseWithCovarianceStamped and TwistWithCovarianceStamped.
- Add support for point cloud input to radar tracking Added the ability for the radar tracking filter to subscribe to either a RadarTargetArray or PointCloud2 message. Internally, subscribing to a point cloud message converts to radar message type and then calls the original radar callback. This was added for portability since radar and point cloud messages are used with radar sensors often interchangeably.
- Minor, explicitly copy header in conversion
- Minor, remove outdated nodelet plugin
- Merge branch 'master' of https://github.com/AinsteinAI/ainstein_radar
- Update combine filter example launch and fix bug Updated the radar combine filter example launch file in the ainstein_radar_filters package to show how to launch three K79 radars and run the combine filter. Also fixed a bug in which the dynamic configuration was set for all possible numbers of radars which caused runtime errors because only one of the time sync objects was valid. Now checking the number of topics and only setting that object.
- Fix race condition in KF-based tracking filter Fixed a race condition in which the KF update loop and the radar data callback were in a race condition, with the number of KFs possibly changing during processing of new incoming data. Added a mutex to synchronize these functions, however the downside is potentially slower processing speed due to blocking waits for mutex unlocks in the data callback. Should be fine for small numbers of KFs.
- Fix broken radar to point cloud conversion node
- Minor, change passthrough filter default field
- Add example launch for radar combine filter usage Added a launch file example for using the radar combine filter to sync three RadarTargetArray topics. Note that the topic names must be set as an arg and passed in through rosparam due to the parameter being a list of strings. Also note that the "slop" factor in message syncing has its default set in the cfg/ file and can be loaded using the usual dynamic reconfigure loader.
- Add up to 8 synchronized topics in combine filter Added the ability to synchronize up to 8 RadarTargetArray topics in the combine filter. In theory the approximate time synchronizer in ROS can support 9 topics, HOWEVER boost::bind (which is used to register the callback) only supports 9 total arguments, the first of which in this case must be the "this" pointer because we bind a class member function here (see https://www.boost.org/doc/libs/1_45_0/libs/bind/bind.html#NumberOfArguments) The ability to synchronize radar topics beyond 3 has not been tested with data (only checked for compilation).
- Merge branch 'master' of https://github.com/AinsteinAI/ainstein_radar
- Minor, add dynconfig update to combine filter
- Minor, needed to negate speed for K79-3D using new SNR firmware
- Refactor to clean up combine filter callbacks Refactored the combine filter's callbacks to use one central callback which works for any number of topics. This cleans up the overloaded callbacks a bit before adding the callbacks for >3 topics (to come next).
- Minor, refactor combine topic names for consistency
- Refactor combine filter for 2 or 3 topics via param Refactored the radar combine filter to approximately sync 2 or 3 topics by reading in a list of topic names and calling appropriate templated functions for setting up the time synchronizer and registering callback functions for each. This is not very clear but since the time sync variables are templated on the exact number of topics, the use of pre-defined templated variables for each number of topics seems
File truncated at 100 lines see the full file
Wiki Tutorials
Package Dependencies
System Dependencies
Dependant Packages
Launch files
- launch/k79_people_tracking.launch
- launch/o79_can_people_tracking.launch
- launch/o79_single_point_cloud_debug.launch
- launch/radar_combine_filter.launch
-
- topic_names [default: [/radar1/targets/raw,/radar2/targets/raw,/radar3/targets/raw]]
Messages
Services
Recent questions tagged ainstein_radar_filters at Robotics Stack Exchange
![]() |
ainstein_radar_filters package from ainstein_radar repoainstein_radar ainstein_radar_drivers ainstein_radar_filters ainstein_radar_gazebo_plugins ainstein_radar_msgs ainstein_radar_rviz_plugins ainstein_radar_tools |
ROS Distro
|
Package Summary
Tags | No category tags. |
Version | 3.0.1 |
License | BSD |
Build type | CATKIN |
Use | RECOMMENDED |
Repository Summary
Checkout URI | https://github.com/AinsteinAI/ainstein_radar.git |
VCS Type | git |
VCS Version | master |
Last Updated | 2024-02-26 |
Dev Status | MAINTAINED |
CI status | Continuous Integration |
Released | RELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Package Description
Additional Links
Maintainers
- Nick Rotella
Authors
- Nick Rotella
Changelog for package ainstein_radar_filters
3.0.1 (2020-02-11)
- Minor, add missing dependency
- Contributors: Nick Rotella
3.0.0 (2020-02-06)
- Add Cartesian tracking filter tracked pose output Added publishing of tracked object poses as geometry_msgs/PoseArray msg populated from tracked Cartesian position and using Cartesian velocity to determine pose. Forward direction (+x) is defined by tracked 3d velocity direction, with other axes determined by completing a right handed frame with +z up. Unfortunately, velocities cannot be published themselves without defining a custom TwistArray message, but nothing similar is supported natively in eg RViz.
- Update Cartesian tracking filter, fix bugs and tune Updated the Cartesian tracking filter to use the measured position instead of measured unit direction, since we can measure range with most radars. Fixed other bugs in implementation and got working. Tuned resulting filter parameters to get decent tracking, now working similarly to old tracking filter (in spherical coordinates). Still need to add full Pose and Twist output; currently converting to RadarTarget for backwards-compatibility with other radar filters.
- Minor, remove outdated filter config
- Add Cartesian tracking filter, needs debugging Added a Cartesian coordinates tracking filter for radar data which stores object state as Cartesian position and velocity rather than spherical coordinate range/angles/speed. The advantage is that we can track the full Cartesian velocity by using information from the radar speed measurement (which is a projection onto the radian direction) and consecutive range/angle measurements. This unfortunately makes the KF into an EKF because the measurements are now nonlinear in Cartesian space. The filter compiles and runs but never outputs tracked targets in its current state, and thus needs debugging. Since the RadarTarget datatype is not capable of storing full 3d velocity anyway, we need to output eg Pose and Twist types instead. Since the filter stores uncertainty, we can use PoseWithCovarianceStamped and TwistWithCovarianceStamped.
- Add support for point cloud input to radar tracking Added the ability for the radar tracking filter to subscribe to either a RadarTargetArray or PointCloud2 message. Internally, subscribing to a point cloud message converts to radar message type and then calls the original radar callback. This was added for portability since radar and point cloud messages are used with radar sensors often interchangeably.
- Minor, explicitly copy header in conversion
- Minor, remove outdated nodelet plugin
- Merge branch 'master' of https://github.com/AinsteinAI/ainstein_radar
- Update combine filter example launch and fix bug Updated the radar combine filter example launch file in the ainstein_radar_filters package to show how to launch three K79 radars and run the combine filter. Also fixed a bug in which the dynamic configuration was set for all possible numbers of radars which caused runtime errors because only one of the time sync objects was valid. Now checking the number of topics and only setting that object.
- Fix race condition in KF-based tracking filter Fixed a race condition in which the KF update loop and the radar data callback were in a race condition, with the number of KFs possibly changing during processing of new incoming data. Added a mutex to synchronize these functions, however the downside is potentially slower processing speed due to blocking waits for mutex unlocks in the data callback. Should be fine for small numbers of KFs.
- Fix broken radar to point cloud conversion node
- Minor, change passthrough filter default field
- Add example launch for radar combine filter usage Added a launch file example for using the radar combine filter to sync three RadarTargetArray topics. Note that the topic names must be set as an arg and passed in through rosparam due to the parameter being a list of strings. Also note that the "slop" factor in message syncing has its default set in the cfg/ file and can be loaded using the usual dynamic reconfigure loader.
- Add up to 8 synchronized topics in combine filter Added the ability to synchronize up to 8 RadarTargetArray topics in the combine filter. In theory the approximate time synchronizer in ROS can support 9 topics, HOWEVER boost::bind (which is used to register the callback) only supports 9 total arguments, the first of which in this case must be the "this" pointer because we bind a class member function here (see https://www.boost.org/doc/libs/1_45_0/libs/bind/bind.html#NumberOfArguments) The ability to synchronize radar topics beyond 3 has not been tested with data (only checked for compilation).
- Merge branch 'master' of https://github.com/AinsteinAI/ainstein_radar
- Minor, add dynconfig update to combine filter
- Minor, needed to negate speed for K79-3D using new SNR firmware
- Refactor to clean up combine filter callbacks Refactored the combine filter's callbacks to use one central callback which works for any number of topics. This cleans up the overloaded callbacks a bit before adding the callbacks for >3 topics (to come next).
- Minor, refactor combine topic names for consistency
- Refactor combine filter for 2 or 3 topics via param Refactored the radar combine filter to approximately sync 2 or 3 topics by reading in a list of topic names and calling appropriate templated functions for setting up the time synchronizer and registering callback functions for each. This is not very clear but since the time sync variables are templated on the exact number of topics, the use of pre-defined templated variables for each number of topics seems
File truncated at 100 lines see the full file
Wiki Tutorials
Package Dependencies
System Dependencies
Dependant Packages
Launch files
- launch/k79_people_tracking.launch
- launch/o79_can_people_tracking.launch
- launch/o79_single_point_cloud_debug.launch
- launch/radar_combine_filter.launch
-
- topic_names [default: [/radar1/targets/raw,/radar2/targets/raw,/radar3/targets/raw]]
Messages
Services
Recent questions tagged ainstein_radar_filters at Robotics Stack Exchange
![]() |
ainstein_radar_filters package from ainstein_radar repoainstein_radar ainstein_radar_drivers ainstein_radar_filters ainstein_radar_gazebo_plugins ainstein_radar_msgs ainstein_radar_rviz_plugins ainstein_radar_tools |
ROS Distro
|
Package Summary
Tags | No category tags. |
Version | 3.0.1 |
License | BSD |
Build type | CATKIN |
Use | RECOMMENDED |
Repository Summary
Checkout URI | https://github.com/AinsteinAI/ainstein_radar.git |
VCS Type | git |
VCS Version | master |
Last Updated | 2024-02-26 |
Dev Status | MAINTAINED |
CI status | Continuous Integration |
Released | RELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Package Description
Additional Links
Maintainers
- Nick Rotella
Authors
- Nick Rotella
Changelog for package ainstein_radar_filters
3.0.1 (2020-02-11)
- Minor, add missing dependency
- Contributors: Nick Rotella
3.0.0 (2020-02-06)
- Add Cartesian tracking filter tracked pose output Added publishing of tracked object poses as geometry_msgs/PoseArray msg populated from tracked Cartesian position and using Cartesian velocity to determine pose. Forward direction (+x) is defined by tracked 3d velocity direction, with other axes determined by completing a right handed frame with +z up. Unfortunately, velocities cannot be published themselves without defining a custom TwistArray message, but nothing similar is supported natively in eg RViz.
- Update Cartesian tracking filter, fix bugs and tune Updated the Cartesian tracking filter to use the measured position instead of measured unit direction, since we can measure range with most radars. Fixed other bugs in implementation and got working. Tuned resulting filter parameters to get decent tracking, now working similarly to old tracking filter (in spherical coordinates). Still need to add full Pose and Twist output; currently converting to RadarTarget for backwards-compatibility with other radar filters.
- Minor, remove outdated filter config
- Add Cartesian tracking filter, needs debugging Added a Cartesian coordinates tracking filter for radar data which stores object state as Cartesian position and velocity rather than spherical coordinate range/angles/speed. The advantage is that we can track the full Cartesian velocity by using information from the radar speed measurement (which is a projection onto the radian direction) and consecutive range/angle measurements. This unfortunately makes the KF into an EKF because the measurements are now nonlinear in Cartesian space. The filter compiles and runs but never outputs tracked targets in its current state, and thus needs debugging. Since the RadarTarget datatype is not capable of storing full 3d velocity anyway, we need to output eg Pose and Twist types instead. Since the filter stores uncertainty, we can use PoseWithCovarianceStamped and TwistWithCovarianceStamped.
- Add support for point cloud input to radar tracking Added the ability for the radar tracking filter to subscribe to either a RadarTargetArray or PointCloud2 message. Internally, subscribing to a point cloud message converts to radar message type and then calls the original radar callback. This was added for portability since radar and point cloud messages are used with radar sensors often interchangeably.
- Minor, explicitly copy header in conversion
- Minor, remove outdated nodelet plugin
- Merge branch 'master' of https://github.com/AinsteinAI/ainstein_radar
- Update combine filter example launch and fix bug Updated the radar combine filter example launch file in the ainstein_radar_filters package to show how to launch three K79 radars and run the combine filter. Also fixed a bug in which the dynamic configuration was set for all possible numbers of radars which caused runtime errors because only one of the time sync objects was valid. Now checking the number of topics and only setting that object.
- Fix race condition in KF-based tracking filter Fixed a race condition in which the KF update loop and the radar data callback were in a race condition, with the number of KFs possibly changing during processing of new incoming data. Added a mutex to synchronize these functions, however the downside is potentially slower processing speed due to blocking waits for mutex unlocks in the data callback. Should be fine for small numbers of KFs.
- Fix broken radar to point cloud conversion node
- Minor, change passthrough filter default field
- Add example launch for radar combine filter usage Added a launch file example for using the radar combine filter to sync three RadarTargetArray topics. Note that the topic names must be set as an arg and passed in through rosparam due to the parameter being a list of strings. Also note that the "slop" factor in message syncing has its default set in the cfg/ file and can be loaded using the usual dynamic reconfigure loader.
- Add up to 8 synchronized topics in combine filter Added the ability to synchronize up to 8 RadarTargetArray topics in the combine filter. In theory the approximate time synchronizer in ROS can support 9 topics, HOWEVER boost::bind (which is used to register the callback) only supports 9 total arguments, the first of which in this case must be the "this" pointer because we bind a class member function here (see https://www.boost.org/doc/libs/1_45_0/libs/bind/bind.html#NumberOfArguments) The ability to synchronize radar topics beyond 3 has not been tested with data (only checked for compilation).
- Merge branch 'master' of https://github.com/AinsteinAI/ainstein_radar
- Minor, add dynconfig update to combine filter
- Minor, needed to negate speed for K79-3D using new SNR firmware
- Refactor to clean up combine filter callbacks Refactored the combine filter's callbacks to use one central callback which works for any number of topics. This cleans up the overloaded callbacks a bit before adding the callbacks for >3 topics (to come next).
- Minor, refactor combine topic names for consistency
- Refactor combine filter for 2 or 3 topics via param Refactored the radar combine filter to approximately sync 2 or 3 topics by reading in a list of topic names and calling appropriate templated functions for setting up the time synchronizer and registering callback functions for each. This is not very clear but since the time sync variables are templated on the exact number of topics, the use of pre-defined templated variables for each number of topics seems
File truncated at 100 lines see the full file
Wiki Tutorials
Package Dependencies
System Dependencies
Dependant Packages
Launch files
- launch/k79_people_tracking.launch
- launch/o79_can_people_tracking.launch
- launch/o79_single_point_cloud_debug.launch
- launch/radar_combine_filter.launch
-
- topic_names [default: [/radar1/targets/raw,/radar2/targets/raw,/radar3/targets/raw]]
Messages
Services
Recent questions tagged ainstein_radar_filters at Robotics Stack Exchange
![]() |
ainstein_radar_filters package from ainstein_radar repoainstein_radar ainstein_radar_drivers ainstein_radar_filters ainstein_radar_gazebo_plugins ainstein_radar_msgs ainstein_radar_rviz_plugins ainstein_radar_tools |
ROS Distro
|
Package Summary
Tags | No category tags. |
Version | 3.0.1 |
License | BSD |
Build type | CATKIN |
Use | RECOMMENDED |
Repository Summary
Checkout URI | https://github.com/AinsteinAI/ainstein_radar.git |
VCS Type | git |
VCS Version | master |
Last Updated | 2024-02-26 |
Dev Status | MAINTAINED |
CI status | Continuous Integration |
Released | RELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Package Description
Additional Links
Maintainers
- Nick Rotella
Authors
- Nick Rotella
Changelog for package ainstein_radar_filters
3.0.1 (2020-02-11)
- Minor, add missing dependency
- Contributors: Nick Rotella
3.0.0 (2020-02-06)
- Add Cartesian tracking filter tracked pose output Added publishing of tracked object poses as geometry_msgs/PoseArray msg populated from tracked Cartesian position and using Cartesian velocity to determine pose. Forward direction (+x) is defined by tracked 3d velocity direction, with other axes determined by completing a right handed frame with +z up. Unfortunately, velocities cannot be published themselves without defining a custom TwistArray message, but nothing similar is supported natively in eg RViz.
- Update Cartesian tracking filter, fix bugs and tune Updated the Cartesian tracking filter to use the measured position instead of measured unit direction, since we can measure range with most radars. Fixed other bugs in implementation and got working. Tuned resulting filter parameters to get decent tracking, now working similarly to old tracking filter (in spherical coordinates). Still need to add full Pose and Twist output; currently converting to RadarTarget for backwards-compatibility with other radar filters.
- Minor, remove outdated filter config
- Add Cartesian tracking filter, needs debugging Added a Cartesian coordinates tracking filter for radar data which stores object state as Cartesian position and velocity rather than spherical coordinate range/angles/speed. The advantage is that we can track the full Cartesian velocity by using information from the radar speed measurement (which is a projection onto the radian direction) and consecutive range/angle measurements. This unfortunately makes the KF into an EKF because the measurements are now nonlinear in Cartesian space. The filter compiles and runs but never outputs tracked targets in its current state, and thus needs debugging. Since the RadarTarget datatype is not capable of storing full 3d velocity anyway, we need to output eg Pose and Twist types instead. Since the filter stores uncertainty, we can use PoseWithCovarianceStamped and TwistWithCovarianceStamped.
- Add support for point cloud input to radar tracking Added the ability for the radar tracking filter to subscribe to either a RadarTargetArray or PointCloud2 message. Internally, subscribing to a point cloud message converts to radar message type and then calls the original radar callback. This was added for portability since radar and point cloud messages are used with radar sensors often interchangeably.
- Minor, explicitly copy header in conversion
- Minor, remove outdated nodelet plugin
- Merge branch 'master' of https://github.com/AinsteinAI/ainstein_radar
- Update combine filter example launch and fix bug Updated the radar combine filter example launch file in the ainstein_radar_filters package to show how to launch three K79 radars and run the combine filter. Also fixed a bug in which the dynamic configuration was set for all possible numbers of radars which caused runtime errors because only one of the time sync objects was valid. Now checking the number of topics and only setting that object.
- Fix race condition in KF-based tracking filter Fixed a race condition in which the KF update loop and the radar data callback were in a race condition, with the number of KFs possibly changing during processing of new incoming data. Added a mutex to synchronize these functions, however the downside is potentially slower processing speed due to blocking waits for mutex unlocks in the data callback. Should be fine for small numbers of KFs.
- Fix broken radar to point cloud conversion node
- Minor, change passthrough filter default field
- Add example launch for radar combine filter usage Added a launch file example for using the radar combine filter to sync three RadarTargetArray topics. Note that the topic names must be set as an arg and passed in through rosparam due to the parameter being a list of strings. Also note that the "slop" factor in message syncing has its default set in the cfg/ file and can be loaded using the usual dynamic reconfigure loader.
- Add up to 8 synchronized topics in combine filter Added the ability to synchronize up to 8 RadarTargetArray topics in the combine filter. In theory the approximate time synchronizer in ROS can support 9 topics, HOWEVER boost::bind (which is used to register the callback) only supports 9 total arguments, the first of which in this case must be the "this" pointer because we bind a class member function here (see https://www.boost.org/doc/libs/1_45_0/libs/bind/bind.html#NumberOfArguments) The ability to synchronize radar topics beyond 3 has not been tested with data (only checked for compilation).
- Merge branch 'master' of https://github.com/AinsteinAI/ainstein_radar
- Minor, add dynconfig update to combine filter
- Minor, needed to negate speed for K79-3D using new SNR firmware
- Refactor to clean up combine filter callbacks Refactored the combine filter's callbacks to use one central callback which works for any number of topics. This cleans up the overloaded callbacks a bit before adding the callbacks for >3 topics (to come next).
- Minor, refactor combine topic names for consistency
- Refactor combine filter for 2 or 3 topics via param Refactored the radar combine filter to approximately sync 2 or 3 topics by reading in a list of topic names and calling appropriate templated functions for setting up the time synchronizer and registering callback functions for each. This is not very clear but since the time sync variables are templated on the exact number of topics, the use of pre-defined templated variables for each number of topics seems
File truncated at 100 lines see the full file
Wiki Tutorials
Package Dependencies
System Dependencies
Dependant Packages
Launch files
- launch/k79_people_tracking.launch
- launch/o79_can_people_tracking.launch
- launch/o79_single_point_cloud_debug.launch
- launch/radar_combine_filter.launch
-
- topic_names [default: [/radar1/targets/raw,/radar2/targets/raw,/radar3/targets/raw]]
Messages
Services
Recent questions tagged ainstein_radar_filters at Robotics Stack Exchange
![]() |
ainstein_radar_filters package from ainstein_radar repoainstein_radar ainstein_radar_drivers ainstein_radar_filters ainstein_radar_gazebo_plugins ainstein_radar_msgs ainstein_radar_rviz_plugins ainstein_radar_tools |
ROS Distro
|
Package Summary
Tags | No category tags. |
Version | 3.0.1 |
License | BSD |
Build type | CATKIN |
Use | RECOMMENDED |
Repository Summary
Checkout URI | https://github.com/AinsteinAI/ainstein_radar.git |
VCS Type | git |
VCS Version | master |
Last Updated | 2024-02-26 |
Dev Status | MAINTAINED |
CI status | Continuous Integration |
Released | RELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Package Description
Additional Links
Maintainers
- Nick Rotella
Authors
- Nick Rotella
Changelog for package ainstein_radar_filters
3.0.1 (2020-02-11)
- Minor, add missing dependency
- Contributors: Nick Rotella
3.0.0 (2020-02-06)
- Add Cartesian tracking filter tracked pose output Added publishing of tracked object poses as geometry_msgs/PoseArray msg populated from tracked Cartesian position and using Cartesian velocity to determine pose. Forward direction (+x) is defined by tracked 3d velocity direction, with other axes determined by completing a right handed frame with +z up. Unfortunately, velocities cannot be published themselves without defining a custom TwistArray message, but nothing similar is supported natively in eg RViz.
- Update Cartesian tracking filter, fix bugs and tune Updated the Cartesian tracking filter to use the measured position instead of measured unit direction, since we can measure range with most radars. Fixed other bugs in implementation and got working. Tuned resulting filter parameters to get decent tracking, now working similarly to old tracking filter (in spherical coordinates). Still need to add full Pose and Twist output; currently converting to RadarTarget for backwards-compatibility with other radar filters.
- Minor, remove outdated filter config
- Add Cartesian tracking filter, needs debugging Added a Cartesian coordinates tracking filter for radar data which stores object state as Cartesian position and velocity rather than spherical coordinate range/angles/speed. The advantage is that we can track the full Cartesian velocity by using information from the radar speed measurement (which is a projection onto the radian direction) and consecutive range/angle measurements. This unfortunately makes the KF into an EKF because the measurements are now nonlinear in Cartesian space. The filter compiles and runs but never outputs tracked targets in its current state, and thus needs debugging. Since the RadarTarget datatype is not capable of storing full 3d velocity anyway, we need to output eg Pose and Twist types instead. Since the filter stores uncertainty, we can use PoseWithCovarianceStamped and TwistWithCovarianceStamped.
- Add support for point cloud input to radar tracking Added the ability for the radar tracking filter to subscribe to either a RadarTargetArray or PointCloud2 message. Internally, subscribing to a point cloud message converts to radar message type and then calls the original radar callback. This was added for portability since radar and point cloud messages are used with radar sensors often interchangeably.
- Minor, explicitly copy header in conversion
- Minor, remove outdated nodelet plugin
- Merge branch 'master' of https://github.com/AinsteinAI/ainstein_radar
- Update combine filter example launch and fix bug Updated the radar combine filter example launch file in the ainstein_radar_filters package to show how to launch three K79 radars and run the combine filter. Also fixed a bug in which the dynamic configuration was set for all possible numbers of radars which caused runtime errors because only one of the time sync objects was valid. Now checking the number of topics and only setting that object.
- Fix race condition in KF-based tracking filter Fixed a race condition in which the KF update loop and the radar data callback were in a race condition, with the number of KFs possibly changing during processing of new incoming data. Added a mutex to synchronize these functions, however the downside is potentially slower processing speed due to blocking waits for mutex unlocks in the data callback. Should be fine for small numbers of KFs.
- Fix broken radar to point cloud conversion node
- Minor, change passthrough filter default field
- Add example launch for radar combine filter usage Added a launch file example for using the radar combine filter to sync three RadarTargetArray topics. Note that the topic names must be set as an arg and passed in through rosparam due to the parameter being a list of strings. Also note that the "slop" factor in message syncing has its default set in the cfg/ file and can be loaded using the usual dynamic reconfigure loader.
- Add up to 8 synchronized topics in combine filter Added the ability to synchronize up to 8 RadarTargetArray topics in the combine filter. In theory the approximate time synchronizer in ROS can support 9 topics, HOWEVER boost::bind (which is used to register the callback) only supports 9 total arguments, the first of which in this case must be the "this" pointer because we bind a class member function here (see https://www.boost.org/doc/libs/1_45_0/libs/bind/bind.html#NumberOfArguments) The ability to synchronize radar topics beyond 3 has not been tested with data (only checked for compilation).
- Merge branch 'master' of https://github.com/AinsteinAI/ainstein_radar
- Minor, add dynconfig update to combine filter
- Minor, needed to negate speed for K79-3D using new SNR firmware
- Refactor to clean up combine filter callbacks Refactored the combine filter's callbacks to use one central callback which works for any number of topics. This cleans up the overloaded callbacks a bit before adding the callbacks for >3 topics (to come next).
- Minor, refactor combine topic names for consistency
- Refactor combine filter for 2 or 3 topics via param Refactored the radar combine filter to approximately sync 2 or 3 topics by reading in a list of topic names and calling appropriate templated functions for setting up the time synchronizer and registering callback functions for each. This is not very clear but since the time sync variables are templated on the exact number of topics, the use of pre-defined templated variables for each number of topics seems
File truncated at 100 lines see the full file
Wiki Tutorials
Package Dependencies
System Dependencies
Dependant Packages
Launch files
- launch/k79_people_tracking.launch
- launch/o79_can_people_tracking.launch
- launch/o79_single_point_cloud_debug.launch
- launch/radar_combine_filter.launch
-
- topic_names [default: [/radar1/targets/raw,/radar2/targets/raw,/radar3/targets/raw]]
Messages
Services
Recent questions tagged ainstein_radar_filters at Robotics Stack Exchange
![]() |
ainstein_radar_filters package from ainstein_radar repoainstein_radar ainstein_radar_drivers ainstein_radar_filters ainstein_radar_gazebo_plugins ainstein_radar_msgs ainstein_radar_rviz_plugins ainstein_radar_tools |
ROS Distro
|
Package Summary
Tags | No category tags. |
Version | 3.0.1 |
License | BSD |
Build type | CATKIN |
Use | RECOMMENDED |
Repository Summary
Checkout URI | https://github.com/AinsteinAI/ainstein_radar.git |
VCS Type | git |
VCS Version | master |
Last Updated | 2024-02-26 |
Dev Status | MAINTAINED |
CI status | Continuous Integration |
Released | RELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Package Description
Additional Links
Maintainers
- Nick Rotella
Authors
- Nick Rotella
Changelog for package ainstein_radar_filters
3.0.1 (2020-02-11)
- Minor, add missing dependency
- Contributors: Nick Rotella
3.0.0 (2020-02-06)
- Add Cartesian tracking filter tracked pose output Added publishing of tracked object poses as geometry_msgs/PoseArray msg populated from tracked Cartesian position and using Cartesian velocity to determine pose. Forward direction (+x) is defined by tracked 3d velocity direction, with other axes determined by completing a right handed frame with +z up. Unfortunately, velocities cannot be published themselves without defining a custom TwistArray message, but nothing similar is supported natively in eg RViz.
- Update Cartesian tracking filter, fix bugs and tune Updated the Cartesian tracking filter to use the measured position instead of measured unit direction, since we can measure range with most radars. Fixed other bugs in implementation and got working. Tuned resulting filter parameters to get decent tracking, now working similarly to old tracking filter (in spherical coordinates). Still need to add full Pose and Twist output; currently converting to RadarTarget for backwards-compatibility with other radar filters.
- Minor, remove outdated filter config
- Add Cartesian tracking filter, needs debugging Added a Cartesian coordinates tracking filter for radar data which stores object state as Cartesian position and velocity rather than spherical coordinate range/angles/speed. The advantage is that we can track the full Cartesian velocity by using information from the radar speed measurement (which is a projection onto the radian direction) and consecutive range/angle measurements. This unfortunately makes the KF into an EKF because the measurements are now nonlinear in Cartesian space. The filter compiles and runs but never outputs tracked targets in its current state, and thus needs debugging. Since the RadarTarget datatype is not capable of storing full 3d velocity anyway, we need to output eg Pose and Twist types instead. Since the filter stores uncertainty, we can use PoseWithCovarianceStamped and TwistWithCovarianceStamped.
- Add support for point cloud input to radar tracking Added the ability for the radar tracking filter to subscribe to either a RadarTargetArray or PointCloud2 message. Internally, subscribing to a point cloud message converts to radar message type and then calls the original radar callback. This was added for portability since radar and point cloud messages are used with radar sensors often interchangeably.
- Minor, explicitly copy header in conversion
- Minor, remove outdated nodelet plugin
- Merge branch 'master' of https://github.com/AinsteinAI/ainstein_radar
- Update combine filter example launch and fix bug Updated the radar combine filter example launch file in the ainstein_radar_filters package to show how to launch three K79 radars and run the combine filter. Also fixed a bug in which the dynamic configuration was set for all possible numbers of radars which caused runtime errors because only one of the time sync objects was valid. Now checking the number of topics and only setting that object.
- Fix race condition in KF-based tracking filter Fixed a race condition in which the KF update loop and the radar data callback were in a race condition, with the number of KFs possibly changing during processing of new incoming data. Added a mutex to synchronize these functions, however the downside is potentially slower processing speed due to blocking waits for mutex unlocks in the data callback. Should be fine for small numbers of KFs.
- Fix broken radar to point cloud conversion node
- Minor, change passthrough filter default field
- Add example launch for radar combine filter usage Added a launch file example for using the radar combine filter to sync three RadarTargetArray topics. Note that the topic names must be set as an arg and passed in through rosparam due to the parameter being a list of strings. Also note that the "slop" factor in message syncing has its default set in the cfg/ file and can be loaded using the usual dynamic reconfigure loader.
- Add up to 8 synchronized topics in combine filter Added the ability to synchronize up to 8 RadarTargetArray topics in the combine filter. In theory the approximate time synchronizer in ROS can support 9 topics, HOWEVER boost::bind (which is used to register the callback) only supports 9 total arguments, the first of which in this case must be the "this" pointer because we bind a class member function here (see https://www.boost.org/doc/libs/1_45_0/libs/bind/bind.html#NumberOfArguments) The ability to synchronize radar topics beyond 3 has not been tested with data (only checked for compilation).
- Merge branch 'master' of https://github.com/AinsteinAI/ainstein_radar
- Minor, add dynconfig update to combine filter
- Minor, needed to negate speed for K79-3D using new SNR firmware
- Refactor to clean up combine filter callbacks Refactored the combine filter's callbacks to use one central callback which works for any number of topics. This cleans up the overloaded callbacks a bit before adding the callbacks for >3 topics (to come next).
- Minor, refactor combine topic names for consistency
- Refactor combine filter for 2 or 3 topics via param Refactored the radar combine filter to approximately sync 2 or 3 topics by reading in a list of topic names and calling appropriate templated functions for setting up the time synchronizer and registering callback functions for each. This is not very clear but since the time sync variables are templated on the exact number of topics, the use of pre-defined templated variables for each number of topics seems
File truncated at 100 lines see the full file
Wiki Tutorials
Package Dependencies
System Dependencies
Dependant Packages
Launch files
- launch/k79_people_tracking.launch
- launch/o79_can_people_tracking.launch
- launch/o79_single_point_cloud_debug.launch
- launch/radar_combine_filter.launch
-
- topic_names [default: [/radar1/targets/raw,/radar2/targets/raw,/radar3/targets/raw]]
Messages
Services
Recent questions tagged ainstein_radar_filters at Robotics Stack Exchange
![]() |
ainstein_radar_filters package from ainstein_radar repoainstein_radar ainstein_radar_drivers ainstein_radar_filters ainstein_radar_gazebo_plugins ainstein_radar_msgs ainstein_radar_rviz_plugins ainstein_radar_tools |
ROS Distro
|
Package Summary
Tags | No category tags. |
Version | 3.0.1 |
License | BSD |
Build type | CATKIN |
Use | RECOMMENDED |
Repository Summary
Checkout URI | https://github.com/AinsteinAI/ainstein_radar.git |
VCS Type | git |
VCS Version | master |
Last Updated | 2024-02-26 |
Dev Status | MAINTAINED |
CI status | Continuous Integration |
Released | RELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Package Description
Additional Links
Maintainers
- Nick Rotella
Authors
- Nick Rotella
Changelog for package ainstein_radar_filters
3.0.1 (2020-02-11)
- Minor, add missing dependency
- Contributors: Nick Rotella
3.0.0 (2020-02-06)
- Add Cartesian tracking filter tracked pose output Added publishing of tracked object poses as geometry_msgs/PoseArray msg populated from tracked Cartesian position and using Cartesian velocity to determine pose. Forward direction (+x) is defined by tracked 3d velocity direction, with other axes determined by completing a right handed frame with +z up. Unfortunately, velocities cannot be published themselves without defining a custom TwistArray message, but nothing similar is supported natively in eg RViz.
- Update Cartesian tracking filter, fix bugs and tune Updated the Cartesian tracking filter to use the measured position instead of measured unit direction, since we can measure range with most radars. Fixed other bugs in implementation and got working. Tuned resulting filter parameters to get decent tracking, now working similarly to old tracking filter (in spherical coordinates). Still need to add full Pose and Twist output; currently converting to RadarTarget for backwards-compatibility with other radar filters.
- Minor, remove outdated filter config
- Add Cartesian tracking filter, needs debugging Added a Cartesian coordinates tracking filter for radar data which stores object state as Cartesian position and velocity rather than spherical coordinate range/angles/speed. The advantage is that we can track the full Cartesian velocity by using information from the radar speed measurement (which is a projection onto the radian direction) and consecutive range/angle measurements. This unfortunately makes the KF into an EKF because the measurements are now nonlinear in Cartesian space. The filter compiles and runs but never outputs tracked targets in its current state, and thus needs debugging. Since the RadarTarget datatype is not capable of storing full 3d velocity anyway, we need to output eg Pose and Twist types instead. Since the filter stores uncertainty, we can use PoseWithCovarianceStamped and TwistWithCovarianceStamped.
- Add support for point cloud input to radar tracking Added the ability for the radar tracking filter to subscribe to either a RadarTargetArray or PointCloud2 message. Internally, subscribing to a point cloud message converts to radar message type and then calls the original radar callback. This was added for portability since radar and point cloud messages are used with radar sensors often interchangeably.
- Minor, explicitly copy header in conversion
- Minor, remove outdated nodelet plugin
- Merge branch 'master' of https://github.com/AinsteinAI/ainstein_radar
- Update combine filter example launch and fix bug Updated the radar combine filter example launch file in the ainstein_radar_filters package to show how to launch three K79 radars and run the combine filter. Also fixed a bug in which the dynamic configuration was set for all possible numbers of radars which caused runtime errors because only one of the time sync objects was valid. Now checking the number of topics and only setting that object.
- Fix race condition in KF-based tracking filter Fixed a race condition in which the KF update loop and the radar data callback were in a race condition, with the number of KFs possibly changing during processing of new incoming data. Added a mutex to synchronize these functions, however the downside is potentially slower processing speed due to blocking waits for mutex unlocks in the data callback. Should be fine for small numbers of KFs.
- Fix broken radar to point cloud conversion node
- Minor, change passthrough filter default field
- Add example launch for radar combine filter usage Added a launch file example for using the radar combine filter to sync three RadarTargetArray topics. Note that the topic names must be set as an arg and passed in through rosparam due to the parameter being a list of strings. Also note that the "slop" factor in message syncing has its default set in the cfg/ file and can be loaded using the usual dynamic reconfigure loader.
- Add up to 8 synchronized topics in combine filter Added the ability to synchronize up to 8 RadarTargetArray topics in the combine filter. In theory the approximate time synchronizer in ROS can support 9 topics, HOWEVER boost::bind (which is used to register the callback) only supports 9 total arguments, the first of which in this case must be the "this" pointer because we bind a class member function here (see https://www.boost.org/doc/libs/1_45_0/libs/bind/bind.html#NumberOfArguments) The ability to synchronize radar topics beyond 3 has not been tested with data (only checked for compilation).
- Merge branch 'master' of https://github.com/AinsteinAI/ainstein_radar
- Minor, add dynconfig update to combine filter
- Minor, needed to negate speed for K79-3D using new SNR firmware
- Refactor to clean up combine filter callbacks Refactored the combine filter's callbacks to use one central callback which works for any number of topics. This cleans up the overloaded callbacks a bit before adding the callbacks for >3 topics (to come next).
- Minor, refactor combine topic names for consistency
- Refactor combine filter for 2 or 3 topics via param Refactored the radar combine filter to approximately sync 2 or 3 topics by reading in a list of topic names and calling appropriate templated functions for setting up the time synchronizer and registering callback functions for each. This is not very clear but since the time sync variables are templated on the exact number of topics, the use of pre-defined templated variables for each number of topics seems
File truncated at 100 lines see the full file
Wiki Tutorials
Package Dependencies
System Dependencies
Dependant Packages
Launch files
- launch/k79_people_tracking.launch
- launch/o79_can_people_tracking.launch
- launch/o79_single_point_cloud_debug.launch
- launch/radar_combine_filter.launch
-
- topic_names [default: [/radar1/targets/raw,/radar2/targets/raw,/radar3/targets/raw]]
Messages
Services
Recent questions tagged ainstein_radar_filters at Robotics Stack Exchange
![]() |
ainstein_radar_filters package from ainstein_radar repoainstein_radar ainstein_radar_drivers ainstein_radar_filters ainstein_radar_gazebo_plugins ainstein_radar_msgs ainstein_radar_rviz_plugins ainstein_radar_tools |
ROS Distro
|
Package Summary
Tags | No category tags. |
Version | 3.0.1 |
License | BSD |
Build type | CATKIN |
Use | RECOMMENDED |
Repository Summary
Checkout URI | https://github.com/AinsteinAI/ainstein_radar.git |
VCS Type | git |
VCS Version | master |
Last Updated | 2024-02-26 |
Dev Status | MAINTAINED |
CI status | Continuous Integration |
Released | RELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Package Description
Additional Links
Maintainers
- Nick Rotella
Authors
- Nick Rotella
Changelog for package ainstein_radar_filters
3.0.1 (2020-02-11)
- Minor, add missing dependency
- Contributors: Nick Rotella
3.0.0 (2020-02-06)
- Add Cartesian tracking filter tracked pose output Added publishing of tracked object poses as geometry_msgs/PoseArray msg populated from tracked Cartesian position and using Cartesian velocity to determine pose. Forward direction (+x) is defined by tracked 3d velocity direction, with other axes determined by completing a right handed frame with +z up. Unfortunately, velocities cannot be published themselves without defining a custom TwistArray message, but nothing similar is supported natively in eg RViz.
- Update Cartesian tracking filter, fix bugs and tune Updated the Cartesian tracking filter to use the measured position instead of measured unit direction, since we can measure range with most radars. Fixed other bugs in implementation and got working. Tuned resulting filter parameters to get decent tracking, now working similarly to old tracking filter (in spherical coordinates). Still need to add full Pose and Twist output; currently converting to RadarTarget for backwards-compatibility with other radar filters.
- Minor, remove outdated filter config
- Add Cartesian tracking filter, needs debugging Added a Cartesian coordinates tracking filter for radar data which stores object state as Cartesian position and velocity rather than spherical coordinate range/angles/speed. The advantage is that we can track the full Cartesian velocity by using information from the radar speed measurement (which is a projection onto the radian direction) and consecutive range/angle measurements. This unfortunately makes the KF into an EKF because the measurements are now nonlinear in Cartesian space. The filter compiles and runs but never outputs tracked targets in its current state, and thus needs debugging. Since the RadarTarget datatype is not capable of storing full 3d velocity anyway, we need to output eg Pose and Twist types instead. Since the filter stores uncertainty, we can use PoseWithCovarianceStamped and TwistWithCovarianceStamped.
- Add support for point cloud input to radar tracking Added the ability for the radar tracking filter to subscribe to either a RadarTargetArray or PointCloud2 message. Internally, subscribing to a point cloud message converts to radar message type and then calls the original radar callback. This was added for portability since radar and point cloud messages are used with radar sensors often interchangeably.
- Minor, explicitly copy header in conversion
- Minor, remove outdated nodelet plugin
- Merge branch 'master' of https://github.com/AinsteinAI/ainstein_radar
- Update combine filter example launch and fix bug Updated the radar combine filter example launch file in the ainstein_radar_filters package to show how to launch three K79 radars and run the combine filter. Also fixed a bug in which the dynamic configuration was set for all possible numbers of radars which caused runtime errors because only one of the time sync objects was valid. Now checking the number of topics and only setting that object.
- Fix race condition in KF-based tracking filter Fixed a race condition in which the KF update loop and the radar data callback were in a race condition, with the number of KFs possibly changing during processing of new incoming data. Added a mutex to synchronize these functions, however the downside is potentially slower processing speed due to blocking waits for mutex unlocks in the data callback. Should be fine for small numbers of KFs.
- Fix broken radar to point cloud conversion node
- Minor, change passthrough filter default field
- Add example launch for radar combine filter usage Added a launch file example for using the radar combine filter to sync three RadarTargetArray topics. Note that the topic names must be set as an arg and passed in through rosparam due to the parameter being a list of strings. Also note that the "slop" factor in message syncing has its default set in the cfg/ file and can be loaded using the usual dynamic reconfigure loader.
- Add up to 8 synchronized topics in combine filter Added the ability to synchronize up to 8 RadarTargetArray topics in the combine filter. In theory the approximate time synchronizer in ROS can support 9 topics, HOWEVER boost::bind (which is used to register the callback) only supports 9 total arguments, the first of which in this case must be the "this" pointer because we bind a class member function here (see https://www.boost.org/doc/libs/1_45_0/libs/bind/bind.html#NumberOfArguments) The ability to synchronize radar topics beyond 3 has not been tested with data (only checked for compilation).
- Merge branch 'master' of https://github.com/AinsteinAI/ainstein_radar
- Minor, add dynconfig update to combine filter
- Minor, needed to negate speed for K79-3D using new SNR firmware
- Refactor to clean up combine filter callbacks Refactored the combine filter's callbacks to use one central callback which works for any number of topics. This cleans up the overloaded callbacks a bit before adding the callbacks for >3 topics (to come next).
- Minor, refactor combine topic names for consistency
- Refactor combine filter for 2 or 3 topics via param Refactored the radar combine filter to approximately sync 2 or 3 topics by reading in a list of topic names and calling appropriate templated functions for setting up the time synchronizer and registering callback functions for each. This is not very clear but since the time sync variables are templated on the exact number of topics, the use of pre-defined templated variables for each number of topics seems
File truncated at 100 lines see the full file
Wiki Tutorials
Package Dependencies
System Dependencies
Dependant Packages
Launch files
- launch/k79_people_tracking.launch
- launch/o79_can_people_tracking.launch
- launch/o79_single_point_cloud_debug.launch
- launch/radar_combine_filter.launch
-
- topic_names [default: [/radar1/targets/raw,/radar2/targets/raw,/radar3/targets/raw]]
Messages
Services
Recent questions tagged ainstein_radar_filters at Robotics Stack Exchange
![]() |
ainstein_radar_filters package from ainstein_radar repoainstein_radar ainstein_radar_drivers ainstein_radar_filters ainstein_radar_gazebo_plugins ainstein_radar_msgs ainstein_radar_rviz_plugins ainstein_radar_tools |
ROS Distro
|
Package Summary
Tags | No category tags. |
Version | 3.0.1 |
License | BSD |
Build type | CATKIN |
Use | RECOMMENDED |
Repository Summary
Checkout URI | https://github.com/AinsteinAI/ainstein_radar.git |
VCS Type | git |
VCS Version | master |
Last Updated | 2024-02-26 |
Dev Status | MAINTAINED |
CI status | Continuous Integration |
Released | RELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Package Description
Additional Links
Maintainers
- Nick Rotella
Authors
- Nick Rotella
Changelog for package ainstein_radar_filters
3.0.1 (2020-02-11)
- Minor, add missing dependency
- Contributors: Nick Rotella
3.0.0 (2020-02-06)
- Add Cartesian tracking filter tracked pose output Added publishing of tracked object poses as geometry_msgs/PoseArray msg populated from tracked Cartesian position and using Cartesian velocity to determine pose. Forward direction (+x) is defined by tracked 3d velocity direction, with other axes determined by completing a right handed frame with +z up. Unfortunately, velocities cannot be published themselves without defining a custom TwistArray message, but nothing similar is supported natively in eg RViz.
- Update Cartesian tracking filter, fix bugs and tune Updated the Cartesian tracking filter to use the measured position instead of measured unit direction, since we can measure range with most radars. Fixed other bugs in implementation and got working. Tuned resulting filter parameters to get decent tracking, now working similarly to old tracking filter (in spherical coordinates). Still need to add full Pose and Twist output; currently converting to RadarTarget for backwards-compatibility with other radar filters.
- Minor, remove outdated filter config
- Add Cartesian tracking filter, needs debugging Added a Cartesian coordinates tracking filter for radar data which stores object state as Cartesian position and velocity rather than spherical coordinate range/angles/speed. The advantage is that we can track the full Cartesian velocity by using information from the radar speed measurement (which is a projection onto the radian direction) and consecutive range/angle measurements. This unfortunately makes the KF into an EKF because the measurements are now nonlinear in Cartesian space. The filter compiles and runs but never outputs tracked targets in its current state, and thus needs debugging. Since the RadarTarget datatype is not capable of storing full 3d velocity anyway, we need to output eg Pose and Twist types instead. Since the filter stores uncertainty, we can use PoseWithCovarianceStamped and TwistWithCovarianceStamped.
- Add support for point cloud input to radar tracking Added the ability for the radar tracking filter to subscribe to either a RadarTargetArray or PointCloud2 message. Internally, subscribing to a point cloud message converts to radar message type and then calls the original radar callback. This was added for portability since radar and point cloud messages are used with radar sensors often interchangeably.
- Minor, explicitly copy header in conversion
- Minor, remove outdated nodelet plugin
- Merge branch 'master' of https://github.com/AinsteinAI/ainstein_radar
- Update combine filter example launch and fix bug Updated the radar combine filter example launch file in the ainstein_radar_filters package to show how to launch three K79 radars and run the combine filter. Also fixed a bug in which the dynamic configuration was set for all possible numbers of radars which caused runtime errors because only one of the time sync objects was valid. Now checking the number of topics and only setting that object.
- Fix race condition in KF-based tracking filter Fixed a race condition in which the KF update loop and the radar data callback were in a race condition, with the number of KFs possibly changing during processing of new incoming data. Added a mutex to synchronize these functions, however the downside is potentially slower processing speed due to blocking waits for mutex unlocks in the data callback. Should be fine for small numbers of KFs.
- Fix broken radar to point cloud conversion node
- Minor, change passthrough filter default field
- Add example launch for radar combine filter usage Added a launch file example for using the radar combine filter to sync three RadarTargetArray topics. Note that the topic names must be set as an arg and passed in through rosparam due to the parameter being a list of strings. Also note that the "slop" factor in message syncing has its default set in the cfg/ file and can be loaded using the usual dynamic reconfigure loader.
- Add up to 8 synchronized topics in combine filter Added the ability to synchronize up to 8 RadarTargetArray topics in the combine filter. In theory the approximate time synchronizer in ROS can support 9 topics, HOWEVER boost::bind (which is used to register the callback) only supports 9 total arguments, the first of which in this case must be the "this" pointer because we bind a class member function here (see https://www.boost.org/doc/libs/1_45_0/libs/bind/bind.html#NumberOfArguments) The ability to synchronize radar topics beyond 3 has not been tested with data (only checked for compilation).
- Merge branch 'master' of https://github.com/AinsteinAI/ainstein_radar
- Minor, add dynconfig update to combine filter
- Minor, needed to negate speed for K79-3D using new SNR firmware
- Refactor to clean up combine filter callbacks Refactored the combine filter's callbacks to use one central callback which works for any number of topics. This cleans up the overloaded callbacks a bit before adding the callbacks for >3 topics (to come next).
- Minor, refactor combine topic names for consistency
- Refactor combine filter for 2 or 3 topics via param Refactored the radar combine filter to approximately sync 2 or 3 topics by reading in a list of topic names and calling appropriate templated functions for setting up the time synchronizer and registering callback functions for each. This is not very clear but since the time sync variables are templated on the exact number of topics, the use of pre-defined templated variables for each number of topics seems
File truncated at 100 lines see the full file
Wiki Tutorials
Package Dependencies
System Dependencies
Dependant Packages
Launch files
- launch/k79_people_tracking.launch
- launch/o79_can_people_tracking.launch
- launch/o79_single_point_cloud_debug.launch
- launch/radar_combine_filter.launch
-
- topic_names [default: [/radar1/targets/raw,/radar2/targets/raw,/radar3/targets/raw]]
Messages
Services
Recent questions tagged ainstein_radar_filters at Robotics Stack Exchange
![]() |
ainstein_radar_filters package from ainstein_radar repoainstein_radar ainstein_radar_drivers ainstein_radar_filters ainstein_radar_gazebo_plugins ainstein_radar_msgs ainstein_radar_rviz_plugins ainstein_radar_tools |
ROS Distro
|
Package Summary
Tags | No category tags. |
Version | 3.0.1 |
License | BSD |
Build type | CATKIN |
Use | RECOMMENDED |
Repository Summary
Checkout URI | https://github.com/AinsteinAI/ainstein_radar.git |
VCS Type | git |
VCS Version | master |
Last Updated | 2024-02-26 |
Dev Status | MAINTAINED |
CI status | Continuous Integration |
Released | RELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Package Description
Additional Links
Maintainers
- Nick Rotella
Authors
- Nick Rotella
Changelog for package ainstein_radar_filters
3.0.1 (2020-02-11)
- Minor, add missing dependency
- Contributors: Nick Rotella
3.0.0 (2020-02-06)
- Add Cartesian tracking filter tracked pose output Added publishing of tracked object poses as geometry_msgs/PoseArray msg populated from tracked Cartesian position and using Cartesian velocity to determine pose. Forward direction (+x) is defined by tracked 3d velocity direction, with other axes determined by completing a right handed frame with +z up. Unfortunately, velocities cannot be published themselves without defining a custom TwistArray message, but nothing similar is supported natively in eg RViz.
- Update Cartesian tracking filter, fix bugs and tune Updated the Cartesian tracking filter to use the measured position instead of measured unit direction, since we can measure range with most radars. Fixed other bugs in implementation and got working. Tuned resulting filter parameters to get decent tracking, now working similarly to old tracking filter (in spherical coordinates). Still need to add full Pose and Twist output; currently converting to RadarTarget for backwards-compatibility with other radar filters.
- Minor, remove outdated filter config
- Add Cartesian tracking filter, needs debugging Added a Cartesian coordinates tracking filter for radar data which stores object state as Cartesian position and velocity rather than spherical coordinate range/angles/speed. The advantage is that we can track the full Cartesian velocity by using information from the radar speed measurement (which is a projection onto the radian direction) and consecutive range/angle measurements. This unfortunately makes the KF into an EKF because the measurements are now nonlinear in Cartesian space. The filter compiles and runs but never outputs tracked targets in its current state, and thus needs debugging. Since the RadarTarget datatype is not capable of storing full 3d velocity anyway, we need to output eg Pose and Twist types instead. Since the filter stores uncertainty, we can use PoseWithCovarianceStamped and TwistWithCovarianceStamped.
- Add support for point cloud input to radar tracking Added the ability for the radar tracking filter to subscribe to either a RadarTargetArray or PointCloud2 message. Internally, subscribing to a point cloud message converts to radar message type and then calls the original radar callback. This was added for portability since radar and point cloud messages are used with radar sensors often interchangeably.
- Minor, explicitly copy header in conversion
- Minor, remove outdated nodelet plugin
- Merge branch 'master' of https://github.com/AinsteinAI/ainstein_radar
- Update combine filter example launch and fix bug Updated the radar combine filter example launch file in the ainstein_radar_filters package to show how to launch three K79 radars and run the combine filter. Also fixed a bug in which the dynamic configuration was set for all possible numbers of radars which caused runtime errors because only one of the time sync objects was valid. Now checking the number of topics and only setting that object.
- Fix race condition in KF-based tracking filter Fixed a race condition in which the KF update loop and the radar data callback were in a race condition, with the number of KFs possibly changing during processing of new incoming data. Added a mutex to synchronize these functions, however the downside is potentially slower processing speed due to blocking waits for mutex unlocks in the data callback. Should be fine for small numbers of KFs.
- Fix broken radar to point cloud conversion node
- Minor, change passthrough filter default field
- Add example launch for radar combine filter usage Added a launch file example for using the radar combine filter to sync three RadarTargetArray topics. Note that the topic names must be set as an arg and passed in through rosparam due to the parameter being a list of strings. Also note that the "slop" factor in message syncing has its default set in the cfg/ file and can be loaded using the usual dynamic reconfigure loader.
- Add up to 8 synchronized topics in combine filter Added the ability to synchronize up to 8 RadarTargetArray topics in the combine filter. In theory the approximate time synchronizer in ROS can support 9 topics, HOWEVER boost::bind (which is used to register the callback) only supports 9 total arguments, the first of which in this case must be the "this" pointer because we bind a class member function here (see https://www.boost.org/doc/libs/1_45_0/libs/bind/bind.html#NumberOfArguments) The ability to synchronize radar topics beyond 3 has not been tested with data (only checked for compilation).
- Merge branch 'master' of https://github.com/AinsteinAI/ainstein_radar
- Minor, add dynconfig update to combine filter
- Minor, needed to negate speed for K79-3D using new SNR firmware
- Refactor to clean up combine filter callbacks Refactored the combine filter's callbacks to use one central callback which works for any number of topics. This cleans up the overloaded callbacks a bit before adding the callbacks for >3 topics (to come next).
- Minor, refactor combine topic names for consistency
- Refactor combine filter for 2 or 3 topics via param Refactored the radar combine filter to approximately sync 2 or 3 topics by reading in a list of topic names and calling appropriate templated functions for setting up the time synchronizer and registering callback functions for each. This is not very clear but since the time sync variables are templated on the exact number of topics, the use of pre-defined templated variables for each number of topics seems
File truncated at 100 lines see the full file
Wiki Tutorials
Package Dependencies
System Dependencies
Dependant Packages
Launch files
- launch/k79_people_tracking.launch
- launch/o79_can_people_tracking.launch
- launch/o79_single_point_cloud_debug.launch
- launch/radar_combine_filter.launch
-
- topic_names [default: [/radar1/targets/raw,/radar2/targets/raw,/radar3/targets/raw]]
Messages
Services
Recent questions tagged ainstein_radar_filters at Robotics Stack Exchange
![]() |
ainstein_radar_filters package from ainstein_radar repoainstein_radar ainstein_radar_drivers ainstein_radar_filters ainstein_radar_gazebo_plugins ainstein_radar_msgs ainstein_radar_rviz_plugins ainstein_radar_tools |
ROS Distro
|
Package Summary
Tags | No category tags. |
Version | 3.0.1 |
License | BSD |
Build type | CATKIN |
Use | RECOMMENDED |
Repository Summary
Checkout URI | https://github.com/AinsteinAI/ainstein_radar.git |
VCS Type | git |
VCS Version | master |
Last Updated | 2024-02-26 |
Dev Status | MAINTAINED |
CI status | Continuous Integration |
Released | RELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Package Description
Additional Links
Maintainers
- Nick Rotella
Authors
- Nick Rotella
Changelog for package ainstein_radar_filters
3.0.1 (2020-02-11)
- Minor, add missing dependency
- Contributors: Nick Rotella
3.0.0 (2020-02-06)
- Add Cartesian tracking filter tracked pose output Added publishing of tracked object poses as geometry_msgs/PoseArray msg populated from tracked Cartesian position and using Cartesian velocity to determine pose. Forward direction (+x) is defined by tracked 3d velocity direction, with other axes determined by completing a right handed frame with +z up. Unfortunately, velocities cannot be published themselves without defining a custom TwistArray message, but nothing similar is supported natively in eg RViz.
- Update Cartesian tracking filter, fix bugs and tune Updated the Cartesian tracking filter to use the measured position instead of measured unit direction, since we can measure range with most radars. Fixed other bugs in implementation and got working. Tuned resulting filter parameters to get decent tracking, now working similarly to old tracking filter (in spherical coordinates). Still need to add full Pose and Twist output; currently converting to RadarTarget for backwards-compatibility with other radar filters.
- Minor, remove outdated filter config
- Add Cartesian tracking filter, needs debugging Added a Cartesian coordinates tracking filter for radar data which stores object state as Cartesian position and velocity rather than spherical coordinate range/angles/speed. The advantage is that we can track the full Cartesian velocity by using information from the radar speed measurement (which is a projection onto the radian direction) and consecutive range/angle measurements. This unfortunately makes the KF into an EKF because the measurements are now nonlinear in Cartesian space. The filter compiles and runs but never outputs tracked targets in its current state, and thus needs debugging. Since the RadarTarget datatype is not capable of storing full 3d velocity anyway, we need to output eg Pose and Twist types instead. Since the filter stores uncertainty, we can use PoseWithCovarianceStamped and TwistWithCovarianceStamped.
- Add support for point cloud input to radar tracking Added the ability for the radar tracking filter to subscribe to either a RadarTargetArray or PointCloud2 message. Internally, subscribing to a point cloud message converts to radar message type and then calls the original radar callback. This was added for portability since radar and point cloud messages are used with radar sensors often interchangeably.
- Minor, explicitly copy header in conversion
- Minor, remove outdated nodelet plugin
- Merge branch 'master' of https://github.com/AinsteinAI/ainstein_radar
- Update combine filter example launch and fix bug Updated the radar combine filter example launch file in the ainstein_radar_filters package to show how to launch three K79 radars and run the combine filter. Also fixed a bug in which the dynamic configuration was set for all possible numbers of radars which caused runtime errors because only one of the time sync objects was valid. Now checking the number of topics and only setting that object.
- Fix race condition in KF-based tracking filter Fixed a race condition in which the KF update loop and the radar data callback were in a race condition, with the number of KFs possibly changing during processing of new incoming data. Added a mutex to synchronize these functions, however the downside is potentially slower processing speed due to blocking waits for mutex unlocks in the data callback. Should be fine for small numbers of KFs.
- Fix broken radar to point cloud conversion node
- Minor, change passthrough filter default field
- Add example launch for radar combine filter usage Added a launch file example for using the radar combine filter to sync three RadarTargetArray topics. Note that the topic names must be set as an arg and passed in through rosparam due to the parameter being a list of strings. Also note that the "slop" factor in message syncing has its default set in the cfg/ file and can be loaded using the usual dynamic reconfigure loader.
- Add up to 8 synchronized topics in combine filter Added the ability to synchronize up to 8 RadarTargetArray topics in the combine filter. In theory the approximate time synchronizer in ROS can support 9 topics, HOWEVER boost::bind (which is used to register the callback) only supports 9 total arguments, the first of which in this case must be the "this" pointer because we bind a class member function here (see https://www.boost.org/doc/libs/1_45_0/libs/bind/bind.html#NumberOfArguments) The ability to synchronize radar topics beyond 3 has not been tested with data (only checked for compilation).
- Merge branch 'master' of https://github.com/AinsteinAI/ainstein_radar
- Minor, add dynconfig update to combine filter
- Minor, needed to negate speed for K79-3D using new SNR firmware
- Refactor to clean up combine filter callbacks Refactored the combine filter's callbacks to use one central callback which works for any number of topics. This cleans up the overloaded callbacks a bit before adding the callbacks for >3 topics (to come next).
- Minor, refactor combine topic names for consistency
- Refactor combine filter for 2 or 3 topics via param Refactored the radar combine filter to approximately sync 2 or 3 topics by reading in a list of topic names and calling appropriate templated functions for setting up the time synchronizer and registering callback functions for each. This is not very clear but since the time sync variables are templated on the exact number of topics, the use of pre-defined templated variables for each number of topics seems
File truncated at 100 lines see the full file
Wiki Tutorials
Package Dependencies
System Dependencies
Dependant Packages
Launch files
- launch/k79_people_tracking.launch
- launch/o79_can_people_tracking.launch
- launch/o79_single_point_cloud_debug.launch
- launch/radar_combine_filter.launch
-
- topic_names [default: [/radar1/targets/raw,/radar2/targets/raw,/radar3/targets/raw]]
Messages
Services
Recent questions tagged ainstein_radar_filters at Robotics Stack Exchange
![]() |
ainstein_radar_filters package from ainstein_radar repoainstein_radar ainstein_radar_drivers ainstein_radar_filters ainstein_radar_gazebo_plugins ainstein_radar_msgs ainstein_radar_rviz_plugins ainstein_radar_tools |
ROS Distro
|
Package Summary
Tags | No category tags. |
Version | 3.0.1 |
License | BSD |
Build type | CATKIN |
Use | RECOMMENDED |
Repository Summary
Checkout URI | https://github.com/AinsteinAI/ainstein_radar.git |
VCS Type | git |
VCS Version | master |
Last Updated | 2024-02-26 |
Dev Status | MAINTAINED |
CI status | Continuous Integration |
Released | RELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Package Description
Additional Links
Maintainers
- Nick Rotella
Authors
- Nick Rotella
Changelog for package ainstein_radar_filters
3.0.1 (2020-02-11)
- Minor, add missing dependency
- Contributors: Nick Rotella
3.0.0 (2020-02-06)
- Add Cartesian tracking filter tracked pose output Added publishing of tracked object poses as geometry_msgs/PoseArray msg populated from tracked Cartesian position and using Cartesian velocity to determine pose. Forward direction (+x) is defined by tracked 3d velocity direction, with other axes determined by completing a right handed frame with +z up. Unfortunately, velocities cannot be published themselves without defining a custom TwistArray message, but nothing similar is supported natively in eg RViz.
- Update Cartesian tracking filter, fix bugs and tune Updated the Cartesian tracking filter to use the measured position instead of measured unit direction, since we can measure range with most radars. Fixed other bugs in implementation and got working. Tuned resulting filter parameters to get decent tracking, now working similarly to old tracking filter (in spherical coordinates). Still need to add full Pose and Twist output; currently converting to RadarTarget for backwards-compatibility with other radar filters.
- Minor, remove outdated filter config
- Add Cartesian tracking filter, needs debugging Added a Cartesian coordinates tracking filter for radar data which stores object state as Cartesian position and velocity rather than spherical coordinate range/angles/speed. The advantage is that we can track the full Cartesian velocity by using information from the radar speed measurement (which is a projection onto the radian direction) and consecutive range/angle measurements. This unfortunately makes the KF into an EKF because the measurements are now nonlinear in Cartesian space. The filter compiles and runs but never outputs tracked targets in its current state, and thus needs debugging. Since the RadarTarget datatype is not capable of storing full 3d velocity anyway, we need to output eg Pose and Twist types instead. Since the filter stores uncertainty, we can use PoseWithCovarianceStamped and TwistWithCovarianceStamped.
- Add support for point cloud input to radar tracking Added the ability for the radar tracking filter to subscribe to either a RadarTargetArray or PointCloud2 message. Internally, subscribing to a point cloud message converts to radar message type and then calls the original radar callback. This was added for portability since radar and point cloud messages are used with radar sensors often interchangeably.
- Minor, explicitly copy header in conversion
- Minor, remove outdated nodelet plugin
- Merge branch 'master' of https://github.com/AinsteinAI/ainstein_radar
- Update combine filter example launch and fix bug Updated the radar combine filter example launch file in the ainstein_radar_filters package to show how to launch three K79 radars and run the combine filter. Also fixed a bug in which the dynamic configuration was set for all possible numbers of radars which caused runtime errors because only one of the time sync objects was valid. Now checking the number of topics and only setting that object.
- Fix race condition in KF-based tracking filter Fixed a race condition in which the KF update loop and the radar data callback were in a race condition, with the number of KFs possibly changing during processing of new incoming data. Added a mutex to synchronize these functions, however the downside is potentially slower processing speed due to blocking waits for mutex unlocks in the data callback. Should be fine for small numbers of KFs.
- Fix broken radar to point cloud conversion node
- Minor, change passthrough filter default field
- Add example launch for radar combine filter usage Added a launch file example for using the radar combine filter to sync three RadarTargetArray topics. Note that the topic names must be set as an arg and passed in through rosparam due to the parameter being a list of strings. Also note that the "slop" factor in message syncing has its default set in the cfg/ file and can be loaded using the usual dynamic reconfigure loader.
- Add up to 8 synchronized topics in combine filter Added the ability to synchronize up to 8 RadarTargetArray topics in the combine filter. In theory the approximate time synchronizer in ROS can support 9 topics, HOWEVER boost::bind (which is used to register the callback) only supports 9 total arguments, the first of which in this case must be the "this" pointer because we bind a class member function here (see https://www.boost.org/doc/libs/1_45_0/libs/bind/bind.html#NumberOfArguments) The ability to synchronize radar topics beyond 3 has not been tested with data (only checked for compilation).
- Merge branch 'master' of https://github.com/AinsteinAI/ainstein_radar
- Minor, add dynconfig update to combine filter
- Minor, needed to negate speed for K79-3D using new SNR firmware
- Refactor to clean up combine filter callbacks Refactored the combine filter's callbacks to use one central callback which works for any number of topics. This cleans up the overloaded callbacks a bit before adding the callbacks for >3 topics (to come next).
- Minor, refactor combine topic names for consistency
- Refactor combine filter for 2 or 3 topics via param Refactored the radar combine filter to approximately sync 2 or 3 topics by reading in a list of topic names and calling appropriate templated functions for setting up the time synchronizer and registering callback functions for each. This is not very clear but since the time sync variables are templated on the exact number of topics, the use of pre-defined templated variables for each number of topics seems
File truncated at 100 lines see the full file
Wiki Tutorials
Package Dependencies
System Dependencies
Dependant Packages
Launch files
- launch/k79_people_tracking.launch
- launch/o79_can_people_tracking.launch
- launch/o79_single_point_cloud_debug.launch
- launch/radar_combine_filter.launch
-
- topic_names [default: [/radar1/targets/raw,/radar2/targets/raw,/radar3/targets/raw]]
Messages
Services
Recent questions tagged ainstein_radar_filters at Robotics Stack Exchange
![]() |
ainstein_radar_filters package from ainstein_radar repoainstein_radar ainstein_radar_drivers ainstein_radar_filters ainstein_radar_gazebo_plugins ainstein_radar_msgs ainstein_radar_rviz_plugins ainstein_radar_tools |
ROS Distro
|
Package Summary
Tags | No category tags. |
Version | 3.0.1 |
License | BSD |
Build type | CATKIN |
Use | RECOMMENDED |
Repository Summary
Checkout URI | https://github.com/AinsteinAI/ainstein_radar.git |
VCS Type | git |
VCS Version | master |
Last Updated | 2024-02-26 |
Dev Status | MAINTAINED |
CI status | Continuous Integration |
Released | RELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Package Description
Additional Links
Maintainers
- Nick Rotella
Authors
- Nick Rotella
Changelog for package ainstein_radar_filters
3.0.1 (2020-02-11)
- Minor, add missing dependency
- Contributors: Nick Rotella
3.0.0 (2020-02-06)
- Add Cartesian tracking filter tracked pose output Added publishing of tracked object poses as geometry_msgs/PoseArray msg populated from tracked Cartesian position and using Cartesian velocity to determine pose. Forward direction (+x) is defined by tracked 3d velocity direction, with other axes determined by completing a right handed frame with +z up. Unfortunately, velocities cannot be published themselves without defining a custom TwistArray message, but nothing similar is supported natively in eg RViz.
- Update Cartesian tracking filter, fix bugs and tune Updated the Cartesian tracking filter to use the measured position instead of measured unit direction, since we can measure range with most radars. Fixed other bugs in implementation and got working. Tuned resulting filter parameters to get decent tracking, now working similarly to old tracking filter (in spherical coordinates). Still need to add full Pose and Twist output; currently converting to RadarTarget for backwards-compatibility with other radar filters.
- Minor, remove outdated filter config
- Add Cartesian tracking filter, needs debugging Added a Cartesian coordinates tracking filter for radar data which stores object state as Cartesian position and velocity rather than spherical coordinate range/angles/speed. The advantage is that we can track the full Cartesian velocity by using information from the radar speed measurement (which is a projection onto the radian direction) and consecutive range/angle measurements. This unfortunately makes the KF into an EKF because the measurements are now nonlinear in Cartesian space. The filter compiles and runs but never outputs tracked targets in its current state, and thus needs debugging. Since the RadarTarget datatype is not capable of storing full 3d velocity anyway, we need to output eg Pose and Twist types instead. Since the filter stores uncertainty, we can use PoseWithCovarianceStamped and TwistWithCovarianceStamped.
- Add support for point cloud input to radar tracking Added the ability for the radar tracking filter to subscribe to either a RadarTargetArray or PointCloud2 message. Internally, subscribing to a point cloud message converts to radar message type and then calls the original radar callback. This was added for portability since radar and point cloud messages are used with radar sensors often interchangeably.
- Minor, explicitly copy header in conversion
- Minor, remove outdated nodelet plugin
- Merge branch 'master' of https://github.com/AinsteinAI/ainstein_radar
- Update combine filter example launch and fix bug Updated the radar combine filter example launch file in the ainstein_radar_filters package to show how to launch three K79 radars and run the combine filter. Also fixed a bug in which the dynamic configuration was set for all possible numbers of radars which caused runtime errors because only one of the time sync objects was valid. Now checking the number of topics and only setting that object.
- Fix race condition in KF-based tracking filter Fixed a race condition in which the KF update loop and the radar data callback were in a race condition, with the number of KFs possibly changing during processing of new incoming data. Added a mutex to synchronize these functions, however the downside is potentially slower processing speed due to blocking waits for mutex unlocks in the data callback. Should be fine for small numbers of KFs.
- Fix broken radar to point cloud conversion node
- Minor, change passthrough filter default field
- Add example launch for radar combine filter usage Added a launch file example for using the radar combine filter to sync three RadarTargetArray topics. Note that the topic names must be set as an arg and passed in through rosparam due to the parameter being a list of strings. Also note that the "slop" factor in message syncing has its default set in the cfg/ file and can be loaded using the usual dynamic reconfigure loader.
- Add up to 8 synchronized topics in combine filter Added the ability to synchronize up to 8 RadarTargetArray topics in the combine filter. In theory the approximate time synchronizer in ROS can support 9 topics, HOWEVER boost::bind (which is used to register the callback) only supports 9 total arguments, the first of which in this case must be the "this" pointer because we bind a class member function here (see https://www.boost.org/doc/libs/1_45_0/libs/bind/bind.html#NumberOfArguments) The ability to synchronize radar topics beyond 3 has not been tested with data (only checked for compilation).
- Merge branch 'master' of https://github.com/AinsteinAI/ainstein_radar
- Minor, add dynconfig update to combine filter
- Minor, needed to negate speed for K79-3D using new SNR firmware
- Refactor to clean up combine filter callbacks Refactored the combine filter's callbacks to use one central callback which works for any number of topics. This cleans up the overloaded callbacks a bit before adding the callbacks for >3 topics (to come next).
- Minor, refactor combine topic names for consistency
- Refactor combine filter for 2 or 3 topics via param Refactored the radar combine filter to approximately sync 2 or 3 topics by reading in a list of topic names and calling appropriate templated functions for setting up the time synchronizer and registering callback functions for each. This is not very clear but since the time sync variables are templated on the exact number of topics, the use of pre-defined templated variables for each number of topics seems
File truncated at 100 lines see the full file
Wiki Tutorials
Package Dependencies
System Dependencies
Dependant Packages
Launch files
- launch/k79_people_tracking.launch
- launch/o79_can_people_tracking.launch
- launch/o79_single_point_cloud_debug.launch
- launch/radar_combine_filter.launch
-
- topic_names [default: [/radar1/targets/raw,/radar2/targets/raw,/radar3/targets/raw]]
Messages
Services
Recent questions tagged ainstein_radar_filters at Robotics Stack Exchange
![]() |
ainstein_radar_filters package from ainstein_radar repoainstein_radar ainstein_radar_drivers ainstein_radar_filters ainstein_radar_gazebo_plugins ainstein_radar_msgs ainstein_radar_rviz_plugins ainstein_radar_tools |
ROS Distro
|
Package Summary
Tags | No category tags. |
Version | 3.0.1 |
License | BSD |
Build type | CATKIN |
Use | RECOMMENDED |
Repository Summary
Checkout URI | https://github.com/AinsteinAI/ainstein_radar.git |
VCS Type | git |
VCS Version | master |
Last Updated | 2024-02-26 |
Dev Status | MAINTAINED |
CI status | Continuous Integration |
Released | RELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Package Description
Additional Links
Maintainers
- Nick Rotella
Authors
- Nick Rotella
Changelog for package ainstein_radar_filters
3.0.1 (2020-02-11)
- Minor, add missing dependency
- Contributors: Nick Rotella
3.0.0 (2020-02-06)
- Add Cartesian tracking filter tracked pose output Added publishing of tracked object poses as geometry_msgs/PoseArray msg populated from tracked Cartesian position and using Cartesian velocity to determine pose. Forward direction (+x) is defined by tracked 3d velocity direction, with other axes determined by completing a right handed frame with +z up. Unfortunately, velocities cannot be published themselves without defining a custom TwistArray message, but nothing similar is supported natively in eg RViz.
- Update Cartesian tracking filter, fix bugs and tune Updated the Cartesian tracking filter to use the measured position instead of measured unit direction, since we can measure range with most radars. Fixed other bugs in implementation and got working. Tuned resulting filter parameters to get decent tracking, now working similarly to old tracking filter (in spherical coordinates). Still need to add full Pose and Twist output; currently converting to RadarTarget for backwards-compatibility with other radar filters.
- Minor, remove outdated filter config
- Add Cartesian tracking filter, needs debugging Added a Cartesian coordinates tracking filter for radar data which stores object state as Cartesian position and velocity rather than spherical coordinate range/angles/speed. The advantage is that we can track the full Cartesian velocity by using information from the radar speed measurement (which is a projection onto the radian direction) and consecutive range/angle measurements. This unfortunately makes the KF into an EKF because the measurements are now nonlinear in Cartesian space. The filter compiles and runs but never outputs tracked targets in its current state, and thus needs debugging. Since the RadarTarget datatype is not capable of storing full 3d velocity anyway, we need to output eg Pose and Twist types instead. Since the filter stores uncertainty, we can use PoseWithCovarianceStamped and TwistWithCovarianceStamped.
- Add support for point cloud input to radar tracking Added the ability for the radar tracking filter to subscribe to either a RadarTargetArray or PointCloud2 message. Internally, subscribing to a point cloud message converts to radar message type and then calls the original radar callback. This was added for portability since radar and point cloud messages are used with radar sensors often interchangeably.
- Minor, explicitly copy header in conversion
- Minor, remove outdated nodelet plugin
- Merge branch 'master' of https://github.com/AinsteinAI/ainstein_radar
- Update combine filter example launch and fix bug Updated the radar combine filter example launch file in the ainstein_radar_filters package to show how to launch three K79 radars and run the combine filter. Also fixed a bug in which the dynamic configuration was set for all possible numbers of radars which caused runtime errors because only one of the time sync objects was valid. Now checking the number of topics and only setting that object.
- Fix race condition in KF-based tracking filter Fixed a race condition in which the KF update loop and the radar data callback were in a race condition, with the number of KFs possibly changing during processing of new incoming data. Added a mutex to synchronize these functions, however the downside is potentially slower processing speed due to blocking waits for mutex unlocks in the data callback. Should be fine for small numbers of KFs.
- Fix broken radar to point cloud conversion node
- Minor, change passthrough filter default field
- Add example launch for radar combine filter usage Added a launch file example for using the radar combine filter to sync three RadarTargetArray topics. Note that the topic names must be set as an arg and passed in through rosparam due to the parameter being a list of strings. Also note that the "slop" factor in message syncing has its default set in the cfg/ file and can be loaded using the usual dynamic reconfigure loader.
- Add up to 8 synchronized topics in combine filter Added the ability to synchronize up to 8 RadarTargetArray topics in the combine filter. In theory the approximate time synchronizer in ROS can support 9 topics, HOWEVER boost::bind (which is used to register the callback) only supports 9 total arguments, the first of which in this case must be the "this" pointer because we bind a class member function here (see https://www.boost.org/doc/libs/1_45_0/libs/bind/bind.html#NumberOfArguments) The ability to synchronize radar topics beyond 3 has not been tested with data (only checked for compilation).
- Merge branch 'master' of https://github.com/AinsteinAI/ainstein_radar
- Minor, add dynconfig update to combine filter
- Minor, needed to negate speed for K79-3D using new SNR firmware
- Refactor to clean up combine filter callbacks Refactored the combine filter's callbacks to use one central callback which works for any number of topics. This cleans up the overloaded callbacks a bit before adding the callbacks for >3 topics (to come next).
- Minor, refactor combine topic names for consistency
- Refactor combine filter for 2 or 3 topics via param Refactored the radar combine filter to approximately sync 2 or 3 topics by reading in a list of topic names and calling appropriate templated functions for setting up the time synchronizer and registering callback functions for each. This is not very clear but since the time sync variables are templated on the exact number of topics, the use of pre-defined templated variables for each number of topics seems
File truncated at 100 lines see the full file
Wiki Tutorials
Package Dependencies
System Dependencies
Dependant Packages
Launch files
- launch/k79_people_tracking.launch
- launch/o79_can_people_tracking.launch
- launch/o79_single_point_cloud_debug.launch
- launch/radar_combine_filter.launch
-
- topic_names [default: [/radar1/targets/raw,/radar2/targets/raw,/radar3/targets/raw]]
Messages
Services
Recent questions tagged ainstein_radar_filters at Robotics Stack Exchange
![]() |
ainstein_radar_filters package from ainstein_radar repoainstein_radar ainstein_radar_drivers ainstein_radar_filters ainstein_radar_gazebo_plugins ainstein_radar_msgs ainstein_radar_rviz_plugins ainstein_radar_tools |
ROS Distro
|
Package Summary
Tags | No category tags. |
Version | 3.0.1 |
License | BSD |
Build type | CATKIN |
Use | RECOMMENDED |
Repository Summary
Checkout URI | https://github.com/AinsteinAI/ainstein_radar.git |
VCS Type | git |
VCS Version | master |
Last Updated | 2024-02-26 |
Dev Status | MAINTAINED |
CI status | Continuous Integration |
Released | RELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Package Description
Additional Links
Maintainers
- Nick Rotella
Authors
- Nick Rotella
Changelog for package ainstein_radar_filters
3.0.1 (2020-02-11)
- Minor, add missing dependency
- Contributors: Nick Rotella
3.0.0 (2020-02-06)
- Add Cartesian tracking filter tracked pose output Added publishing of tracked object poses as geometry_msgs/PoseArray msg populated from tracked Cartesian position and using Cartesian velocity to determine pose. Forward direction (+x) is defined by tracked 3d velocity direction, with other axes determined by completing a right handed frame with +z up. Unfortunately, velocities cannot be published themselves without defining a custom TwistArray message, but nothing similar is supported natively in eg RViz.
- Update Cartesian tracking filter, fix bugs and tune Updated the Cartesian tracking filter to use the measured position instead of measured unit direction, since we can measure range with most radars. Fixed other bugs in implementation and got working. Tuned resulting filter parameters to get decent tracking, now working similarly to old tracking filter (in spherical coordinates). Still need to add full Pose and Twist output; currently converting to RadarTarget for backwards-compatibility with other radar filters.
- Minor, remove outdated filter config
- Add Cartesian tracking filter, needs debugging Added a Cartesian coordinates tracking filter for radar data which stores object state as Cartesian position and velocity rather than spherical coordinate range/angles/speed. The advantage is that we can track the full Cartesian velocity by using information from the radar speed measurement (which is a projection onto the radian direction) and consecutive range/angle measurements. This unfortunately makes the KF into an EKF because the measurements are now nonlinear in Cartesian space. The filter compiles and runs but never outputs tracked targets in its current state, and thus needs debugging. Since the RadarTarget datatype is not capable of storing full 3d velocity anyway, we need to output eg Pose and Twist types instead. Since the filter stores uncertainty, we can use PoseWithCovarianceStamped and TwistWithCovarianceStamped.
- Add support for point cloud input to radar tracking Added the ability for the radar tracking filter to subscribe to either a RadarTargetArray or PointCloud2 message. Internally, subscribing to a point cloud message converts to radar message type and then calls the original radar callback. This was added for portability since radar and point cloud messages are used with radar sensors often interchangeably.
- Minor, explicitly copy header in conversion
- Minor, remove outdated nodelet plugin
- Merge branch 'master' of https://github.com/AinsteinAI/ainstein_radar
- Update combine filter example launch and fix bug Updated the radar combine filter example launch file in the ainstein_radar_filters package to show how to launch three K79 radars and run the combine filter. Also fixed a bug in which the dynamic configuration was set for all possible numbers of radars which caused runtime errors because only one of the time sync objects was valid. Now checking the number of topics and only setting that object.
- Fix race condition in KF-based tracking filter Fixed a race condition in which the KF update loop and the radar data callback were in a race condition, with the number of KFs possibly changing during processing of new incoming data. Added a mutex to synchronize these functions, however the downside is potentially slower processing speed due to blocking waits for mutex unlocks in the data callback. Should be fine for small numbers of KFs.
- Fix broken radar to point cloud conversion node
- Minor, change passthrough filter default field
- Add example launch for radar combine filter usage Added a launch file example for using the radar combine filter to sync three RadarTargetArray topics. Note that the topic names must be set as an arg and passed in through rosparam due to the parameter being a list of strings. Also note that the "slop" factor in message syncing has its default set in the cfg/ file and can be loaded using the usual dynamic reconfigure loader.
- Add up to 8 synchronized topics in combine filter Added the ability to synchronize up to 8 RadarTargetArray topics in the combine filter. In theory the approximate time synchronizer in ROS can support 9 topics, HOWEVER boost::bind (which is used to register the callback) only supports 9 total arguments, the first of which in this case must be the "this" pointer because we bind a class member function here (see https://www.boost.org/doc/libs/1_45_0/libs/bind/bind.html#NumberOfArguments) The ability to synchronize radar topics beyond 3 has not been tested with data (only checked for compilation).
- Merge branch 'master' of https://github.com/AinsteinAI/ainstein_radar
- Minor, add dynconfig update to combine filter
- Minor, needed to negate speed for K79-3D using new SNR firmware
- Refactor to clean up combine filter callbacks Refactored the combine filter's callbacks to use one central callback which works for any number of topics. This cleans up the overloaded callbacks a bit before adding the callbacks for >3 topics (to come next).
- Minor, refactor combine topic names for consistency
- Refactor combine filter for 2 or 3 topics via param Refactored the radar combine filter to approximately sync 2 or 3 topics by reading in a list of topic names and calling appropriate templated functions for setting up the time synchronizer and registering callback functions for each. This is not very clear but since the time sync variables are templated on the exact number of topics, the use of pre-defined templated variables for each number of topics seems
File truncated at 100 lines see the full file
Wiki Tutorials
Package Dependencies
System Dependencies
Dependant Packages
Launch files
- launch/k79_people_tracking.launch
- launch/o79_can_people_tracking.launch
- launch/o79_single_point_cloud_debug.launch
- launch/radar_combine_filter.launch
-
- topic_names [default: [/radar1/targets/raw,/radar2/targets/raw,/radar3/targets/raw]]
Messages
Services
Recent questions tagged ainstein_radar_filters at Robotics Stack Exchange
![]() |
ainstein_radar_filters package from ainstein_radar repoainstein_radar ainstein_radar_drivers ainstein_radar_filters ainstein_radar_gazebo_plugins ainstein_radar_msgs ainstein_radar_rviz_plugins ainstein_radar_tools |
ROS Distro
|
Package Summary
Tags | No category tags. |
Version | 3.0.1 |
License | BSD |
Build type | CATKIN |
Use | RECOMMENDED |
Repository Summary
Checkout URI | https://github.com/AinsteinAI/ainstein_radar.git |
VCS Type | git |
VCS Version | master |
Last Updated | 2024-02-26 |
Dev Status | MAINTAINED |
CI status | Continuous Integration |
Released | RELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Package Description
Additional Links
Maintainers
- Nick Rotella
Authors
- Nick Rotella
Changelog for package ainstein_radar_filters
3.0.1 (2020-02-11)
- Minor, add missing dependency
- Contributors: Nick Rotella
3.0.0 (2020-02-06)
- Add Cartesian tracking filter tracked pose output Added publishing of tracked object poses as geometry_msgs/PoseArray msg populated from tracked Cartesian position and using Cartesian velocity to determine pose. Forward direction (+x) is defined by tracked 3d velocity direction, with other axes determined by completing a right handed frame with +z up. Unfortunately, velocities cannot be published themselves without defining a custom TwistArray message, but nothing similar is supported natively in eg RViz.
- Update Cartesian tracking filter, fix bugs and tune Updated the Cartesian tracking filter to use the measured position instead of measured unit direction, since we can measure range with most radars. Fixed other bugs in implementation and got working. Tuned resulting filter parameters to get decent tracking, now working similarly to old tracking filter (in spherical coordinates). Still need to add full Pose and Twist output; currently converting to RadarTarget for backwards-compatibility with other radar filters.
- Minor, remove outdated filter config
- Add Cartesian tracking filter, needs debugging Added a Cartesian coordinates tracking filter for radar data which stores object state as Cartesian position and velocity rather than spherical coordinate range/angles/speed. The advantage is that we can track the full Cartesian velocity by using information from the radar speed measurement (which is a projection onto the radian direction) and consecutive range/angle measurements. This unfortunately makes the KF into an EKF because the measurements are now nonlinear in Cartesian space. The filter compiles and runs but never outputs tracked targets in its current state, and thus needs debugging. Since the RadarTarget datatype is not capable of storing full 3d velocity anyway, we need to output eg Pose and Twist types instead. Since the filter stores uncertainty, we can use PoseWithCovarianceStamped and TwistWithCovarianceStamped.
- Add support for point cloud input to radar tracking Added the ability for the radar tracking filter to subscribe to either a RadarTargetArray or PointCloud2 message. Internally, subscribing to a point cloud message converts to radar message type and then calls the original radar callback. This was added for portability since radar and point cloud messages are used with radar sensors often interchangeably.
- Minor, explicitly copy header in conversion
- Minor, remove outdated nodelet plugin
- Merge branch 'master' of https://github.com/AinsteinAI/ainstein_radar
- Update combine filter example launch and fix bug Updated the radar combine filter example launch file in the ainstein_radar_filters package to show how to launch three K79 radars and run the combine filter. Also fixed a bug in which the dynamic configuration was set for all possible numbers of radars which caused runtime errors because only one of the time sync objects was valid. Now checking the number of topics and only setting that object.
- Fix race condition in KF-based tracking filter Fixed a race condition in which the KF update loop and the radar data callback were in a race condition, with the number of KFs possibly changing during processing of new incoming data. Added a mutex to synchronize these functions, however the downside is potentially slower processing speed due to blocking waits for mutex unlocks in the data callback. Should be fine for small numbers of KFs.
- Fix broken radar to point cloud conversion node
- Minor, change passthrough filter default field
- Add example launch for radar combine filter usage Added a launch file example for using the radar combine filter to sync three RadarTargetArray topics. Note that the topic names must be set as an arg and passed in through rosparam due to the parameter being a list of strings. Also note that the "slop" factor in message syncing has its default set in the cfg/ file and can be loaded using the usual dynamic reconfigure loader.
- Add up to 8 synchronized topics in combine filter Added the ability to synchronize up to 8 RadarTargetArray topics in the combine filter. In theory the approximate time synchronizer in ROS can support 9 topics, HOWEVER boost::bind (which is used to register the callback) only supports 9 total arguments, the first of which in this case must be the "this" pointer because we bind a class member function here (see https://www.boost.org/doc/libs/1_45_0/libs/bind/bind.html#NumberOfArguments) The ability to synchronize radar topics beyond 3 has not been tested with data (only checked for compilation).
- Merge branch 'master' of https://github.com/AinsteinAI/ainstein_radar
- Minor, add dynconfig update to combine filter
- Minor, needed to negate speed for K79-3D using new SNR firmware
- Refactor to clean up combine filter callbacks Refactored the combine filter's callbacks to use one central callback which works for any number of topics. This cleans up the overloaded callbacks a bit before adding the callbacks for >3 topics (to come next).
- Minor, refactor combine topic names for consistency
- Refactor combine filter for 2 or 3 topics via param Refactored the radar combine filter to approximately sync 2 or 3 topics by reading in a list of topic names and calling appropriate templated functions for setting up the time synchronizer and registering callback functions for each. This is not very clear but since the time sync variables are templated on the exact number of topics, the use of pre-defined templated variables for each number of topics seems
File truncated at 100 lines see the full file
Wiki Tutorials
Package Dependencies
System Dependencies
Dependant Packages
Launch files
- launch/k79_people_tracking.launch
- launch/o79_can_people_tracking.launch
- launch/o79_single_point_cloud_debug.launch
- launch/radar_combine_filter.launch
-
- topic_names [default: [/radar1/targets/raw,/radar2/targets/raw,/radar3/targets/raw]]
Messages
Services
Recent questions tagged ainstein_radar_filters at Robotics Stack Exchange
![]() |
ainstein_radar_filters package from ainstein_radar repoainstein_radar ainstein_radar_drivers ainstein_radar_filters ainstein_radar_gazebo_plugins ainstein_radar_msgs ainstein_radar_rviz_plugins ainstein_radar_tools |
ROS Distro
|
Package Summary
Tags | No category tags. |
Version | 3.0.1 |
License | BSD |
Build type | CATKIN |
Use | RECOMMENDED |
Repository Summary
Checkout URI | https://github.com/AinsteinAI/ainstein_radar.git |
VCS Type | git |
VCS Version | master |
Last Updated | 2024-02-26 |
Dev Status | MAINTAINED |
CI status | Continuous Integration : 0 / 0 |
Released | RELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Package Description
Additional Links
Maintainers
- Nick Rotella
Authors
- Nick Rotella
Changelog for package ainstein_radar_filters
3.0.1 (2020-02-11)
- Minor, add missing dependency
- Contributors: Nick Rotella
3.0.0 (2020-02-06)
- Add Cartesian tracking filter tracked pose output Added publishing of tracked object poses as geometry_msgs/PoseArray msg populated from tracked Cartesian position and using Cartesian velocity to determine pose. Forward direction (+x) is defined by tracked 3d velocity direction, with other axes determined by completing a right handed frame with +z up. Unfortunately, velocities cannot be published themselves without defining a custom TwistArray message, but nothing similar is supported natively in eg RViz.
- Update Cartesian tracking filter, fix bugs and tune Updated the Cartesian tracking filter to use the measured position instead of measured unit direction, since we can measure range with most radars. Fixed other bugs in implementation and got working. Tuned resulting filter parameters to get decent tracking, now working similarly to old tracking filter (in spherical coordinates). Still need to add full Pose and Twist output; currently converting to RadarTarget for backwards-compatibility with other radar filters.
- Minor, remove outdated filter config
- Add Cartesian tracking filter, needs debugging Added a Cartesian coordinates tracking filter for radar data which stores object state as Cartesian position and velocity rather than spherical coordinate range/angles/speed. The advantage is that we can track the full Cartesian velocity by using information from the radar speed measurement (which is a projection onto the radian direction) and consecutive range/angle measurements. This unfortunately makes the KF into an EKF because the measurements are now nonlinear in Cartesian space. The filter compiles and runs but never outputs tracked targets in its current state, and thus needs debugging. Since the RadarTarget datatype is not capable of storing full 3d velocity anyway, we need to output eg Pose and Twist types instead. Since the filter stores uncertainty, we can use PoseWithCovarianceStamped and TwistWithCovarianceStamped.
- Add support for point cloud input to radar tracking Added the ability for the radar tracking filter to subscribe to either a RadarTargetArray or PointCloud2 message. Internally, subscribing to a point cloud message converts to radar message type and then calls the original radar callback. This was added for portability since radar and point cloud messages are used with radar sensors often interchangeably.
- Minor, explicitly copy header in conversion
- Minor, remove outdated nodelet plugin
- Merge branch 'master' of https://github.com/AinsteinAI/ainstein_radar
- Update combine filter example launch and fix bug Updated the radar combine filter example launch file in the ainstein_radar_filters package to show how to launch three K79 radars and run the combine filter. Also fixed a bug in which the dynamic configuration was set for all possible numbers of radars which caused runtime errors because only one of the time sync objects was valid. Now checking the number of topics and only setting that object.
- Fix race condition in KF-based tracking filter Fixed a race condition in which the KF update loop and the radar data callback were in a race condition, with the number of KFs possibly changing during processing of new incoming data. Added a mutex to synchronize these functions, however the downside is potentially slower processing speed due to blocking waits for mutex unlocks in the data callback. Should be fine for small numbers of KFs.
- Fix broken radar to point cloud conversion node
- Minor, change passthrough filter default field
- Add example launch for radar combine filter usage Added a launch file example for using the radar combine filter to sync three RadarTargetArray topics. Note that the topic names must be set as an arg and passed in through rosparam due to the parameter being a list of strings. Also note that the "slop" factor in message syncing has its default set in the cfg/ file and can be loaded using the usual dynamic reconfigure loader.
- Add up to 8 synchronized topics in combine filter Added the ability to synchronize up to 8 RadarTargetArray topics in the combine filter. In theory the approximate time synchronizer in ROS can support 9 topics, HOWEVER boost::bind (which is used to register the callback) only supports 9 total arguments, the first of which in this case must be the "this" pointer because we bind a class member function here (see https://www.boost.org/doc/libs/1_45_0/libs/bind/bind.html#NumberOfArguments) The ability to synchronize radar topics beyond 3 has not been tested with data (only checked for compilation).
- Merge branch 'master' of https://github.com/AinsteinAI/ainstein_radar
- Minor, add dynconfig update to combine filter
- Minor, needed to negate speed for K79-3D using new SNR firmware
- Refactor to clean up combine filter callbacks Refactored the combine filter's callbacks to use one central callback which works for any number of topics. This cleans up the overloaded callbacks a bit before adding the callbacks for >3 topics (to come next).
- Minor, refactor combine topic names for consistency
- Refactor combine filter for 2 or 3 topics via param Refactored the radar combine filter to approximately sync 2 or 3 topics by reading in a list of topic names and calling appropriate templated functions for setting up the time synchronizer and registering callback functions for each. This is not very clear but since the time sync variables are templated on the exact number of topics, the use of pre-defined templated variables for each number of topics seems
File truncated at 100 lines see the full file
Wiki Tutorials
Package Dependencies
System Dependencies
Dependant Packages
Launch files
- launch/k79_people_tracking.launch
- launch/o79_can_people_tracking.launch
- launch/o79_single_point_cloud_debug.launch
- launch/radar_combine_filter.launch
-
- topic_names [default: [/radar1/targets/raw,/radar2/targets/raw,/radar3/targets/raw]]
Messages
Services
Recent questions tagged ainstein_radar_filters at Robotics Stack Exchange
![]() |
ainstein_radar_filters package from ainstein_radar repoainstein_radar ainstein_radar_drivers ainstein_radar_filters ainstein_radar_gazebo_plugins ainstein_radar_msgs ainstein_radar_rviz_plugins ainstein_radar_tools |
ROS Distro
|
Package Summary
Tags | No category tags. |
Version | 3.0.1 |
License | BSD |
Build type | CATKIN |
Use | RECOMMENDED |
Repository Summary
Checkout URI | https://github.com/AinsteinAI/ainstein_radar.git |
VCS Type | git |
VCS Version | master |
Last Updated | 2024-02-26 |
Dev Status | MAINTAINED |
CI status | No Continuous Integration |
Released | UNRELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Package Description
Additional Links
Maintainers
- Nick Rotella
Authors
- Nick Rotella
Changelog for package ainstein_radar_filters
3.0.1 (2020-02-11)
- Minor, add missing dependency
- Contributors: Nick Rotella
3.0.0 (2020-02-06)
- Add Cartesian tracking filter tracked pose output Added publishing of tracked object poses as geometry_msgs/PoseArray msg populated from tracked Cartesian position and using Cartesian velocity to determine pose. Forward direction (+x) is defined by tracked 3d velocity direction, with other axes determined by completing a right handed frame with +z up. Unfortunately, velocities cannot be published themselves without defining a custom TwistArray message, but nothing similar is supported natively in eg RViz.
- Update Cartesian tracking filter, fix bugs and tune Updated the Cartesian tracking filter to use the measured position instead of measured unit direction, since we can measure range with most radars. Fixed other bugs in implementation and got working. Tuned resulting filter parameters to get decent tracking, now working similarly to old tracking filter (in spherical coordinates). Still need to add full Pose and Twist output; currently converting to RadarTarget for backwards-compatibility with other radar filters.
- Minor, remove outdated filter config
- Add Cartesian tracking filter, needs debugging Added a Cartesian coordinates tracking filter for radar data which stores object state as Cartesian position and velocity rather than spherical coordinate range/angles/speed. The advantage is that we can track the full Cartesian velocity by using information from the radar speed measurement (which is a projection onto the radian direction) and consecutive range/angle measurements. This unfortunately makes the KF into an EKF because the measurements are now nonlinear in Cartesian space. The filter compiles and runs but never outputs tracked targets in its current state, and thus needs debugging. Since the RadarTarget datatype is not capable of storing full 3d velocity anyway, we need to output eg Pose and Twist types instead. Since the filter stores uncertainty, we can use PoseWithCovarianceStamped and TwistWithCovarianceStamped.
- Add support for point cloud input to radar tracking Added the ability for the radar tracking filter to subscribe to either a RadarTargetArray or PointCloud2 message. Internally, subscribing to a point cloud message converts to radar message type and then calls the original radar callback. This was added for portability since radar and point cloud messages are used with radar sensors often interchangeably.
- Minor, explicitly copy header in conversion
- Minor, remove outdated nodelet plugin
- Merge branch 'master' of https://github.com/AinsteinAI/ainstein_radar
- Update combine filter example launch and fix bug Updated the radar combine filter example launch file in the ainstein_radar_filters package to show how to launch three K79 radars and run the combine filter. Also fixed a bug in which the dynamic configuration was set for all possible numbers of radars which caused runtime errors because only one of the time sync objects was valid. Now checking the number of topics and only setting that object.
- Fix race condition in KF-based tracking filter Fixed a race condition in which the KF update loop and the radar data callback were in a race condition, with the number of KFs possibly changing during processing of new incoming data. Added a mutex to synchronize these functions, however the downside is potentially slower processing speed due to blocking waits for mutex unlocks in the data callback. Should be fine for small numbers of KFs.
- Fix broken radar to point cloud conversion node
- Minor, change passthrough filter default field
- Add example launch for radar combine filter usage Added a launch file example for using the radar combine filter to sync three RadarTargetArray topics. Note that the topic names must be set as an arg and passed in through rosparam due to the parameter being a list of strings. Also note that the "slop" factor in message syncing has its default set in the cfg/ file and can be loaded using the usual dynamic reconfigure loader.
- Add up to 8 synchronized topics in combine filter Added the ability to synchronize up to 8 RadarTargetArray topics in the combine filter. In theory the approximate time synchronizer in ROS can support 9 topics, HOWEVER boost::bind (which is used to register the callback) only supports 9 total arguments, the first of which in this case must be the "this" pointer because we bind a class member function here (see https://www.boost.org/doc/libs/1_45_0/libs/bind/bind.html#NumberOfArguments) The ability to synchronize radar topics beyond 3 has not been tested with data (only checked for compilation).
- Merge branch 'master' of https://github.com/AinsteinAI/ainstein_radar
- Minor, add dynconfig update to combine filter
- Minor, needed to negate speed for K79-3D using new SNR firmware
- Refactor to clean up combine filter callbacks Refactored the combine filter's callbacks to use one central callback which works for any number of topics. This cleans up the overloaded callbacks a bit before adding the callbacks for >3 topics (to come next).
- Minor, refactor combine topic names for consistency
- Refactor combine filter for 2 or 3 topics via param Refactored the radar combine filter to approximately sync 2 or 3 topics by reading in a list of topic names and calling appropriate templated functions for setting up the time synchronizer and registering callback functions for each. This is not very clear but since the time sync variables are templated on the exact number of topics, the use of pre-defined templated variables for each number of topics seems
File truncated at 100 lines see the full file
Wiki Tutorials
Package Dependencies
System Dependencies
Dependant Packages
Launch files
- launch/k79_people_tracking.launch
- launch/o79_can_people_tracking.launch
- launch/o79_single_point_cloud_debug.launch
- launch/radar_combine_filter.launch
-
- topic_names [default: [/radar1/targets/raw,/radar2/targets/raw,/radar3/targets/raw]]