stevejp's profile - activity

Is it possible you have an uninitialised variable in the switch/case which is breaking the program?

Have you tried vicon_bridge? I used it a couple months ago and it worked out of the box.

What are the performance metrics you want to use for deciding if you want to break 1 node into many, or combine many int

Q1: You can't publish multiple message types to a single topic. You could, however, publish each of these message types

Q1: You can't publish multiple message types to a single topic. You could, however, publish each of these message types

Q1: You can't publish multiple message types to a single topic. You could, however, publish each of these message types

Q1: You can't publish multiple message types to a single topic. You could, however, publish each of these message types

Q1: You can't publish multiple message types to a single topic. You could, however, publish each of these message types

Updated my answer

Q1: You can't publish multiple message types to a single topic. You could, however, publish each of these message types

Can you post your launch file? Also confirm that the "odom_raw" frame id in your odom message is a typo (or that you are

Q1: You can't publish multiple message types to a single topic. You could, however, publish each of these message types

If you aren't providing your 'global ekf' with an absolute source of positioning (i.e., a pose estimate of base_link in

When you say "it was not working", can you elaborate on what isn't working? Do you have an error message you can show?

When I view odometry/filtered in RVIZ in the odom frame the arrows don't point to direction of movement,but per

Not entirely clear what you're saying. Can you either post a picture or give a detailed description of the observed beha

Is the local planner giving you any warnings? Have you tried running it with the default local / global planner paramete

Can you provide more information on what packages / configurations you're using?

Can you add more info on what you're trying to do / what you setup is? Are you using robot_localization? If you are, the

Have you talked to your supervisor?

Other than the timing issues that looks like what I would expect from move_base. Have you tried removing some of the com

Sounds like you haven't set it up properly - if you add more information (screenshots, your r_l config file, and example

Clearpath robots also use diff drive if you want to compare with PAL.

If you just want to know the direction they're facing then orientation is correct (keep it mind it is in quaternion form

Can you provide more details on what your problem is? I.e., what behavior do you expect and what are you seeing?

Covariance of what? What is the problem?

Unfortunately I'm not super familiar with the husky hardware interface, you may have to dig into the driver to figure it

Answer will depend on what exactly you mean by "implement odometry pose estimation". If you want to go from raw wheel

What local planner are you using? Have you tried tuning the parameters of your local planner?

Can you record & upload a bag file? Would make it easier to troubleshoot.

The UM7 IMU is reporting the orientation of the imu_link frame in some world fixed frame (e.g., ENU / NED). So regardles

I remember having this problem (hanging at 99-100%) awhile ago on an old T440 laptop (16.04). Don't think it prevented m

navsat_transform_node only needs one imu message to initiate the utm->map frame TF, so it could be dropping the conne

Generic troubleshooting advice would be to simplify the system and then systematically add complexity when you're confid

The navigation stack works perfectly fine without a laser. The main reason you may want to use a laser for navigation (a

For your IMU, the only valid rows to fuse are [2,4,5] which correspond to roll-pitch-yaw, roll dot-pitch dot-yaw dot, an

The statement Tom made "The odometry input to...output (it defaults to odometry/filtered)." is saying that the default i

The statement Tom made "The odometry input to...output (it defaults to odometry/filtered)." is saying that the default o

For your IMU, the only valid rows to fuse are [2,4,5] which correspond to roll-pitch-yaw, roll dot-pitch dot-yaw dot, an

The line extraction node is trying to publish the markers in the laser frame, which doesn't exist because you probably h

In your EKF node config, your gps odometry topic name looks incorrect. It should be the output coming from your navsat_t

The "AHRS" orientation estimate that the UM7 calculates isn't great, but the IMU sensor data (i.e., acceleration, gyros,