Hot answers tagged

6

I have found the problem after some long search on the internet. The problem was that in Rviz, X-axis is defined as front of the robot and Y-axis is defined as the sideways. However, in my URDF I defined the robot in a way where Y-axis was its front and X-axis was its sideways. After fixing this, my robot moves normally in Rviz and Gazebo both.


3

So the doc's were out of date. I just updated them as the mesh is actually of type voxblox_msgs::MeshBlock. Voxblox use to output a standard MarkerArray, however this form of visualization means you have to output the entire mesh every time any part of it changes. This meant when running on a robot and visualizing on a laptop we were saturating our wifi ...


2

These values are relative to the camera. Z is always positive as the camera can't see what is behind. X and Y can be positive or negative depending on if an object is left/right or higher/lower than the camera's viewing direction.


2

Behavior like this suggests that your odometry is not being computed properly when the vehicle turns. It's hard to tell but the model appears to have rotated about 90 degrees but the laser scans appear to have rotated close to 180 degrees comparatively. There may be an issue with your wheel radius or some similar setting. Alternatively there could be a sign ...


2

I just had to re-enter: source devel/setup.bash In every new terminal.


1

I agree with r-bryan that you're likely missinterpreting some of the metadata. It could be the frame width or alternatively the stride width or something else in the depth image. There's a good reference implementation that you can compare yours to the one in depth_image_proc The main part of the implementation is in this header where you can see that there'...


1

At first I thought there was some sort of systematic raw format or resolution error, sort of like ROS + kinect depth data duplication . Then I noticed that each corridor appears in a different perspective, as if the sensor turned to point a different way between two captured frames. You didn't say what sensor you're using, but I assume it's not two cams that ...


1

Collisions with? If you have an occupancy map, then you can check with that and the robot's base_link. If the objects are static then just having their positions will be enough to check the collisions. It completely depends on the robot and the application.


1

I have run Gazebo in machines that don't have Nvidia cards for years now, never had any problems with it. The problem is more likely related to the virtual machine environment, see here and here for relevant threads. In any case, you should consider installing Ubuntu in dual-boot mode. It will help avoid this sort of compatibility issue, and you will make ...


1

The origin defined inside link_01 is not the position of the cylinder in the global coordinate frame (the "world"), but in its own private frame. By default the object's center lies at the origin of its own coordinate frame, but in this case, the cylinder is shifted $0.2 m$ upwards along the $z$ axis, placing its bottom on the origin. The effect of this ...


1

The XYZ readings from the camera are in the reference frame of the camera. @FooBar is correct about the X/Y values: they are planar about the center of the camera, just like the OpenGL viewing window. I don't know the maximum range of the point-cloud data, but my suspicion is that the maximum z value is 1. (This could change, however, depending if you have a ...


1

I did install a YARP based environment on my droplet along with graphics and it works great. I use it for testing purpose. The installation in my case was very standard and when it came to graphics I simply searched for online guidance, which is usually super useful on Digital Ocean (DO). This is why I tend to prefer DO over other online premises: it's easy ...


1

I think that you're correct in your assessment that "there is some disconnect between the axes of the 2D map and the response from aruco_detect." Reading the documentation for the topic /fiducial_transforms you'll see that those transforms are relative to the camera, "The transforms showing the pose of the fiducials relative to the camera.&...


1

I had this problem too. You just have to source the corresponding setup.bash for the terminal that runs rviz and the /voxblox_node/mesh topic will be available to show in rviz.


Only top voted, non community-wiki answers of a minimum length are eligible