ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

mcarr's profile - activity

2021-04-14 04:30:10 -0500 received badge  Good Answer (source)
2020-05-05 23:31:04 -0500 received badge  Nice Answer (source)
2018-11-28 05:58:12 -0500 received badge  Famous Question (source)
2018-10-12 03:49:12 -0500 commented answer Costmap2D failing to mark laser scan data as obstacles on one side

Thanks for the help, I found the problem and posted the solution

2018-10-12 03:48:57 -0500 marked best answer Costmap2D failing to mark laser scan data as obstacles on one side

My obstacle layer is only marking obstacles on one half of the robot. image description

The raw laser scan data is correct and it is correctly visualised in RVIZ and you can see. The unmarked obstacles are always on the right-side of the robot (0 to -pi), even as it turns in the costmap. If it was an issue with the costmap itself, I would expect the error to be independent of the robot, however this is not the case.

Does this look familiar or have any suggestions?

local_costmap_params.yaml:

local_costmap:
  global_frame: odom
  robot_base_frame: base_link
  update_frequency: 5.0
  publish_frequency: 2.0
  static_map: false
  rolling_window: true
  width: 7.0
  height: 7.0
  resolution: 0.05
  transform_tolerance: 0.5

  plugins:
   #- {name: sonar_layer, type: "range_sensor_layer::RangeSensorLayer"}
   - {name: obstacle_layer, type: 'costmap_2d::ObstacleLayer'}
   - {name: inflation_layer, type: 'costmap_2d::InflationLayer'}

  sonar_layer:
    topics: ['/ultrasonic1','/ultrasonic2','/ultrasonic3']
    clear_threshold: 0.4
    mark_threshold: 0.6
    clear_on_max_reading: true
    no_readings_timeout: 0.0

common_costmap_params.yaml:

footprint: [[0.28, 0.245], [0.28,-0.245], [-0.28,-0.245], [-0.28,0.245]]
obstacle_layer:
  observation_sources: laser_scan_sensor
  laser_scan_sensor:
    topic: /scan
    sensor_frame: /scan
    data_type: LaserScan
    marking: true
    clearing: true
    expected_update_rate: 5.0
    inf_is_valid: true
  obstacle_range: 6
  raytrace_range: 15

inflation_layer:
  inflation_radius: 0.35
  cost_scaling_factor: 10.0

TF publisher from /base_link to /scan:

<node name="base_link_to_scan" pkg="tf" type="static_transform_publisher" args="0.20 0 0 3.1415 0 0 /base_link /scan 100"/>

EDIT 1

warning message on move_base bringup:

[ INFO] [1539238779.564957513]: Using plugin "obstacle_layer"
[ INFO] [1539238779.620244801]:     Subscribed to Topics: laser_scan_sensor
[ INFO] [1539238780.103866224]: Using plugin "inflation_layer"
[ WARN] [1539238780.699934704]: Illegal bounds change, was [tl: (-179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.000000, -179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.000000), br: (179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.000000, 179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.000000)], but is now [tl: (-340282346638528859811704183484516925440.000000, -340282346638528859811704183484516925440.000000), br: (340282346638528859811704183484516925440.000000, 340282346638528859811704183484516925440.000000)]. The offending layer is local_costmap/inflation_layer
[ INFO] [1539238780.918647320]: Created local_planner base_local_planner/TrajectoryPlannerROS
[ INFO] [1539238781.130984061]: Sim period is set to 0.10
[ INFO] [1539238782.598323429]: Recovery behavior will clear layer obstacles
[ INFO] [1539238782.684406268]: Recovery behavior will clear layer obstacles

EDIT 2

Local Costmap is centered on the robot:

image description

result from echo on /scan

    header: 
  seq: 660
  stamp: 
    secs: 1539183847
    nsecs: 932467526
  frame_id: "scan"
