Closed MoffKalast closed 4 years ago
@MoffKalast thanks for the PR and review request. As a procedural note, the assignee should be the person that is currently working on the PR, generally not the reviewers. This way it is easy to see who the PR belongs to on the projects board.
If I want the robot to turn around, continuing to go forward while doing so would be incorrect.
Well yes, but actually no. The robot should indeed stop, but not instantly since that results in a very intensive braking manever that can supposedly harm the motor's plastic gears - and also spill potential cargo. This should bring the robot to a stop during the rotation phase. The entire idea is to make all movement smoother at the expense of exact positioning.
Then again I haven't really tested what exactly happens if it tries to turn 180 at max speed, so I'll definitely attempt that when I get the chance.
We need to extend the obstacle distance function to be able to calculate along the curve, or else you could have problems when the robot is near a wall.
Hmm, fair point. The rotation system already has an obstacle check for left and right though and it's also operating at the time, though it only influences rotation. That could end up working fine if the robot finds a wall and simply stops rotating to avoid it, the question is if the forward sonar will even pick up the wall in such an orientation.
And it's not like we can do much in terms of advanced curve planning when we only have sonars of questionable reliability only every 45 degrees.
Anyhow, it needs to be tested with an actual sonar board before we can say anything.
the assignee should be the person that is currently working on the PR, generally not the reviewers
Right, fixed. I was not entirely sure if simply assigning people would send any notifications.
The move_basic obstacle detector also supports Lidar and possibly the ToF system. Obviously the sonars are significantly lower quality data sources, but we should still attempt to be correct.
Maybe an interim solution for all this is just smoothly decelerating to a stop before we start turning, and calculate the turning angle only after we stop.
I'll try to look into that when possible. Thing is, stopping at a goal should be optional since it very much isn't desired behaviour if you want to continuously follow goals to maximize overall travel speed.
What I've done for now regarding angle based cornering is adding two parameters - min and max corner braking values that scale braking power depending on the sharpness of the angle. That way it's possible to not brake at all at very shallow angles and stop completely at wide ones, which seems to work fine for now. Testing at high speed and giving it a goal at 180 degrees would make it veer off quite severely with the previous setup of one general parameter.
Added parameter toggleable smooth cornering as seen here.
Upon receiving a new goal the linear velocity is preserved for a short time to prevent sudden stops at high speed that degrade wheel gears and spill cargo. Theoretically it should reduce accuracy a bit, though I haven't observed anything drastic during testing so far. It's safe to say that I haven't covered even close to all edge cases though.
It should stop once an obstacle is found during the time of slowdown, however I don't have a sonar board on hand to test that part out.