The spatio_temporal_voxel_layer's discuss from stevemacenski

  //hash function this  TODO
  // projected_list<struct, uint16>, projected_list[struct]++;
  // store this for return not the vector, check if there first

resetting level set kills program

accessing it while things are inserting/deleting / when accessor objects are in scope is bad.

Evaluating other solutions to find frustum points

Luke mentioned convex hull, I brought up azmith & altitude method, others maybe more efficient

baseline memory footprint at save time via:

http://www.openvdb.org/documentation/doxygen/classopenvdb_1_1v5__0_1_1Grid.html#a5f5d5dcea1d8bee1f7752c5b99d4acbc

Costmap not getting cleared properly

Hello, I'm using this configuration

rgbd_obstacle_layer:
    enabled:               true
    voxel_decay:           15     #seconds if linear, e^n if exponential
    decay_model:           0      #0=linear, 1=exponential, -1=persistent
    voxel_size:            0.05   #meters
    track_unknown_space:   true   #default space is unknown
    observation_persistence: 0.0  #seconds
    max_obstacle_height:   2.0    #meters
    unknown_threshold:     15     #voxel height
    mark_threshold:        0      #voxel height
    update_footprint_enabled: true
    combination_method:    1      #1=max, 0=override
    obstacle_range:        3.0    #meters
    origin_z:              0.0    #meters
    publish_voxel_map:     true   # default off
    transform_tolerance:   0.2    # seconds
    mapping_mode:          false  # default off, saves map not for navigation
    map_save_duration:     60     #default 60s, how often to autosave
    observation_sources:   rgbd1_mark rgbd1_clear 
    rgbd1_mark:
      data_type: PointCloud2
      topic: /throttle_filtering_points/filtered_points
      marking: true
      clearing: false
      min_obstacle_height: 0.3    #default 0, meters
      max_obstacle_height: 3.0     #defaule 3, meters
      expected_update_rate: 0.0    #default 0, if not updating at this rate at least, remove from buffer
      observation_persistence: 0.0 #default 0, use all measurements taken during now-value, 0=latest 
      inf_is_valid: false          #default false, for laser scans
    rgbd1_clear:
      data_type: PointCloud2
      topic: /throttle_filtering_points/filtered_points
      marking: false
      clearing: true
      max_z: 7.0                  # default 0, meters
      min_z: 0.1                  # default 10, meters
      vertical_fov_angle: 0.8745  # default 0.7, radians
      horizontal_fov_angle: 1.048 # default 1.04, radians
      decay_acceleration: 5.0     # default 0, 1/s^2. If laser scanner MUST be 0
      voxel_filter: true

The obstacles are detected properly and the costmap is updated, but when the points are deleted due to the voxel decay, the costmap portion corresponding to these point is not properly cleared.
Here is a video, it might be more explicit : https://youtu.be/G7ypkJwLBuM
Did you faced this error ? And if yes, do you where it come from ?

Thanks for the help

temporal voxel expiration in floatgrid voxel values

Store expiration time, duration, etc insize of the levelset

Create new Costmap3D like standard interface for ROS

Take the boiler plate items of this layer that iterface to ROS and make a costmap_3D interface class so that its easy to plug and play with a variety of 3D environment solutions.

Merge stalled PR and release v1

find a clever way to generate PC/costmap from the same full grid iteration as frustum clearing

maybe maintain the 2 from the citer from the grid in this situation. if no clearing, it just runs once over the grid

flattened costmap is easy, just +1 or -1 on clear / mark of column.

Maintaining the pointcloud is harder, unless we change the underlying data structure of PCL

Create frustum model for acceleration expiration for lidars with circular back planes - v1.5

scanning range finders or non-traditional depth cameras

Implement ros specific functions to interface with costmap_2d

i.e. updateOrigin for local costmaps, resetMaps from internal node tree issue, resize inside of level set

validate frustum math and configuration

Potential bayesian model for decay and for marking in mapping mode

Merging mapping mode for instruction updates: must still validate autosave works

use connected component analysis to accelerate orphan returns

for those users that don't do pre-processing on their depth information or segment out blobs

Configurable models for voxel expiration

linear
exponential
permanent

and if model changes or is accelerated when not viewed in frustum during measurement cycle

clearing based buffers do not need to actually store a cloud

[steve] evaulate use of formal ray logic or being scrappy about it

Model based expiration

linear, exponential, etc permanent

Toggle activation freeze from replanning and/or clearing costmap bug

yaml service for adding and removing keep out zones - v1.5

expose and allow for loading them at runtime from a yaml if provided

take polygon, convert to a MeasurementReading of height _mark_threshold and append to static_observations.

Store decay model and specifics in buffer for level_set calculations

--> voxel grid filter

restarting plugin freezes up

potentially from buffer, _voxel_pub.getNumSubscribers>0, or grid insertion

Would it be useful to have a service to save these 3D maps to file for manipulation, later reloading and localizing, visualizations, or anything else?

