nigeno's profile - activity

Ok, the reason was pretty obvious. The publisher is located on one machine, and the subscriber (Rviz or Plotjugger or an

Ubuntu 20.04 ROS2 Foxy C++

Why would Rviz slow down the program running /map publisher when subscribed to the topic?

The following error pops up. The map is displayed but getting updated agonizingly slow.

~$ rviz2 rviz2
[INFO] [1649261852.934675573] [rviz2]: Stereo is NOT SUPPORTED
[INFO] [1649261852.934911179] [rviz2]: OpenGl version: 3.1 (GLSL 1.4)
[INFO] [1649261853.023261324] [rviz2]: Stereo is NOT SUPPORTED
[INFO] [1649262370.083874343] [rviz2]: Trying to create a map of size 400 x 200 using 1 swatches
[ERROR] [1649262370.087614431] [rviz2]: Vertex Program:rviz/glsl120/indexed_8bit_image.vert Fragment Program:rviz/glsl120/indexed_8bit_image.frag GLSL link result : 
active samplers with a different type refer to the same texture image unit

Update:

Bandwidth of the /map publisher drops from 600KB/s to 50KB/s

Frequency drops from 7Hz to 0.4Hz.

BTW it's not only Rviz, with plotjuggler program I see the same slowdown.

Ok, the reason was pretty obvious. The publisher is located on one machine, and the subscriber (Rviz or Plotjugger or an

Rviz slows down publisher when subscribed to /map topic? Ubuntu 20.04 ROS2 Foxy C++ Why would Rviz slow down the progra

Rviz slows down publisher when subscribed to /map topic? Ubuntu 20.04 ROS2 Foxy C++ Why would Rviz slow down the progra

Rviz error for /map topic: Vertex Program... Ubuntu 20.04 ROS2 Foxy C++ Please advise what's the following error is abo

Rviz error for /map topic: Vertex Program... Ubuntu 20.04 ROS2 Foxy C++ Please advise what's the following error is abo

Rviz error for /map topic: Vertex Program... Ubuntu 20.04 ROS2 Foxy C++ Please advise what's the following error is abo

PointCloud2 to xyz array in ROS2 I'm trying to find a solution of converting PointCloud2 message data into xyz array for

PointCloud2 to xyz array in ROS2 I'm trying to find a solution of converting PointCloud2 message data into xyz array for

slam_toolbox life-long mapping doesn't work I've tested slam_toolbox producing life-long environment mapping, and not qu

slam_toolbox life-long mapping doesn't work I've tested slam_toolbox producing life-long environment mapping, and not qu

Installed slam_toolbox on Foxy, Ubuntu 20.04:

sudo apt install ros-foxy-slam-toolbox

Set up the yaml like:

odom_frame: odom
    map_frame: map
    base_frame: base_link
    scan_topic: /scan

Run

ros2 launch slam_toolbox online_sync_launch.py

Provided transforms:

odom -> base_link - dynamic from odom node (or static for testing - the same result)

base_link -> laser - static

ros2 run tf2_ros static_transform_publisher 0 0 0 0 0 0 base_link laser

I see the /map topic in Rviz.

Rviz has an error but still show the map:

[INFO] [1648148542.387284934] [rviz2]: Trying to create a map of size 299 x 171 using 1 swatches
[ERROR] [1648148542.393145177] [rviz2]: Vertex Program:rviz/glsl120/indexed_8bit_image.vert Fragment Program:rviz/glsl120/indexed_8bit_image.frag GLSL link result : 
active samplers with a different type refer to the same texture image unit

The messages from slam_toolbox node:

INFO] [launch]: All log files can be found below /home/ys/.ros/log/2022-03-24-15-01-57-027859-ys-ubuntu-39307
[INFO] [launch]: Default logging verbosity is set to INFO
[INFO] [sync_slam_toolbox_node-1]: process started with pid [39309]
[sync_slam_toolbox_node-1] [INFO] [1648148517.251239498] [slam_toolbox]: Node using stack size 40000000
[sync_slam_toolbox_node-1] [INFO] [1648148517.343822743] [slam_toolbox]: Using solver plugin solver_plugins::CeresSolver
[sync_slam_toolbox_node-1] [INFO] [1648148517.345019501] [slam_toolbox]: CeresSolver: Using SCHUR_JACOBI preconditioner.
[sync_slam_toolbox_node-1] Registering sensor: [Custom Described Lidar]

Why do I have this weird looking map? With the same input I'm getting a perfect map with gmapping slam.

It's not only Rviz issue BTW. I'm really getting occupancy grid 2D array with this layout.

It appears like the mapping looks good in the area close to the scanner. Could it be that it's the maximum distance issue? My scanner is long range laser and the grid on the pic is 1m.

I'm using a fork of slam_gmapping package for ROS2: https://github.com/Project-MANAS/slam...

As we all know, it requires the odometry tf transformation. Specifically, it requires the following transforms:

  cloud => base_link (where "cloud" is my laser_base frame)
  base_link => odom

As an output SLAM provides

odom => map transform

I was able to make it working with static transformations. So, I provided cloud => base_link and base_link => odom transforms and everything worked just fine. This is situation when my laser is static/no motion.

The following step was going to be pretty simple, but turned out to be not easy as I expected. If my laser is moving, then the solution to it is to leave the cloud => base_link as a static transform, and to add a dynamic transform base_link => odom, initiated either with the wall time (let's say 100ms) or as a callback to /odom message.

    now = this->get_clock()->now();
    transformStamped.header.stamp = now;
    transformStamped.header.frame_id = "odom";
    transformStamped.child_frame_id = "base_link";
    transformStamped.transform.translation.x = 0.0;
    transformStamped.transform.translation.y = 0.0;
    transformStamped.transform.translation.z = 0.0;
    transformStamped.transform.rotation.x = 0.0;
    transformStamped.transform.rotation.y = 0.0;
    transformStamped.transform.rotation.z = 0.0;
    transformStamped.transform.rotation.w = 1.0; 
    tf_broadcaster1_->sendTransform(transformStamped);

I tried different combinations and methods, no luck so far. My guess is that it might related to how the tf transforms are timed. I don't quite understand yet how this message filter is working, that's what it gives:

[slam_gmapping-1] [INFO] [1643650251.253186111] [slam_gmapping]: Message Filter dropping message: frame 'cloud' at time 1640201165.546 for reason 'Unknown

I cannot upload the pic of tf tree (given with ros2 run tf2_tools view_frames.py command), but it looks good to me: map => odom => base_link => cloud.

So, probably my question would boil down to the following: why having the static transforms everything works fine, and exchanging one transform (odom => base_link) would result in such an error. How specifically I can check that the transform is carried out properly and expected for the slam_gmapping algorithm.

PS: the forked gmapping looks the same as popular https://github.com/ros-perception/sla... for ROS1, but not officially supported as https://github.com/SteveMacenski/slam....

I'm trying to solve this puzzle. It seems to be simple but it doesn't work.

So, the OdomNode is subscribed to the original LaserScan message on /sick_lrs_36x1/scan topic. It receives the message and call LaserScan publisher to publish the message on /scan topic. A customized message is published with a new frame_id and with now timestamp.

The original scan message is getting played using the bag tool.

Running

ros2 topic echo /sick_lrs_36x1/scan

seems to give exact message as

ros2 topic echo /scan message

Interestingly, I can observe the /sick_lrs_36x1/scan in rviz, but cannot see the customized message.

Below is my code:

class OdomNode : public rclcpp::Node
{
public:
    OdomNode() : Node("odom")
    {
        scan_ = this->create_subscription<sensor_msgs::msg::LaserScan>("/sick_lrs_36x1/scan", rclcpp::SensorDataQoS(),
                                    std::bind(&OdomNode::callbackPose, this, std::placeholders::_1));
        publisher_ = this->create_publisher<sensor_msgs::msg::LaserScan>("scan", rclcpp::SensorDataQoS());                            
    }

private:
    void callbackPose(const sensor_msgs::msg::LaserScan::SharedPtr msg)
    {   

        now = this->get_clock()->now();

        sensor_msgs::msg::LaserScan laser;
        laser.header.frame_id = "cloud";
        laser.header.stamp = now;
        laser.angle_min = msg->angle_min;
        laser.angle_max = msg->angle_max;
        laser.angle_increment = msg->angle_increment;
        laser.scan_time = msg->scan_time;
        laser.time_increment = msg->time_increment;
        laser.range_min = msg->range_min;
        laser.range_max = msg->range_max;
        laser.ranges = msg->ranges;
        publisher_->publish(laser);

    }

    rclcpp::Time now;
    rclcpp::Subscription<sensor_msgs::msg::LaserScan>::SharedPtr scan_;
    rclcpp::Publisher<sensor_msgs::msg::LaserScan>::SharedPtr publisher_;
    rclcpp::TimerBase::SharedPtr transform_timer_;
};

int main(int argc, char **argv)
{
    rclcpp::init(argc, argv);
    auto node = std::make_shared<OdomNode>();
    rclcpp::spin(node);
    rclcpp::shutdown();
    return 0;
}

it is a general question.

Gmapping seems to be used only for creating a map of the static environment. Once created, it doesn't account for any changes - you add a new object, but it's being ignored and not reflected in the map.

Is there any way to modify gmapping so it can be used for changing environments? What other methods can be used in this case?

I don't care about localization, only need mapping of the dynamically changing environment.

Any thoughts or comments are very welcome!

Thank you. Actually when I moved the scanner, the mapping filled itself, so it appears like the behavior is normal, thou

slam_toolbox incomplete mapping Installed slam_toolbox on Foxy, Ubuntu 20.04: sudo apt install ros-foxy-slam-toolbox

slam_toolbox incomplete mapping Installed slam_toolbox on Foxy, Ubuntu 20.04: sudo apt install ros-foxy-slam-toolbox

slam_toolbox incomplete mapping Installed slam_toolbox on Foxy, Ubuntu 20.04: sudo apt install ros-foxy-slam-toolbox

It appears like the term for dynamic mapping is life-long mapping. There's an experimental implementation of this algori

It appears like the term for dynamic mapping is life-long mapping. There's an experimental implementation of this algori