-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add diagonal movement #4
base: main
Are you sure you want to change the base?
Conversation
lib/src/rover/orchestrator.dart
Outdated
@@ -61,13 +63,13 @@ class RoverOrchestrator extends OrchestratorInterface with ValueReporter { | |||
collection.logger.debug(step.toString()); | |||
} | |||
currentState = AutonomyState.DRIVING; | |||
var count = 0; | |||
// var count = 0; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was good because it catches small drifts in the GPS and IMU, allowing us to be more lenient about errors in everything. Maybe let's keep it and try removing it later when we do more physical tests
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe instead of replanning after a set amount of steps, have it check after each step is completed if it has drifted too far and replan?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Planning is very cheap -- not noticeable during operation. If there is no drift, the new plan == the old plan. So this is pretty much just as efficient as that, without the extra logic
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doesn't replanning stop the rover suddenly? I'd rather not replan if it will cause a visible hiccup
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not if we move faceNorth
outside the while loop, Then there is no stop command and the re-planning will happen while the rover is still executing/finishing the last command. Technically there is a very slight delay but we're still unsure exactly what accuracy we will end up having. Keep in mind that we still don't have RTK so our GPS will have significant error.
Co-authored-by: Binghamton Rover <[email protected]> Co-authored-by: Levi Lesches <[email protected]>
GpsCoordinates goForward(CardinalDirection orientation) => this + switch(orientation) { | ||
CardinalDirection.north => GpsUtils.north, | ||
CardinalDirection.south => GpsUtils.south, | ||
CardinalDirection.west => GpsUtils.west, | ||
CardinalDirection.east => GpsUtils.east, | ||
CardinalDirection.northEast => GpsUtils.northEast, | ||
CardinalDirection.northWest => GpsUtils.northWest, | ||
CardinalDirection.southEast => GpsUtils.southEast, | ||
CardinalDirection.southWest => GpsUtils.southWest, | ||
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can make this a field on CardinalDirection
, so that this becomes:
GpsCoordinates goForward(CardinalDirection direction) => this + direction.gpsOffset;
|
||
extension OrientationUtils on Orientation { | ||
static const double epsilon = 3.5; | ||
static const double orientationEpsilon = 10; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
static const double orientationEpsilon = 10; |
Seems to be unused
No description provided.