-
Notifications
You must be signed in to change notification settings - Fork 8
Basic movement firmware Changelog #2
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
base: master
Are you sure you want to change the base?
Basic movement firmware Changelog #2
Conversation
Need to make pose object. Uses encoder instead of IMU right now
Newer basic movement Test state made TODO: Drive straight
not forwards, but thats ok for us
maybe got the PIDMotorTask to work
REACHED_SETPOINT, TIMED_OUT, GOING_TO_SETPOINT instead of just true and false
allows for smoother motion
DrivingChassis.cpp
Outdated
| myright -> startInterpolationDegrees(-mmDistanceFromCurrent * MM_TO_WHEEL_DEGREES, msDuration, LIN); | ||
| } | ||
|
|
||
| DrivingStatus DrivingChassis::driveForward(float mmDistanceFromCurrent, int msDuration){ |
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 should be called once and only once, make a different method to check for completion
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.
the functions driveForward, driveBackwards, turnToHeading are meant to run in the updateStateMachine. I'll give an example. Imagine we have a routine which is to drive forward for 300 mm and then turn right. This routine is called in updateStateMachine.
in that routine we do something like:
// This indicates we're done driving
if(driveForward(300, 5000) == REACHED_SETPOINT){
routineStatus = turning
}
and then inside of turning, we do the same thing for the turnToHeading.
Something we can do is make commandDriveForward, and checkDriveForwardStatus. Basically breaking it up like you suggest. In that case we must add a separate state in the state machine for setting the command to drive forward, and another separate state to turn, instead of checking if we've reached the setpoint in the same state as assigning it. Another solution is just setting a boolean that you've set a setpoint.
This is a lot of text so let me know if this doesn't make sense and I can jump on a call to clarify
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.
i do see how that works, i just disagree on that implementation. the splitting into command and check is much more "state machine like" and would be great
DrivingChassis.cpp
Outdated
| myright -> startInterpolationDegrees(degreesToRotateBase * WHEEL_DEGREES_TO_BODY_DEGREES, msDuration, LIN); | ||
| } | ||
|
|
||
| DrivingStatus DrivingChassis::turnToHeading(float degreesToRotateBase, int msDuration){ |
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.
again, seperate this into 2 functions, one to start the move, another to check on completion
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.
same as above
| int leftCorrection = 0; | ||
| int rightCorrection = 0; | ||
|
|
||
| if(leftSensorValue >= ON_BLACK && rightSensorValue>= ON_BLACK) |
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 is reducing the analog signal to a on-off, BAD. Use the analog vlaue of the sensor reading to proportionally set velocities.
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.
While I agree that this is reducing it to binary (on/off), since this is running quickly over and over again in the state machine, I do not know if making it proportional velocity based on error in analog reading (difference between white and black), would add much value. That being said, I have a growing list of TODOs for the firmware, to which I have added this comment. Right now, this is working well, but I can come back to this and make it a proportional controller later in the semester if time permits.
Here is a video of this working as of right now: https://www.youtube.com/watch?v=P8xwpK9FVaI&feature=youtu.be
EDIT: I have since addressed this comment
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.
i am starting to think that perhaps the line tracking will not be super useful given the precision in the encoders and the small distances involved. Note how the robot arrices at the end point with the orention all skewed. I think using the sinusoidal interpolation and heading correction with the IMU is a more useful stragity for this applicaiton
Going to delete the comments later
1) Found bug in drive forward/backward 2) Started navigation routine 3) pose class
had to rewire line sensor to move it to the front instead of thw back. Pushing cause sloeber is being slow. Navigation in its own file but still buggy
moved line follower onto the other side for tighter navigation
Will split the navigation routine into two parts
re-wrote motion for forward/backwards to drive straight based on IMU.
No description provided.