davidbsp / patrolling_sim Goto Github PK

I'm using a modified version of the simulator that logs the xy coordinates of all patrol agents every second. The positions are logged from the patrol agent with id 0, from the PatrolAgent.xPos and patrolAgent.yPos attributes. I have noticed that if two robots collide in an unrecoverable fashion (a fairly rare occurrence, but running 6 agents using some strategies for multiple hours causes this to occur quite often) and the robots enter a stall state in Stage, their position as reported sometimes keeps varying, even though they have stalled in simulation. This disconnect between Stage's representation of the patrol agents and the ROS representation means that if the robots believe they are still moving, as they are not interacting with Stage properly they do not interact with obstacles in Stage and sometimes report positions that are inside obstacles. I have no idea how fixable this is or if it is even worth trying to address, as I have only seen it typically occur when the simulator is running for several hours continuously, but I felt I should make you aware of what I've found.

I am a newbie in ROS and learning to run patrolling_sim.

Environment: Windows 7 64-bit host, VM (Ubuntu 16.04 LTS and ROS Kinetic).

Following instruction from README.md.

1. I copied the code of patrolling_sim (https://github.com/davidbsp/patrolling_sim) to /home/top/catkin_ws/src/;
2. I have succeeded in compiling the source code('catkin_make');
3. I start the script './start_experiment.py', and pressed the button 'start experiment' to run a simulation.

However, I have some trouble in running the simulation as follows:

1. Runtime window show that “ERROR: Parameter [/SimulationRunning] is not set”.

2. Robots in the visualization window are always static, which is different from what the video show. (http://wiki.ros.org/patrolling_sim).
   

Therefore, I tried to solve this problem by modifying the script file (start_experiment.py). Unfortunately, the problem is still unsolved.

Hi,

I am using ROS Hydro on ubuntu 12.04. I was using this package earlier without any trouble. I recently upgraded it to the newest version. Did catkin_make and ran the start_experiment script, but getting this error :

rd@robotics:~/catkin_ws/src/patrolling_sim$ ./start_experiment.py
Unhandled exception in thread started by <function run_experiment at 0x1323500>
TypeError: run_experiment() takes exactly 12 arguments (11 given)

Can you help me with this???

Thanks

Alex

I am running the simulator in ROS Noetic on Ubuntu 20.04.

When running in ROS navigation mode, I encountered this warning and error constantly displaying for all robots:
[ERROR] [1652286776.128019954, 24.300000000]: TF Exception that should never happen for sensor frame: robot_0/base_laser_link, cloud frame: /robot_0/base_laser_link, Invalid argument "/robot_0/base_laser_link" passed to lookupTransform argument source_frame in tf2 frame_ids cannot start with a '/' like: Warning: Invalid argument "/robot_0/base_laser_link" passed to canTransform argument source_frame in tf2 frame_ids cannot start with a '/' like: at line 134 in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp
Tracing this through move_base showed it must have come from a callback in the ObstacleLayer class. I also saw that when starting robots, the following warning displayed:
[ WARN] [1652286665.985781620, 15.500000000]: global_costmap: Parameter "plugins" not provided, loading pre-Hydro parameters
By modifying the param files for the costmaps I think I was able to solve both of these (the previously mentioned warnings and error disappeared at least)- I'm not sure exactly what was going on here but it appears that the pre-Hydro parameters being loaded was causing the attempt to use a TF frame starting with '/' during obstacle detection, which would also explain the constant robot collisions I was getting. Any thoughts on this issue would be appreciated.

However, this did not totally solve the main problem I was having with the simulator- when running in ROS navigation mode, robots were constantly crashing into walls and each other, and failing to recover. The change mentioned above significantly improved this, but did not solve it completely, and I still regularly encounter unrecoverable robot crashes. When using spqrl navigation this problem does not occur at all- what rate of unrecoverable crashes could be considered normal, and is there anything to be done about this?

Now each algorithm has its own send/receive functions to send and receive robot-robot messages.
Check if these messages are actually needed for each algorithm and remove/simplify what is not needed.

Hi davidbsp,
first of all, thank you for your work ! On the README, you mentioned a possible merged coming soon, implementing "a distributed execution of the patrolling environment that can be used also on real robots."
Is this merged still relevant ? What do we have to do to use one of your algorithm on real robots ?
Best regards.

TODO -- A solution like this to choose the TIMEOUT time: