Fine tuning speed and obstacle threshold parameters

[abbypribis]

Instructions for tuning:

First, you'll need to get the simulation and roslaunch files started:

$ cd SC2
$ catkin clean -y
$ source ./srcp2-competitors/ros_workspace/install/setup.bash
$ catkin build
$ ./srcp2-competitors/docker/scripts/launch/roslaunch_docker --run-round 1 --seed 10

This runs round 1 of the time with a seed - if you use the same seed every time, it'll make comparison easier.

If you want to run it without Gazebo, add --no-gui after --run-round 1. However, it might be useful to have the actual sim running in case you want to see why a robot isn't moving or the area surrounding the robot that isn't in camera view. If I do this, I open another terminal and get the camera view from the robot so I can see if it is moving:

$ rosservice call /gazebo/unpause_physics
$ rosrun image_view image_view image:=/scout_1/camera/left/image_raw

Second, open another terminal to run the roslaunch file:

$ cd SC2
$ source ./devel/setup.bash
$ roslaunch ./launch/scoot.launch "search:=searchRandomWalk"

This starts the searchRandomWalk behavior for scout_1. You should see what the different parameters are set to underneath PARAMETERS. However, you can also check through the terminal by writing:

$ rosparam get <param_name>

You can also set parameters this way - this needs to be run BEFORE running the roslaunch command:

$ rosparam set <param_name> <value>

Keep in mind that namespaces and ROS nodes matter! '/scout_1/Core/DRIVE_SPEED' is not the same as '/scout_1/DRIVE_SPEED'. Writing rosparam set with the latter would not change anything about the scout's speed.

Another way to confirm the rover's speed is to run:

$ rostopic echo /scout_1/odom/filtered

and look at the twist messages published in the x direction. Keep in mind that the x messages are in m/s and the values we set for rover speeds are in rad/s!

If you want to run the rover manually, perhaps to check whether the speed has updated, run these roslaunch arguments instead:

$ roslaunch ./launch/scoot.launch "search:=search" "mode:=manual"

Open another terminal:

$ cd SC2
$ source ./devel/setup.bash
$ ROS_NAMESPACE="/scout_1" rosrun scoot repl.py

To drive the robot in the repl:

ln [1]: scoot.drive(1)
#To turn the robot:
ln [2]: scoot.turn(math.pi)
#To ignore a volatile or obstacle exception:
ln [1]: import obstacles.msg
ln [2]: scoot.drive(1, ignore=Obstacles.IS_LIDAR)
ln [3]: scoot.turn(math.pi, ignore=Obstacles.IS_VOLATILE)

The parameters for driving you will want to mess with are: scout_1/Core/DRIVE_SPEED and possibly scout_1/Core/TURN_SPEED scout_1/Core/REVERSE_SPEED if you see a specific problem related to them.

These are set in SC2/src/scoot/launch/scoot.xml by changing the default OR you can use the rosparam commands above BEFORE running roslaunch.

The parameters for obstacle detection are: /warning_distance /safe_distance

These distances dictate when an ObstacleException is triggered.

These are not set in launch files, so you will need to change them either in the code in SC2/src/obstacle/src/Obstacle.py. You need to change the defaults in the file OR use rosparam set BEFORE running roslaunch. These two parameters WON'T show up in the list when you press tab after:

$ rosparam get

What you are looking for: Changes that cause the robot to do undesirable things, like flip over, get stuck on rocks, get stuck in craters, etc., OR changes that cause the robot to avoid doing the aforementioned behaviors.

[Carter90]

I would recommenced trying with insanely low and high values to get an idea of how the rover responds

[baelinor]

These seem to work and minimize issues I observed, however, there is a lot of 'play' here. Speed Settings (these minimize slip and joint 'bounce') param name="DRIVE_SPEED" value="5" param name="REVERSE_SPEED" value="3" param name="TURN_SPEED" value="3" Obstacle Settings (to much lower and they may bump things, and higher tends to catch odd things like going downhill) self.safe_distance = rospy.get_param('/safe_distance', default=0.7) self.warning_distance = rospy.get_param('/warning_distance', default=1.1)

Unrelated Note on Wheel Odom: Rear wheels appear to play an important role while turning. The 2 catacorner wheels (front right - rear left or front left - rear right ... turning direction dependent) often spin independently or at a higher rate than the other wheels when turning.

[Carter90]

@baelinor cool did you want to make a pull req with said tuning?

[baelinor]

Not entirely sure how to go about doing that.

[gmfricke]

I'll see if taking the average of the front and back wheels on each side improves encoder odom. Or if there is a lot of slip potentially taking the min of the front and back might be better.

On 9/9/20 12:26 AM, baelinor wrote:

These seem to work and minimize issues I observed, however, there is a lot of 'play' here. Speed Settings (these minimize slip and joint 'bounce')

Obstacle Settings (to much lower and they may bump things, and higher tends to catch odd things like going downhill) self.safe_distance = rospy.get_param('/safe_distance', default=0.7) self.warning_distance = rospy.get_param('/warning_distance', default=1.1)

Unrelated Note on Wheel Odom: Rear wheels appear to play an important role while turning. The 2 catacorner wheels (front right - rear left or front left - rear right ... turning direction dependent) often spin independently or at a higher rate than the other wheels when turning.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/BCLab-UNM/SC2/issues/100#issuecomment-689335641, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA6DSE6WJ4FIYXURACZ44CLSE4N27ANCNFSM4QNTDZOA.

[abbypribis]

@baelinor I would just make a new branch and change the speed and obstacle threshold values to the best that you observed. Then, after pushing the branch, go to Pull Requests create a new Pull Request for that branch, assign some of us to review it, and give us some instructions for testing. Thanks for the help!

[baelinor]

I can do that, but with the latest master, all I get it a host of errors and the robot never moves. I had to finish tests under Carters old randomwalk_backup. I don't want to upload errors in this late stage, or is this normal (I saw others had some fakeodom errors but, nobody mentioned the robot not moving)?

[gmfricke]

Let's talk about it on slack where everyone can see that is going on. Could you describe the errors you are seeing there. Thanks.

On 9/9/20 2:49 PM, baelinor wrote:

I can do that, but with the latest master, all I get it a host of errors and the robot never moves. I had to finish tests under Carters old randomwalk_backup. I don't want to upload errors in this late stage, or is this normal (I saw others had some fakeodom errors but, nobody mentioned the robot not moving).

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/BCLab-UNM/SC2/issues/100#issuecomment-689814023, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA6DSE6I5OYRIWMONZNRYADSE7S6HANCNFSM4QNTDZOA.