angle_min: -3.12413907051
angle_max: 3.14159274101
angle_increment: 0.00871450919658
time_increment: 9.44497514865e-05
scan_time: 0.0679093673825
range_min: 0.15000000596
range_max: 12.0
ranges: [3.6559998989105225, 3.635999917984009, 3.611999988555908, 3.6080000400543213, 3.0759999752044678, 3.2079999446868896, 3.7200000286102295, 3.7200000286102295, 3.6640000343322754, 3.6440000534057617, 3.6480000019073486, 2.5920000076293945, 2.615999937057495, inf, 2.6559998989105225, 2.6559998989105225, 2.6480000019073486, 2.635999917984009, 2.631999969482422, 2.635999917984009, 2.631999969482422, 2.631999969482422, 2.611999988555908, 2.6080000400543213, 2.611999988555908, 2.619999885559082, 2.628000020980835, 2.615999937057495, 2.615999937057495, 2.611999988555908, 2.611999988555908, 2.611999988555908, 2.619999885559082, 2.624000072479248, 2.624000072479248, 2.6440000534057617, 2.6480000019073486, 2.640000104904175, 2.6640000343322754, 2.6640000343322754, 2.671999931335449, 2.6679999828338623, 2.6760001182556152, 2.6760001182556152, 2.680000066757202, 2.687999963760376, 2.691999912261963, 2.691999912261963, 2.7039999961853027, 2.7239999771118164, 2.7279999256134033, 2.7279999256134033, 2.7320001125335693, 2.752000093460083, 2.75600004196167, 2.75600004196167, 2.75600004196167, 2.7679998874664307, 2.7839999198913574, 2.7839999198913574, 2.7960000038146973, 2.812000036239624, 2.808000087738037, 2.7920000553131104, 2.7920000553131104, 2.7799999713897705, 2.7960000038146973, 2.808000087738037, 2 ...
(more)
2018-10-12 03:48:47 -0500 answered a question Costmap2D failing to mark laser scan data as obstacles on one side

The problem was in the TF transform from odom -> base_link. I am using robot_localization to fuse IMU and wheel odome

2018-10-12 03:18:23 -0500 commented answer Costmap2D failing to mark laser scan data as obstacles on one side

Reset everything back to default but no difference. However it's my robot_localization node at fault! The transform it's

2018-10-11 05:37:22 -0500 received badge  Notable Question (source)
2018-10-11 05:07:01 -0500 commented answer Costmap2D failing to mark laser scan data as obstacles on one side

I'm using RPLidar A2M8. I have done exactly what you said and set the expected rate to twice as fast as it's publishing.

2018-10-11 03:26:40 -0500 edited question Costmap2D failing to mark laser scan data as obstacles on one side

Costmap2D failing to mark laser scan data as obstacles on one side My obstacle layer is only marking obstacles on one ha

2018-10-11 03:15:25 -0500 commented answer Costmap2D failing to mark laser scan data as obstacles on one side

The local Costmap is centered around the robot, I've added a picture to show this. Also using rqt_reconfigure the size o

2018-10-11 02:59:20 -0500 received badge  Famous Question (source)
2018-10-11 01:49:29 -0500 received badge  Popular Question (source)
2018-10-11 01:34:33 -0500 edited question Ultrasonic sensor with range_sensor_layer not forming cone obstacles

Ultrasonic sensor with range_sensor_layer not forming cone obstacles Hi, I am able to form a costmap using my Lidar dat

2018-10-11 01:31:43 -0500 commented answer Ultrasonic sensor with range_sensor_layer not forming cone obstacles

The main issue - not forming cone obstacles - is still an issue. Will update question

2018-10-11 01:31:38 -0500 commented answer Ultrasonic sensor with range_sensor_layer not forming cone obstacles

The main issue - not forming cone obstacles - is still an issue. Will update questions

2018-10-11 01:25:22 -0500 commented answer Costmap2D failing to mark laser scan data as obstacles on one side

In local_costmap_params.yaml, I have commented out the sonar_layer (range_sensor_layer) so it shouldn't have any effect

2018-10-11 01:22:46 -0500 edited question Costmap2D failing to mark laser scan data as obstacles on one side

Costmap2D failing to mark laser scan data as obstacles on one side My obstacle layer is only marking obstacles on one ha

2018-10-11 01:17:30 -0500 commented answer Costmap2D failing to mark laser scan data as obstacles on one side

@rike93 - As you can see in local_costmap_params.yaml, I have commented out the sonar_layer (range_sensor_layer) so it s

2018-10-10 10:24:58 -0500 edited question Costmap2D failing to mark laser scan data as obstacles on one side

Costmap2D failing to mark laser scan data as obstacles 360 degrees My obstacle layer is only marking obstacles on one ha

2018-10-10 10:24:37 -0500 asked a question Costmap2D failing to mark laser scan data as obstacles on one side

Costmap2D failing to mark laser scan data as obstacles 360 degrees My obstacle layer is only marking obstacles on one ha

2018-10-10 08:57:22 -0500 commented answer Ultrasonic sensor with range_sensor_layer not forming cone obstacles

Cheers, realised that I didn't understand how Costmap2D worked really with the layers as plugins and such. Still haven't

2018-10-10 08:56:19 -0500 marked best answer Ultrasonic sensor with range_sensor_layer not forming cone obstacles

Hi,

I am able to form a costmap using my Lidar data and move_base through the ROS Navigation stack. However when I try to integrate an ultrasonic sensor to the costmap using range_sensor_layer there are 2 problems:

  1. The Lidar is no longer creating obstacles on the local costmap
  2. The Ultrasonic sensor is only creating obstacles in line of single pixels in front of the robot (by pixels I mean the smallest unit of map resolution, 0.05m in my case)

Below: local costmap created from lidar, without the range_sensor_layer plugin. Everything working fine

Local costmap created from lidar:

Below: Costmap with range_sensor_layer plugin active. I moved an object towards the ultrasonic sensor starting at about 80cm, moving to 30cm (it doesn't clear objects behind others thus why is forms a line). The robot is located at the center cross facing right in both these images

Local costmap created from ultrasonic sensor

I have tried playing with the parameters discussed in range_sensor_layer but this did not help. Is there some blatant oversight that I'm making? Below are my config files

costmap_common_params.yaml

obstacle_range: 4.0
raytrace_range: 5.0
footprint: [[0.075, 0.235], [0.075,-0.235], [-0.455,-0.235], [-0.455,0.235]]
inflation_radius: 0.55

observation_sources: laser_scan_sensor

laser_scan_sensor: {sensor_frame: /scan, data_type: LaserScan, topic: /scan, marking: true, clearing: true}

sonar:
  topics: ['/ultrasonic']
  clear_threshold: 0.3
  mark_threshold: 0.6
  clear_on_max_reading: true
  no_readings_timeout: 2.0

plugins:
  - {name: sonar, type: "range_sensor_layer::RangeSensorLayer"}
  - {name: obstacle_layer, type: "costmap_2d::ObstacleLayer"}
  - {name: inflation_layer, type: "costmap_2d::InflationLayer"}

local_costmap_params.yaml

local_costmap:
  global_frame: odom
  robot_base_frame: base_link
  update_frequency: 5.0
  publish_frequency: 2.0
  static_map: false
  rolling_window: true
  width: 6.0
  height: 6.0
  resolution: 0.05

global_costmap_params.yaml

global_costmap:
  global_frame: /map
  robot_base_frame: base_link
  update_frequency: 5.0
  static_map: false
  rolling_window: true
  height: 10.0
  width: 10.0
  resolution: 0.05

And here is my Ultrasonic message:

image description

EDIT 1

The ultrasonic sensors are now marking obstacles after fixing the different layers and plugins in Costmap2D. However the range_sensor_layer package is still only marking dots, instead of arcs on the costmap. Is it even supposed to mark arcs? Maybe my understanding is incorrect. However there are field of view parameters so I would assume it is supposed to mark an arc obstacles at the detected range.

image description

2018-09-24 13:26:09 -0500 received badge  Notable Question (source)
2018-09-24 04:02:58 -0500 received badge  Popular Question (source)
2018-09-24 03:23:17 -0500 edited question Ultrasonic sensor with range_sensor_layer not forming cone obstacles

range_sensor_layer not forming cone obstacles Hi, I am able to form a costmap using my Lidar data and move_base through

2018-09-24 03:22:08 -0500 edited question Ultrasonic sensor with range_sensor_layer not forming cone obstacles

range_sensor_layer not forming cone obstacles Hi, I am able to form a costmap using my Lidar data and move_base through

2018-09-24 03:21:18 -0500 edited question Ultrasonic sensor with range_sensor_layer not forming cone obstacles

range_sensor_layer not forming cone obstacles Hi, I am able to form a costmap using my Lidar data and move_base through

2018-09-24 03:21:01 -0500 edited question Ultrasonic sensor with range_sensor_layer not forming cone obstacles

range_sensor_layer not forming cone obstacles Hi, I am able to form a costmap using my Lidar data and move_base through

2018-09-24 03:17:10 -0500 edited question Ultrasonic sensor with range_sensor_layer not forming cone obstacles

range_sensor_layer not forming cone obstacles Hi, I am able to form a costmap using my Lidar data and move_base through

2018-09-21 09:10:47 -0500 asked a question Ultrasonic sensor with range_sensor_layer not forming cone obstacles

range_sensor_layer not forming cone obstacles Hi, I am able to form a costmap using my Lidar data and move_base through

2018-09-06 08:40:28 -0500 received badge  Enlightened (source)
2018-09-06 08:40:28 -0500 received badge  Good Answer (source)
2018-09-06 08:40:24 -0500 received badge  Nice Question (source)
2018-07-09 14:04:54 -0500 marked best answer Arduino Ethernet Driver | Custom hardware publishing on topic via ethernet

I have a custom sensor which I am using with an Arduino. My ultimate goal (TL:DR) is to publish these sensor values on a ROS topic via Ethernet.

I am using a Ethernet shield and have completed the Arduino Ethernet tutorial which walked through creating a server which 'publishes' the sensor data via HTTP. On my PC browser (on the same network) I can navigate to the server/ethernet shield IP address and view the sensor values. I am familiar with fundamental ROS concepts but just a beginner in Ethernet communication, TCP/IP, etc

So what I'm trying to do is write a driver which 'reads' these sensor values, formats them into a custom rosmsg and publishes this rosmsg on a topic.

I would appreciate some tips if anyone is familiar with interfacing between custom hardware and ROS via ethernet. How would one go about the above things I mentioned? I guess it's to set up a socket listening to the sensor but have no idea how to start on this. I realise that a many sensor drivers do a similar thing as I'm trying to do. I know some SICK sensors communicate via Ethernet so effectively I'm trying to reproduce the same funtionality with my custom hardware. I did look at some of these drivers however couldn't understand them very well. If anyone has any links to tutorials / guide of something similar that would be great.

Also if anyone has any wisdom to impart or tips to offer, that would be great!

Cheers

2018-05-22 02:57:35 -0500 marked best answer Poor performance of base_local_planner - advice for parameter tuning?

Hi All,

I am having some issues with object avoidance when using move_base. As you can see in this video I made the robot doesn't navigate the obstacles in a smooth manner. My suspicion is that my local_planner parameters need tuning. However I've spend hours playing with all the different parameters and am not seeing improved results. I have checked my odometry data and it's very accurate, so that's not the problem.

I'll attach my parameter configuration files below. I would really appreciate any tips, particularly from those who have success in tuning their robots to navigate smoothly around obstacles.


base_local_planner_params.yaml

controller_frequency: 2.0
recovery_behavior_enabled: false
clearing_rotation_allowed: false

TrajectoryPlannerROS:
   max_vel_x: 0.36
   min_vel_x: 0.2
   max_vel_y: 0.0  # zero for a differential drive robot
   min_vel_y: 0.0
   max_vel_theta: 0.7
   min_vel_theta: -0.7
   min_in_place_vel_theta: 0.5
   escape_vel: -0.15
   acc_lim_x: 0.3 # From test trials (0.304,0.285,0.26,0.365)
   acc_lim_y: 0.0 # zero for a differential drive robot
   acc_lim_theta: 1.0 #probably closer to 1.3 

   holonomic_robot: false
   yaw_goal_tolerance: 0.25 # about 12 degrees
   xy_goal_tolerance: 0.25  # 20 cm
   latch_xy_goal_tolerance: false
   pdist_scale: 0.6
   gdist_scale: 0.7
   meter_scoring: true

   heading_lookahead: 0.375

   heading_scoring: false
   heading_scoring_timestep: 0.8
   occdist_scale: 0.01
   oscillation_reset_dist: 0.05
   publish_cost_grid_pc: false
   prune_plan: true

   #sim_time: 4
   sim_granularity: 0.025
   angular_sim_granularity: 0.025
   vx_samples: 8
   vy_samples: 0 # zero for a differential drive robot
   vtheta_samples: 20
   dwa: true
   simple_attractor: false

costmap_common_params.yaml

obstacle_range: 4.0
raytrace_range: 5.0
inf_is_valid: false
robot_radius: 0.3 # - dont need a radius if we have a footprint.
inflation_radius: 0.3
# footprint: [[-15,0.26],[0.42,0.26],[0.42,-0.26],[-15,-0.26]] # Note Base_link is on top of the lidar and x axis is forwards


observation_sources: scan
scan:
  data_type: LaserScan
  topic: scan
  marking: true
  clearing: true    

map_type: costmap

global_costmap_params.yaml

global_costmap:
   global_frame: /map
   robot_base_frame: /base_footprint
   update_frequency: 1.0
   publish_frequency: 0.5
   static_map: true
   rolling_window: false
   resolution: 0.025
   transform_tolerance: 1.0
   map_type: costmap

local_costmap_params.yaml

local_costmap:
   global_frame: /odom
   robot_base_frame: /base_footprint
   update_frequency: 1
   publish_frequency: 2
   static_map: false
   rolling_window: true
   width: 5.0
   height: 5.0
   resolution: 0.025
   transform_tolerance: 1.0
   map_type: costmap

move_base_params.yaml

shutdown_costmaps: false

controller_frequency: 5.0 #before 5.0
controller_patience: 3.0


planner_frequency: 0.5
planner_patience: 5.0

oscillation_timeout: 10.0
oscillation_distance: 0.2

conservative_reset_dist: 0.10 #distance from an obstacle at which it will unstuck itself