Basic movement firmware Changelog#2
Basic movement firmware Changelog#2madhephaestus wants to merge 19 commits intoWPIRoboticsEngineering:masterfrom
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.
this should be called once and only once, make a different method to check for completion
There was a problem hiding this comment.
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.
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.
again, seperate this into 2 functions, one to start the move, another to check on completion
| int leftCorrection = 0; | ||
| int rightCorrection = 0; | ||
|
|
||
| if(leftSensorValue >= ON_BLACK && rightSensorValue>= ON_BLACK) |
There was a problem hiding this comment.
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.
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.
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.
2 participants
No description provided.