Bug #1 Navigator with minimum radius and TRAVEL moves
Occurs when the navigator calculates its path AND the minimum turn radius is not 0 (from the MovePilot).
The navigator uses the following piece of code
Code: Select all
if (_destination.headingRequired)
{
moves = ArcAlgorithms.getBestPath(poseProvider.getPose(),
(float)minRadius, _destination.getPose(),(float)minRadius);
}
else
{
moves = ArcAlgorithms.getBestPath(poseProvider.getPose(),
_destination, (float)minRadius);
}
// 2. Drive the path
for(int i=0;i<moves.length;i++)
{
((ArcMoveController) _pilot).travelArc(moves[i].getArcRadius(),
moves[i].getDistanceTraveled(),false);
if (!_keepGoing) break;
}The ArcAlgorithm returns a set of moves. Some of the moves are not ARC type. However the Navigator sends all the moves through the travelArc() method of the move pilot. This results in unexpected behaviour. In particular, TRAVEL moves end up travelling forever instead of a fixed distance.
One fix whould be to have a switch statement in the navigator that calls the arc, travel and rotate methods from the pilot depending on the type (tested). The other might be to have the travel arc add a catch for infite radii so that the angle doesn't end up being infinite (not tested).
Bug #2 : Arc Algorithm returns negative angles
The Arc Algorithm returns negative angles in the ARC moves when it's not supposed to.
One quick work around that worked for me is adding an obsolute value to the angle (this is not pretty and a better fix should be made by someone who understands how the ArcAlgorithms work)
Bug #3 : Chassis with negative arcs and radii
When running the following method from chassis "arc(-70, -360)". Instead of rotating backward for 360 degrees around its right side, the robot rotates forward forever.
I do not know why.