Skip to content

Conversation

@madhephaestus
Copy link
Contributor

No description provided.

gentov added 10 commits October 5, 2020 12:32
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
myright -> startInterpolationDegrees(-mmDistanceFromCurrent * MM_TO_WHEEL_DEGREES, msDuration, LIN);
}

DrivingStatus DrivingChassis::driveForward(float mmDistanceFromCurrent, int msDuration){
Copy link
Contributor Author

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

Copy link

@gentov gentov Oct 21, 2020

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

Copy link
Contributor Author

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

myright -> startInterpolationDegrees(degreesToRotateBase * WHEEL_DEGREES_TO_BODY_DEGREES, msDuration, LIN);
}

DrivingStatus DrivingChassis::turnToHeading(float degreesToRotateBase, int msDuration){
Copy link
Contributor Author

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

Copy link

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)
Copy link
Contributor Author

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.

Copy link

@gentov gentov Oct 21, 2020

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

Copy link
Contributor Author

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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants