Mork's profile - activity

Thanks for clarification, PR was made :) https://github.com/ros-planning/moveit/pull/2991

Get object color though python PlanningSceneInterface I have implemented a custom object detection node which publishes

It causes some problems when performing SLAM (e.g. with gmapping), since new walls "apper" on the map when turning direc

Thank you for sharing, I'll look into it!

@nettercm Could you provide some code for your skew compensation solution please? I think this might help a lot of users

So you think that the whole scan itself is kind of skewed? My lidar has a rotation frequency of about 7Hz. Now it kind o

laser_scan_matcher with YDLidar Hello fellow ROS users, I'm trying to use the laser_scan_matcher together with a YDLida

laser_scan_matcher with YDLidar Hello fellow ROS users, I'm trying to use the laser_scan_matcher together with a YDLida

Does your robot properly respond to the lateral part (y coordinate) in the twist message, i.e. is it generally capable t

Also, could you attach the logs after setting a goal in rviz?

Usually no plan is published when path planning failed. From the video it looks like you are setting the goal pretty clo

That was it, the problem is solved, thank you!

Thanks a lot, that was it!!

You need something what can deliver similar data like a laser scanner. I don't think a single IR sensor will make it. Try to get a second hand kinect online (e.g. ebay), they aren't that expensive.

I assume you have a self made robot or something. The gmapping and amcl (for localization only) need 3 thinks to work: - Odometry - Laser scans (can also be fake laser scans) - Transformations from the laser scan to the global position as measured by the motor encoders (which later will be corrected by the localization)

You have to figure out by your own how to code it for your robot in particular. A good starting point are the tutorials at Navigation tutorials.

What kind of sonar do you use? A single sonar sensor won't make it, you need to fake a laser scanner with at least 20-30 directions. Maybe a Kinect or a similar sensor would be a better choice.

I think so, since the Start and Goal states are green/orange and the actual robot model is gray, isn't it?

Btw. when we publish the joint states, we leave the header.frame_id and the velocity/effort arrays empty. Is that ok?

Hey,

we are trying to integrate our custom robot into the Moveit! framework. We are able to create and execute plans on the real robot using the rviz moveit motion planning plugin.

However, the shown robot state is not updated live in Rviz. When we manually move the robot, the visual representation in Rviz does not move at all, although the joint states are published correctly. We have to reset Rviz or the plugin to make it show the current state. I.e. it looks like it's taking a snapshot of the robot state at rviz startup and doesn't update it later.

If we activate the Robot Model plugin in Rviz, the shown representation moves correctly according to the real robot movement.

Are we doing something wrong or is the Rviz moveit plugin somehow assuming that the robot can only be moved by trajectory commands?

Best regards Mark