profile
viewpoint
Tom Moore ayrton04 Locus Robotics Edinburgh, United Kingdom

ayrton04/ros_comm 1

ROS communications-related packages, including core client libraries (roscpp, rospy, roslisp) and graph introspection tools (rostopic, rosnode, rosservice, rosparam).

ayrton04/slam_karto 1

ROS Wrapper and Node for OpenKarto

ayrton04/buildfarm_deployment_config 0

Example configuration for buildfarm_deployment repo

ayrton04/design 0

Design documentation for ROS 2.0 effort

ayrton04/ecl_core 0

A set of tools and interfaces extending the capabilities of c++ to provide a lightweight, consistent interface with a focus for control programming.

ayrton04/EmulationStation 0

A Fork of Emulation Station for RetroPie. Emulation Station is a flexible emulator front-end supporting keyboardless navigation and custom system themes.

ayrton04/gazebo_ros_pkgs 0

Wrappers, tools and additional API's for using ROS with Gazebo. Formally simulator_gazebo stack

ayrton04/genpy 0

genpy

ayrton04/geometry 0

Packages for common geometric calculations including the ROS transform library, "tf". Also includes ROS bindings for "bullet" physics engine and "kdl" kinematics/dynamics package.

issue commentcra-ros-pkg/robot_localization

Fusing the gps and imu datas, the z coordinate data he

Please post this questions on answers.ros.org.

keguo1119

comment created time in 10 days

issue closedcra-ros-pkg/robot_localization

Fusing the gps and imu datas, the z coordinate data he

<!-- All questions should be directed to answers.ros.org. Similarly, before filing a bug report, please check for solutions to your issue on answers.ros.org. -->

Bug report

Required Info:

  • Operating System:
    • OS and version (e.g. Ubuntu 18.04)
  • Installation type:
    • from source
  • Version or commit hash:
    • melodic-devel, HEAD, 9277d982fa1a2d2a05eec4f59b4f8696ca903f1c

Steps to reproduce issue

I used the test1.bag to test the pkg performance and the z coordinate data has drifted as the follow pictures. Can anybody explain why? Screenshot from 2020-10-14 16-35-34 Screenshot from 2020-10-14 16-36-00

closed time in 10 days

keguo1119

issue commentcra-ros-pkg/robot_localization

Fusing the gps and imu datas, the z coordinate data he

Hi, all questions should be asked on answers.ros.org. Please post the config you are using.

keguo1119

comment created time in 10 days

pull request commentcra-ros-pkg/robot_localization

Fix warning "Failed to meet update rate!"

Thanks again!

mjs973

comment created time in 11 days

push eventcra-ros-pkg/robot_localization

Mike

commit sha 2a03b084de1b709c9d068e28317d37c356e5ea77