Pipeline would be something along the lines of traditional 2D slam to build a map, localizing, running the navigation stack, collect measurements to build this map from the 2D pose estimates, then can later use this for XYZ with alignment/scale on the 2D planar map

fix normal vector transformation

Remove ROS dependency on level-set and frustum from logging

cache the _cost_map instead of clearing and repopulating - v1.5

Implement local costmap functions for nav stack

Optionally, make local costmap return a deep copy of the local costmap sized area of the global costmap.

Create mapping mode

would:

disable clearing
save grids at regular intervals
publish this occupancy grid or open vdb viewer?

Work needed to support good maps in dynamic environments

probabilistic marking

Utils needed

VDB -> Pointcloud

costmap maintaining rather than each update - v1.5

for case of no voxel decay, or replacement plugin for traditional raytracing for some users, or when doing only local iteration for frustum bounding box estimations

Parallelize clearing of frustums stabally - v1.5

remove excess reset

spatio_temporal_voxel_layer/src/spatio_temporal_voxel_layer.cpp

Line 535 in deae202

Costmap2D::resetMaps();

Find voxel blobs - v1.5

in connected-component to the static map (2D, later 3D as well)
blobs not connected to map, static
blobs that are moving not disconnected from static map

Validate interior checks

Check that the dots and vector transforms do as intended for accelerating the interior of frustums.

merge openexr into rosdep to allow ros build farm builds

Parallelize and optimize to run at minimum 5hz on amd i7

build with Melodic

--> merge trees

http://www.openvdb.org/documentation/doxygen/codeExamples.html#sXformTools

Voxel grid and costmap stop marking

Observed this after the costmap reset was triggered and when there were a lot of voxels left marked. Normal behavior was restored after the grid was purged by another reset or when all previously marked voxels expired

Allow for voxel size to vary from static map size - v1.5

The voxel size in openvdb should not be required to be the same as the size of the static map. I want to be able to have a more dense, descriptive environment to work with and then downsample to the static map size for layering.

combine CIterator loop for 2D plane & publish PC2 and return both

Create a function to do the effective combination of these two functions to minimize the number of times we iterate through the grid. Projecting to the 2D plane should be done and pointcloud stored but not retrieved by the ROS interface layer unless publishing voxel grid is enabled.

# costmap_ros
global_frame: /base_link
robot_base_frame: /base_link

update_frequency: 4.0
publish_frequency: 4.0
static_map: false
map_type: costmap
resolution: 0.015

width: 10.0
height: 10.0

rolling_window: true
transform_tolerance: 0.4

plugins:
 - {name: rgbd_obstacle_layer, type: "spatio_temporal_voxel_layer/SpatioTemporalVoxelLayer"}


rgbd_obstacle_layer:
  enabled:                  true
  voxel_decay:              15    # seconds if linear, e^n if exponential
  decay_model:              0     # 0=linear, 1=exponential, -1=persistent
  voxel_size:               0.05  # meters
  track_unknown_space:      false  # default space is known
  max_obstacle_height:      2.0   # meters
  unknown_threshold:        15    # voxel height
  mark_threshold:           0     # voxel height
  update_footprint_enabled: true
  combination_method:       1     # 1=max, 0=override
  obstacle_range:           3.0   # meters
  origin_z:                 0.0   # meters
  publish_voxel_map:        true # default off
  transform_tolerance:      0.2   # seconds
  mapping_mode:             false # default off, saves map not for navigation
  map_save_duration:        60    # default 60s, how often to autosave
  observation_sources:      rgbd1_mark rgbd1_clear
  rgbd1_mark:
    data_type: PointCloud2
    topic: /detected_obstacles
    marking: true
    clearing: false
    min_obstacle_height: 0.1     # default 0, meters
    max_obstacle_height: 3.0     # default 3, meters
    expected_update_rate: 1.0    # default 0, if not updating at this rate at least, remove from buffer
    observation_persistence: 0.0 # default 0, use all measurements taken during now-value, 0=latest
    inf_is_valid: false          # default false, for laser scans
  rgbd1_clear:
    data_type: PointCloud2
    topic: /detected_obstacles
    marking: false
    clearing: true
    max_z: 7.0                  # default 0, meters
    min_z: 0.1                  # default 10, meters
    vertical_fov_angle: 0.8745  # default 0.7, radians
    horizontal_fov_angle: 1.048 # default 1.04, radians
    decay_acceleration: 5.0     # default 0, 1/s^2. If laser scanner MUST be 0
    voxel_filter: false          # default off, apply voxel filter to sensor, recommend on

and getting the voxel layer display as following:

My questions are:

Is, in the first place, Spatio-Temporal-Voxel-Layer supposed to update costmap_2d? If yes, what could be wrong in the configuration?
Voxels appear and disappear which should be part of acceleration and decay but seems to be very non-deterministic and couldn't be set to desirable/understandable behavior.

Move voxel_filter param from clearing examples to marking

Renaming

{level set, parallel, locking grid}

stevemacenski / spatio_temporal_voxel_layer Goto Github PK

spatio_temporal_voxel_layer's Issues

Recommend Projects

Recommend Topics

Recommend Org