Closed abbypribis closed 3 years ago
I would recommenced trying with insanely low and high values to get an idea of how the rover responds
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.
@baelinor cool did you want to make a pull req with said tuning?
Not entirely sure how to go about doing that.
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.
@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!
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)?
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.
Instructions for tuning:
First, you'll need to get the simulation and roslaunch files started:
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:Second, open another terminal to run the roslaunch file:
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:
You can also set parameters this way - this needs to be run BEFORE running the roslaunch command:
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:
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:
Open another terminal:
To drive the robot in the repl:
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:
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.