Fix warning "Failed to meet update rate!" (#602) * Fix warning "Failed to meet update rate!"

view details

push time in 11 days

PR merged cra-ros-pkg/robot_localization

Fix warning "Failed to meet update rate!"

This patch reads the parameter server key silent_tf_failure only once at startup. It resolves #601.

+11 -3

0 comment

2 changed files

mjs973

pr closed time in 11 days

issue closedcra-ros-pkg/robot_localization

Failed to meet update rate!

<!-- All questions should be directed to answers.ros.org. Similarly, before filing a bug report, please check for solutions to your issue on answers.ros.org. -->

Bug report

Required Info:

  • Operating System:
    • Ubuntu 18.04
  • Installation type:
    • source from git repo
  • Version or commit hash:
    • HEAD of melodic-devel branch

Description

We are running the ekf_localization_node on a Clearpath Jackal.

Commit edc5bea3 causes the performance of the filter to be very poor, and the node continuously logs the warning "Failed to meet update rate!" This message happens many times per second.

This commit causes an access to the ros parameter server for every IMU packet that arrives. On the Jackal, this message comes into the filter at 75 Hz, so the node is trying to access the parameter server every 13 milliseconds. In our environment, the ROS master and parameter server do not run locally on the robot. The robot communciates over a wireless link to a server, and this param() call sometimes takes > 50 milliseconds to execute. That causes input queue overflow and very erratic timing of the filter update callback.

One way to fix this is to cache the silent_tf_failure flag in the RosFilter class. I will submit a pull request shortly.

Steps to reproduce issue

See descrption.

Expected behavior

See description.

Actual behavior

See description.

Additional information

closed time in 11 days

mjs973
PullRequestReviewEvent

Pull request review commentcra-ros-pkg/robot_localization

Fix warning "Failed to meet update rate!"

 template<class T> class RosFilter     //!     bool useControl_; +    //! @brief Whether or not to print warning for tf lookup failure+    //!+    bool silent_tf_failure_;

Thank you very much for both catching and addressing this issue.

Given that this is against melodic-devel, and we're still using the old (and technically incorrect) style for variable names in this branch, would you mind making this consistent with the others, and changing this to silentTfFailure_? I'll make sure it matches the style when I cherry pick it into the other branches. Thanks!

mjs973

comment created time in 12 days

PullRequestReviewEvent
PullRequestReviewEvent

issue commentcra-ros-pkg/robot_localization

Failed to meet update rate!

That does sound problematic. Given that you know the issue, can you submit a PR to fix it? Just make it a member variable and load the parameter once.

mjs973

comment created time in 13 days

delete branch cra-ros-pkg/robot_localization

delete branch : 574-repeat-publication

delete time in 17 days

push eventcra-ros-pkg/robot_localization

Tom Moore

commit sha 660793f4c68408dfa5d3ae4651c5760bbe3a5c69

Making repeated state publication optional (#595) * Making repeated state publication optional

view details

push time in 17 days

PR merged cra-ros-pkg/robot_localization

Making repeated state publication optional

Addresses #574.

As far as how this will behave, if the filter publishes a state with time t, and we later get a measurement with stamp < t, we'll still integrate that measurement and correct our state internally, but we won't publish a state that includes that correction until the next publication cycle after t.

This may get its base changed to a new noetic-devel branch.

+55 -9

4 comments

5 changed files

ayrton04

pr closed time in 17 days

issue closedcra-ros-pkg/robot_localization

Navsat_transform_node Without Magnetometer on Husky Gazebo Sim

Hi, I'm working on using navsat_transform_node to transform GPS to odom frame. However, the magnetometer in our robot is unusable because of bad interference, so I wrote a node that takes an initial GPS coordinate, moves the robot for 5 meters, take another GPS coordinate, and calculate the yaw using the following script:

y = np.sin(lon2-lon1) * np.cos(lat2)

x = np.cos(lat1) * np.sin(lat2) - np.sin(lat1) * np.cos(lat2) * np.cos(lon2 - lon1)

theta = np.arctan2(y, x)

yaw = (theta + 2 * np.pi) % (2 * np.pi)

Then I'm generating an IMU message by setting pitch and roll to 0 and converting YPT to quaternion . Since our robot is in repair, I'm testing my node using husky gazebo simulation. After disabling the hector IMU plugin, I'm launching husky_empty_world.launch, gmapping.launch, move_base.launch from the husky packages, navsat_transform_template.launch from robot_localization, and then running my node which takes GPS coordinates, moves the robot, and publishes an IMU message. However, navsat_transform_node doesn't seem to be unsubscribing from the IMU topic after I publish my IMU message (I added a line of ROS_INFO_STREAM("UNSUBSCRIBED") after imu_sub.shutdown(); ). Is this because I'm not publishing the IMU message within a set time frame after the navsat_trasnform_node launches? navsat_transform_node only requires one IMU reading, right? Any help will be appreciated. Thanks.

closed time in 19 days

jinbae9875

issue commentcra-ros-pkg/robot_localization

Navsat_transform_node Without Magnetometer on Husky Gazebo Sim

Hi there,

Please direct all questions. to answers.ros.org. Thanks.

jinbae9875

comment created time in 19 days

issue commentcra-ros-pkg/robot_localization

How is Absolute Heading Reflected on Imu Data?

Hi there,

I meant to update this previously: we ask that all questions be directed to answers.ros.org. Thanks!

jinbae9875

comment created time in 19 days

pull request commentcra-ros-pkg/robot_localization

Making repeated state publication optional

@reobaird, were you able to try this out?

ayrton04

comment created time in 22 days

push eventcra-ros-pkg/robot_localization

tgreier

commit sha a1055b983f54bc67531d9931a9efb0579d6d1179

Fix bug in creating frequency diag. (#594)

view details

push time in 22 days

PR merged cra-ros-pkg/robot_localization

Fix bug in creating frequency diag.

Resolves #593 Moved the min and max frequency values to the heap since pointers to those values are passed to diagnostic_updater::FrequencyStatusParam (to allow the values to be updated on the fly).

+14 -4

3 comments

2 changed files

tgreier

pr closed time in 22 days

PullRequestReviewEvent
PullRequestEvent

PR closed cra-ros-pkg/robot_localization

Making repeated state publication optional

Addresses #574.

As far as how this will behave, if the filter publishes a state with time t, and we later get a measurement with stamp < t, we'll still integrate that measurement and correct our state internally, but we won't publish a state that includes that correction until the next publication cycle after t.

This may get its base changed to a new noetic-devel branch.

+55 -9

3 comments

5 changed files

ayrton04

pr closed time in 22 days

issue closedcra-ros-pkg/robot_localization

filtered odometry is not accurate

Hi, I'm trying use robot_localization to fuse odometry and imu, But I meet some issues .I will provide my bag and paramer here. https://github.com/Fanny-one/fuse-odometry-and-imu.

the ekf_params.yaml:

  odom0: /wheel_odom
  odom0_config: [false, false, false,
                 false, false, false,
                 true,  true,  true,
                 false, false, true,
                 false, false, false]
  odom0_queue_size: 5
  odom0_nodelay: true
  odom0_differential: true
  odom0_relative: false

  imu0: /imu/data
  imu0_config: [false, false, false,
                false,  false, false,
                false, false, false,
                true,  true,  true,
                true,  true,  false]
  imu0_nodelay: false
  imu0_differential: false
  imu0_relative: true
  imu0_queue_size: 10
  imu0_remove_gravitational_acceleration: true

  process_noise_covariance: [0.05, 0,  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,

0, 0.05, 0, 0, 0, 0, 0, 0, 0,  0, 0, 0, 0, 0, 0,

0, 0, 0.05, 0, 0, 0, 0, 0, 0,  0, 0, 0, 0, 0, 0,

0, 0, 0, 0.03, 0, 0, 0, 0, 0,  0, 0, 0, 0, 0, 0,

0, 0, 0, 0, 0.03, 0, 0, 0, 0,  0, 0, 0, 0, 0, 0,

0, 0, 0, 0, 0, 0.06, 0, 0, 0,  0, 0, 0, 0, 0, 0,

0, 0, 0, 0, 0, 0, 0.025,0, 0,  0, 0, 0, 0, 0, 0,

0, 0, 0, 0, 0, 0, 0, 0.0255, 0,  0, 0, 0, 0, 0, 0,

0, 0, 0, 0, 0, 0, 0, 0, 0.04, 0,  0, 0, 0, 0, 0,

0, 0, 0, 0, 0, 0, 0, 0, 0,  0.01, 0, 0, 0, 0, 0,

0, 0, 0, 0, 0, 0, 0, 0, 0,  0, 0.01, 0, 0, 0, 0,

0, 0, 0, 0, 0, 0, 0, 0, 0,  0, 0, 0.02, 0, 0, 0,

0, 0, 0, 0, 0, 0, 0, 0, 0,  0, 0, 0, 0.01, 0, 0,

0, 0, 0, 0, 0, 0, 0, 0, 0,  0, 0, 0, 0, 0.01, 0,

0, 0, 0, 0, 0, 0, 0, 0, 0,  0, 0, 0, 0, 0, 0.005]
  initial_estimate_covariance: [1e-9, 0,    0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,  0, 0,

0, 1e-9, 0, 0, 0, 0, 0, 0, 0, 0,    0, 0, 0, 0, 0,

0, 0, 1e-9, 0, 0, 0, 0, 0, 0, 0,    0, 0, 0, 0, 0,

0, 0, 0, 1e-9, 0, 0, 0, 0, 0, 0,    0, 0, 0, 0, 0,


0, 0, 0, 0, 1e-9, 0, 0, 0, 0, 0,    0, 0, 0, 0, 0,

0, 0, 0, 0, 0, 1e-9, 0, 0, 0, 0,    0, 0, 0, 0, 0,

0, 0, 0, 0, 0, 0, 1e-9 , 0, 0, 0,    0, 0, 0, 0, 0,

0, 0, 0, 0, 0, 0, 0, 1e-9 , 0, 0,    0, 0, 0, 0, 0,

0, 0, 0, 0, 0, 0, 0, 0, 1e-9, 0,    0, 0, 0, 0, 0,

0, 0, 0, 0, 0, 0, 0, 0, 0, 1e-9,    0, 0, 0, 0, 0,

0, 0, 0, 0, 0, 0, 0, 0, 0, 0,    1e-9, 0, 0, 0, 0,

0, 0, 0, 0, 0, 0, 0, 0, 0, 0,    0, 1e-9 , 0, 0, 0,

0, 0, 0, 0, 0, 0, 0, 0, 0, 0,    0, 0, 1e-9, 0, 0,

0, 0, 0, 0, 0, 0, 0, 0, 0, 0,    0, 0, 0, 1e-9, 0,

0, 0, 0, 0, 0, 0, 0, 0, 0, 0,    0, 0, 0, 0, 1e-9]

the first issue: when the robot stands still, position x an y of odometry from robot_localization will still move a bit. For example, when the true x =0 , y = 0,but the result is (x= 0.0002, y=0.0003),(x= 0.0005, y=0.0008),(x= 0.0008, y=0.001)...increase progressively.

the second issue: In my bag, I make the robot move forward 8m, but the result is about 8.18m. I think the error is too big. So I think my covariance maybe is not fit.

I don't understand why and I need help. thanks in advance.

closed time in 24 days

Fanny-one

issue commentcra-ros-pkg/robot_localization

filtered odometry is not accurate

Please stop asking the same question repeatedly. All questions should be directed to answers.ros.org. If you have already asked there (and I see you have), I will answer it when I have time. I work on r_l on my own time, and I have very little free time to dedicate to it.

Fanny-one

comment created time in 24 days

PR opened ros/rosdistro

Reviewers
Changing robot_localization Noetic source branch
+2 -2

0 comment

1 changed file

pr created time in 25 days

push eventayrton04/rosdistro

Steve Macenski

commit sha 1e7d8cc0db3d1b5c626ae2c7011552ce3f00fb07

navigation2: 0.4.0-1 in 'foxy/distribution.yaml' [bloom] (#25651)

view details

rfeistenauer

commit sha ff2b4d48c9825017c9713b187fd594d59c962f06

pilz_robots: 0.5.18-1 in 'melodic/distribution.yaml' [bloom] (#25656)

view details

Bence Magyar

commit sha f30e7522744342fdff37654cdd3d5efecdcff4f8

realtime_tools: 2.1.0-1 in 'foxy/distribution.yaml' [bloom] (#25665)

view details

Bence Magyar

commit sha 07358baba087c2cccd0380b1142a9b71f124121d

control_msgs: 2.4.0-1 in 'foxy/distribution.yaml' [bloom] (#25664)

view details

Michael Lehning

commit sha 9752429007cfe34d36152140f83e854211bd68d6

sick_scan: 1.7.6-1 in 'kinetic/distribution.yaml' [bloom] (#25661)

view details

Atsushi Watanabe

commit sha 46101726e92a23464be7ca740f1a41ed91a21f07

neonavigation: 0.9.0-1 in 'kinetic/distribution.yaml' [bloom] (#25652)

view details

fpasch

commit sha 97b301e1455bc24d65230f7dc2a39a976f71c572

carla_msgs: 1.1.0-1 in 'kinetic/distribution.yaml' [bloom] (#25659)

view details

Atsushi Watanabe

commit sha d3ffc732a97db1318a3c6349581e5a475607a1e3

neonavigation: 0.9.0-1 in 'noetic/distribution.yaml' [bloom] (#25654)

view details

Tim Clephas

commit sha f5bd16618d780479478de7761d309465ace26a6f

mobile_robot_simulator: 1.0.1-1 in 'noetic/distribution.yaml' [bloom] (#25655)

view details

Michael Lehning

commit sha 2dae6dedc126eea6189c241aa89b2f827c786865

sick_scan: 1.7.6-1 in 'noetic/distribution.yaml' [bloom] (#25658)

view details

AndyZe

commit sha 37b104e90d63633ed1202cfd706de889fc57972c

Add PID pkg for Noetic (#25666)

view details

Robert Haschke

commit sha c0bd074e57bbe3cb0aad48060ef19180b2277755

xacro: 1.14.3-2 in 'noetic/distribution.yaml' [bloom] (#25668)

view details

Eric Relson

commit sha 4926f6a6e2f4aee4b77d6c4a3ecaca9717481f35

power_msgs: 0.4.1-1 in 'noetic/distribution.yaml' [bloom] (#25669)

view details

Adam Allevato

commit sha ca89d3fe479831b8b63c03f9ed6692dcd61d92af

vision_msgs: 0.0.1-1 in 'noetic/distribution.yaml' (#25670) I'm not sure why I had to do this manually; bloom was unable to create an OAuth token to create this PR. Increasing version of package(s) in repository vision_msgs to 0.0.1-1: - upstream repository: `https://github.com/Kukanani/vision_msgs.git` - release repository: `https://github.com/Kukanani/vision_msgs.git` - distro file: `noetic/distribution.yaml` - bloom version: 0.9.7 previous version for package: `null`

view details

Francisco Martín Rico

commit sha 14930d833945abc33af458531c0cbbed17d8e013

ros2_planning_system: 0.0.9-1 in 'eloquent/distribution.yaml' [bloom] (#25671)

view details

Tom Stewart

commit sha 6ee729884b521b7d5ac9152bb513741e2d15a2e6

Add yamale to python.yaml (#25662)

view details

Kei Okada

commit sha 0abdbfe2240336fdb61a4a63e703dc1831399e17

Add additional python3 keys (#25617) - python3-texttable - `ubuntu` https://packages.ubuntu.com/focal/python3-texttable - `debian` https://packages.debian.org/buster/python3-texttable - `gentoo` https://packages.gentoo.org/packages/dev-python/texttable - `rhel` https://centos.pkgs.org/8/epel-x86_64/python3-texttable-1.6.2-5.el8.noarch.rpm.html - `fedora` https://fedora.pkgs.org/30/fedora-x86_64/python3-texttable-1.4.0-2.fc30.noarch.rpm.html - python3-github : Source: https://pypi.python.org/pypi/PyGithub / https://github.com/PyGithub/PyGithub - `ubuntu` https://packages.ubuntu.com/focal/python3-github - `debian` https://packages.debian.org/buster/python3-github - `gentoo` https://packages.gentoo.org/packages/dev-python/PyGithub - `rhel` https://centos.pkgs.org/7/epel-x86_64/python36-pygithub-1.39-5.el7.noarch.rpm.html - `fedora` https://fedora.pkgs.org/30/fedora-x86_64/python3-github3py-1.0.0-0.10a4.fc30.noarch.rpm.html - python3-colorama - `ubuntu` https://packages.ubuntu.com/focal/python3-colorama - `debian` https://packages.debian.org/buster/python3-colorama - `gentoo` https://packages.gentoo.org/packages/dev-python/colorama - `rhel` https://centos.pkgs.org/8/epel-x86_64/python3-colorama-0.4.3-1.el8.noarch.rpm.html - `fedora` https://fedora.pkgs.org/30/fedora-x86_64/python3-colorama-0.4.1-1.fc30.noarch.rpm.html Co-authored-by: Christopher Berner <christopherberner@gmail.com>

view details

Jose Luis Rivero

commit sha 29ff5327457d57e4175e4224655c814f3c488b95

Enable test_abi for foxy: ament_index, rcl, rcl_interfaces, rcpputils, rmw, rosidl (#25638)

view details

Bence Magyar

commit sha 8c055764a0e7150dcaeeea51a4f82b23e9857511

auv_msgs: 0.1.1-1 in 'noetic/distribution.yaml' [bloom] (#25687)

view details

Vladimir Ermakov

commit sha 4d9e2aad34e0cb1e8ba64a8790a1c76350d3665b

mavlink: 2020.7.7-1 in 'noetic/distribution.yaml' [bloom] (#25685)

view details

push time in 25 days

create barnchayrton04/rosdistro

branch : rl_noetic_source_branch

created branch time in 25 days

MemberEvent
MemberEvent

push eventcra-ros-pkg/robot_localization

Tom Moore

commit sha a77f202f47c2f623b9ed7400e14391ba69950aaa

PR feedback

view details

push time in a month

create barnchcra-ros-pkg/robot_localization

branch : noetic-devel

created branch time in a month

PullRequestEvent

PR closed cra-ros-pkg/robot_localization

Fix bug in creating frequency diag.

Resolves #593 Moved the min and max frequency values to the heap since pointers to those values are passed to diagnostic_updater::FrequencyStatusParam (to allow the values to be updated on the fly).

+14 -4

3 comments

2 changed files

tgreier

pr closed time in a month

pull request commentcra-ros-pkg/robot_localization

Fix bug in creating frequency diag.

Let me close and open to kick the job off again.

tgreier

comment created time in a month

pull request commentcra-ros-pkg/robot_localization

Fix bug in creating frequency diag.

That seems to happen with the ROS2 tests, and I'm not sure why. I don't actually have a test setup locally for ROS2 just now, so I'm not sure.

tgreier

comment created time in a month

issue commentros/geometry2

New warning message for repeated transforms

I think the proposal sounds really solid, thanks @tfoote and @SteveMacenski. Meanwhile, I have a PR so that prevents r_l from re-publishing data with duplicate timestamps.

ayrton04

comment created time in a month

pull request commentcra-ros-pkg/robot_localization

Making repeated state publication optional

Shouldn't this be targeted only onto noetic and foxy? I don't think this issue affects melodic

Yes, but we don't have a noetic-devel. Are you cool if we make one now? I'll take care of it.

Will roll your suggestion into the PR tomorrow. Thanks!

ayrton04

comment created time in a month

Pull request review commentcra-ros-pkg/robot_localization

Making repeated state publication optional

 namespace RobotLocalization       }        // Fire off the position and the transform-      positionPub_.publish(filteredPosition);+      if (!corrected_data)+      {+        positionPub_.publish(filteredPosition);+      }++      // Retain the last published stamp so we can detect repeated transforms in future cycles+      lastPublishedStamp_ = filteredPosition.header.stamp;

So the earlier suggestion about >= notwithstanding, as of now, if corrected_data == true, then lastPublishedStamp_ == filteredPosition.header.stamp anyway. However, I'm perfectly happy to move this up to line 1992.

ayrton04

comment created time in a month

Pull request review commentcra-ros-pkg/robot_localization

Making repeated state publication optional

 namespace RobotLocalization               " This was likely due to poorly coniditioned process, noise, or sensor covariances.");       } +      // If we're trying to publish with the same time stamp, it means that we had a measurement get inserted into the+      // filter history, and our state estimate was updated after it was already published. As of ROS Noetic, TF2 will+      // issue warnings whenever this occurs, so we make this behavior optional.+      corrected_data = (!permitCorrectedPublication_ && lastPublishedStamp_ == filteredPosition.header.stamp);

Yeah, that situation should never happen, but it also won't hurt to change it, and I agree with the increased clarity.

ayrton04

comment created time in a month

Pull request review commentcra-ros-pkg/robot_localization

Making repeated state publication optional

 If *true*, the state estimation node will publish the transform from the frame s ^^^^^^^^^^^^^^^^^^^^^ If *true*, the state estimation node will publish the linear acceleration state. Defaults to *false*. +~permit_corrected_publication

Should we just make a noetic-devel and then change this PR to target that? Then we don't have to worry about that.

ayrton04

comment created time in a month

PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commentcra-ros-pkg/robot_localization

Making repeated state publication optional

 namespace RobotLocalization               " This was likely due to poorly coniditioned process, noise, or sensor covariances.");       } +      // If we're trying to publish with the same time stamp, it means that we had a measurement get inserted into the+      // filter history, and our state estimate was updated after it was already published. As of ROS Noetic, TF2 will+      // issue warnings whenever this occurs, so we make this behavior optional.+      corrected_data = (!permitCorrectedPublication_ && lastPublishedStamp_ == filteredPosition.header.stamp);

So I'm thinking aloud here. The filter history handles this situation:

  • In the first cycle, the filter has four measurements to process. They have timestamps 1, 2, 4, and 5. They get processed, and we publish a state with timestamp 5.
  • In the second cycle, the filter receives only a measurement with timestamp 3. It rewinds history to the posterior state after measurement 2 was fused, and then processes 3, 4, and 5 again. Then it publishes a state with timestamp 5. This creates the issue in question, and is solved by this PR.

Now let's go over your scenario, or at least what I think you are saying.

  • In the first cycle, the filter has four measurements to process. They have timestamps 1, 2, 4, and 5. They get processed, and we publish a state with timestamp 5.
  • In the second cycle, the filter has four measurements to process. They have timestamps 6, 7, 8, and 9. They get processed, and we publish a state with timestamp 9.
  • In the third cycle, the filter receives only a measurement with timestamp 3. It rewinds history to the posterior state after measurement 2 was fused, and then processes 3, 4, 5, 6, 7, 8, and 9 again. Then it publishes a state with stamp 9 again. This also causes the issue, and is solved by this PR.

The filter was never publishing the updated state as it processed the history. It was rewinding, inserting, and processing all the way up to the latest measurement, then publishing. So I think checking the latest publication should work?

Note that in both of those cases, anyone listening to tf will get the exact same behavior before and after this change: the first transform published won't get updated when the second one arrives. It's just that in Noetic, we also get yelled at. :)

There is a third case.

  • In the first cycle, the filter has four measurements to process. They have timestamps 1, 2, 4, and 5. They get processed, and we publish a state with timestamp 5.
  • In the second cycle, the filter has two measurements to process. They have timestamps 3 and 6. The filter rewinds history to the posterior state after measurement 2 was fused, and then processes 3, 4, 5, and 6, and publishes the state with timestamp 6. This is obviously not an issue.

Anyway, I will readily admit that I might be totally missing your point, and I apologize if so. Can you provide an example?

ayrton04

comment created time in a month

PullRequestReviewEvent

Pull request review commentcra-ros-pkg/robot_localization

Making repeated state publication optional

 namespace RobotLocalization              "\ntransform_timeout is " << tfTimeout_.toSec() <<              "\nfrequency is " << frequency_ <<              "\nsensor_timeout is " << filter_.getSensorTimeout() <<-             "\ntwo_d_mode is " << (twoDMode_ ? "true" : "false") <<-             "\nsmooth_lagged_data is " << (smoothLaggedData_ ? "true" : "false") <<+             "\ntwo_d_mode is " << std::boolalpha << twoDMode_ <<

Sorry, I printed out the new param here using boolalpha, and thought I might as well pick up the others.

ayrton04

comment created time in a month

PullRequestReviewEvent

push eventcra-ros-pkg/robot_localization

Tom Moore

commit sha e4d0bf8ede9767965e8977b970e565a522e18ca3

Making repeated state publication optional

view details

push time in a month

issue commentcra-ros-pkg/robot_localization

Diagnostic frequency monitor min/max values are 0.

Oh! I just realized this was for ROS2. The ROS1 version uses member variables.

tgreier

comment created time in a month

issue commentcra-ros-pkg/robot_localization

TF_REPEATED_DATA warning in Noetic

@reobaird, give that branch a spin, if you have any cycles. Waiting to see if the warnings go away on the ROS buildfarm.

ayrton04

comment created time in a month

push eventcra-ros-pkg/robot_localization

Tom Moore

commit sha 706daab914abfe634139c1d96e159457844777d3

Making repeated state publication optional

view details

push time in a month

create barnchcra-ros-pkg/robot_localization

branch : 574-repeat-publication

created branch time in a month

issue commentcra-ros-pkg/robot_localization

TF_REPEATED_DATA warning in Noetic

So my simple solution for this will be to add a parameter that allows the filter to repeat publication time stamps. However, I feel like that parameter should default to false for Noetic, but everything before Noetic should retain the old behavior for compatibility. @SteveMacenski, I'm thinking we're going to need a noetic-devel.

ayrton04

comment created time in a month

issue closedcra-ros-pkg/robot_localization

Sign error in transferFunctionJacobian_

I was just diving deeper into the math behind EKF and its implementation in robot_localization and I believe I found sign error in formula for transfer function Jacobian. I think that at line 327 In file ekf.cpp the correct formula should be: "double dFY_dP = (sr * tp * cpi * pitchVel + cr * tp * cpi * yawVel) * delta;" instead of "double dFY_dP = (sr * tp * cpi * pitchVel - cr * tp * cpi * yawVel) * delta;"

closed time in a month

abojda

issue commentcra-ros-pkg/robot_localization

Diagnostic frequency monitor min/max values are 0.

Woof, that's been around since the beginning. Thanks for catching it. I'd welcome a PR to fix it!

tgreier

comment created time in a month

push eventcra-ros-pkg/robot_localization

Aleksander Bojda

commit sha 1bfc1120e9fddfecd7e550dc6c7dc120ae14e1f5

Fix sign error in dFY_dP part of transferFunctionJacobian_ (#592) Co-authored-by: Aleksander Bojda <a.bojda@agribot.eu>

view details

push time in a month

PR merged cra-ros-pkg/robot_localization

Fix sign error in dFY_dP part of transferFunctionJacobian_

Addresses https://github.com/cra-ros-pkg/robot_localization/issues/591.

+1 -1

0 comment

1 changed file

abojda

pr closed time in a month

PullRequestReviewEvent

issue commentcra-ros-pkg/robot_localization

Sign error in transferFunctionJacobian_

I think you're right, good catch. The transfer function (ignoring the time delta term) is:

new_yaw = yaw + v_pitch * sin(roll) * cos(pitch)^-1 + v_yaw * cos(roll) * cos(pitch)^-1

So then we'd have

dFYaw/dPitch = v_pitch * sin(roll) * - (-sin(pitch)) * cos(pitch)^-2 + v_yaw * cos(roll) * - (-sin(pitch)) * cos(pitch)^-2
             = v_pitch * sin(roll) * tan(pitch) * cos(pitch)^-1 + v_yaw * cos(roll) * tan(pitch) * cos(pitch)^-1

Care to submit a PR?

Will go see if I still have this in my notebook from when I originally computed that.

abojda

comment created time in a month

issue closedcra-ros-pkg/robot_localization

How to dynamically set "init_state"?

I want to use the program to automatically set the initial state of the localization,and the init_state can only be set manually each time. What should I do? Thank you very much

closed time in a month

he-guo

issue commentcra-ros-pkg/robot_localization

How to dynamically set "init_state"?

Hi, would you mind asking this question on answers.ros.org? Thanks.

he-guo

comment created time in a month

pull request commentcra-ros-pkg/robot_localization

Parameter for world_frame_id for navsat_transform

Thanks again!

cdimmig

comment created time in a month

push eventcra-ros-pkg/robot_localization

cdimmig

commit sha c2e1bdddf86444c39d75142d5a138a11b03589e9

Parameter for world_frame_id for navsat_transform (#576) * Added parameter for world_frame_id to navsat transform to allow for setting frame ID to be something other than the default when wait_for_datum is true

view details

push time in a month

PR merged cra-ros-pkg/robot_localization

Parameter for world_frame_id for navsat_transform

Added parameter for world_frame_id to navsat transform to allow for setting frame ID to be something other than the default when wait_for_datum is true. Issue noted in #524

+50 -0

3 comments

2 changed files

cdimmig

pr closed time in a month

push eventcra-ros-pkg/robot_localization

Jeffrey Kane Johnson

commit sha 19126874894fadf0fa57e8c634748a56d8066326

Fix typo in navsat_transform_node.rst (#588) "prodives" -> "provides"

view details

push time in 2 months

PR merged cra-ros-pkg/robot_localization

Fix typo in navsat_transform_node.rst

"prodives" -> "provides"

+1 -1

0 comment

1 changed file

togaen

pr closed time in 2 months

PullRequestReviewEvent

pull request commentcra-ros-pkg/robot_localization

fix issue caused by starting on uneven terrain

Thanks again!

jrbaxter0

comment created time in 2 months

push eventcra-ros-pkg/robot_localization

James Baxter

commit sha f760c01a381caa2aa1709aaf6f9585596dac89ac

fix issue caused by starting on uneven terrain (#582)

view details

push time in 2 months

PR merged cra-ros-pkg/robot_localization

Reviewers
fix issue caused by starting on uneven terrain

This resolves an bug in navsat_transform generating the static transform between map and utm while on a slope. It does this by stripping the pitch and roll from the odometry message. This is noted in issue #325. Essentially, since the pitch and roll are stripped from the utm orientation, the same must be done for the map orientation.

cartesian_world_transform_, which is the transform from utm to map is calculated in the following way: <a href="https://www.codecogs.com/eqnedit.php?latex=T_{utm}^{map}&space;=&space;T_{base_link}^{map}&space;&space;(T_{base_link_yaw_only}^{utm})^{-1}" target="blank"><img src="https://latex.codecogs.com/gif.latex?T{utm}^{map}&space;=&space;T_{base_link}^{map}&space;&space;(T_{base_link_yaw_only}^{utm})^{-1}" title="T_{utm}^{map} = T_{base_link}^{map} * (T_{base_link_yaw_only}^{utm})^{-1}" /></a> <a href="https://www.codecogs.com/eqnedit.php?latex=T_{utm}^{map}&space;=&space;T_{base_link}^{map}&space;&space;T_{utm}^{base_link_yaw_only}" target="blank"><img src="https://latex.codecogs.com/gif.latex?T{utm}^{map}&space;=&space;T_{base_link}^{map}&space;&space;T_{utm}^{base_link_yaw_only}" title="T_{utm}^{map} = T_{base_link}^{map} * T_{utm}^{base_link_yaw_only}" /></a>

This only works if base_link and base_link_yaw_only are the same frame. On a slope, this won't be true, which is why the bug appears there.

These images show the output of navsat_transform under several configurations. In each, a sinusoidal altitude is given on the input gps/fix message, while latitude and longitude are held fixed.

This is the normal output of the system when the input imu and pose messages have an identity quaternion. Note that the X and Y positions are fixed, while Z tracks altitude. normal

This is the output of the system before the patch, where the input imu and pose messages have a 45 degree upwards pitch. Note that X is no longer fixed. The static transform between utm and map has relative pitch, which is causing this issue.

Remember that REP 105 specifies that map should have Z pointing straight upwards. Therefore, there can only be relative yaw between utm and map. broken

This is the output of the system after the patch, where the input imu and pose messages have a 45 degree upwards pitch. Note that X is once again fixed and Z tracks altitude. fixed

+10 -1

3 comments

1 changed file

jrbaxter0

pr closed time in 2 months

PullRequestReviewEvent

pull request commentcra-ros-pkg/robot_localization

fix finding headers for yaml-cpp when building foxy

@ManuelMeraz, what is the status of this PR? Would it be possible to do what @SteveMacenski suggests?

ManuelMeraz

comment created time in 2 months

Pull request review commentcra-ros-pkg/robot_localization

Parameter for world_frame_id for navsat_transform

 namespace RobotLocalization    void NavSatTransform::odomCallback(const nav_msgs::OdometryConstPtr& msg)   {+    if (world_frame_param_loaded_ && (world_frame_id_.compare(msg->header.frame_id) != 0))

compare will obviously work, but I think this would be more readable as world_frame_id_ != msg->header.frame_id. Same below with the base_link_frame_id_.

cdimmig

comment created time in 2 months

PullRequestReviewEvent
PullRequestReviewEvent

issue closedcra-ros-pkg/robot_localization

Does the covariance is related to the velocity and acceleration?

As I accelerate, I find that the covariance is related to my acceleration and my velocity. I check the code found this:

double dFx_dP = (xCoeff * xVel + yCoeff * yVel + zCoeff * zVel) * delta + (xCoeff * xAcc + yCoeff * yAcc + zCoeff * zAcc) * oneHalfATSquared;

double dFR_dP = (cpi * cpi * sr * pitchVel + cpi * cpi * cr * yawVel) * delta;

transferFunctionJacobian_(StateMemberX, StateMemberPitch) = dFx_dP;

It's say that the Jacobian matrix is related to the velocity and acceleration. When the velocity increases, the covariance of the entire EKF will increase, not only related to the time? If I set a threshold of covariance, when I go too fast, I'm going to report an error very quickly.

closed time in 2 months

improve100

issue commentcra-ros-pkg/robot_localization

Does the covariance is related to the velocity and acceleration?

I've been behind on my ROS answers attentiveness, but I'll try to catch up this week. Questions should only go there, thanks.

improve100

comment created time in 2 months

issue commentcra-ros-pkg/robot_localization

When calculate innovationSubset(z-Hx), why it's (measurementSubset - stateSubset)?

First, keep in mind that H is a matrix of size measurement_size x state_size. Let's imagine we have a measurement of size 3. The matrix would be 3x15, with 1s in the locations of the updated variables, and 0s elsewhere.

Given that, we could compute the innovation two ways:

  1. innovation = (measurement - H * full_state)

This would yield a 3x1 - 3x15 * 15x1 -> 3x1 vector, which is correct. In this case, H * full_state is just "ignoring" all the variables we don't care about. That would make it identical to state_subset.

  1. Build the state subset directly, and just use that.

(2) requires fewer iterations, so we do that.

If H were actually transforming the data in any way, we couldn't get away with this.

KarasCvs

comment created time in 2 months

pull request commentlocusrobotics/ros_comm

Confirm and log non-queued connections being created during initialization

@abencz, can we close this, even if we retain the branch for now?

abencz

comment created time in 2 months

PullRequestReviewEvent

issue closedcra-ros-pkg/robot_localization

How to use landmark(which has global pose)to update state?

<!-- All questions should be directed to answers.ros.org. Similarly, before filing a bug report, please check for solutions to your issue on answers.ros.org. -->

Bug report

Required Info:

  • Operating System:
    • <!-- OS and version (e.g. Ubuntu 16.04) -->
  • Installation type:
    • <!-- binaries or from source -->
  • Version or commit hash:
    • <!-- Output of git rev-parse HEAD, release version, or repos file -->

Steps to reproduce issue

<!-- Detailed instructions on how to reliably reproduce this issue -->

Expected behavior

Actual behavior

Additional information

closed time in 2 months

xbcdbc

issue commentcra-ros-pkg/robot_localization

How to use landmark(which has global pose)to update state?

This doesn't appear to be a bug. Please ask questions on answers.ros.org, and I'd ask for your patience. Thanks.

xbcdbc

comment created time in 2 months

pull request commentlocusrobotics/ros_comm

Confirm and log non-queued connections being created during initialization

So this looks fine, but I wonder if we can get a little bit closer to the action self.connections append operation:

https://github.com/locusrobotics/ros_comm/blob/0dd1d9206b6cce3e72cc6fbda29342595dde8fec/clients/rospy/src/rospy/topics.py#L443

Can we check the type of the object that we're about to append there? I know it's extremely unlikely that some other data path exists that we're not seeing, but "extremely unlikely" is how we got here. We might also consider printing out the stack trace if it's the wrong type.

I can deploy this at Boots in the meantime, pending permission.

abencz

comment created time in 2 months

pull request commentcra-ros-pkg/robot_localization

fix issue caused by starting on uneven terrain

Just a note that I am not ignoring this. I am swamped at the moment, and will review soon. Thanks for submitting!

jrbaxter0

comment created time in 3 months

pull request commentcra-ros-pkg/robot_localization

Parameter for world_frame_id for navsat_transform

So the real root of this issue is that, if we specify the datum manually, we aren't able to get an odometry message before the frame_ids get used in the datum callback. I think that this PR needs three more things:

  1. Please also load the base_link_frame as a parameter.
  2. Both the world_frame and base_link_frame parameters should only get loaded if wait_for_datum is true. If those parameters are set and wait_for_datum is false, then we should warn the user that the parameters have no effect.
  3. If wait_for_datum is true, and we load the frame parameters, but we later get an odometry message and the frame_ids in that message don't match the ones in the parameters we set, we should issue a warning (once).
cdimmig

comment created time in 3 months

more