| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
extent. Tested initialization on functioning system - it works!
|
| |
|
|
| |
Update linear encoder to reduce noisy behavior and properly keep track of position. NOTE: Linear encoder direction seems to be backwards relative to the system (the motor currently also moves in this direction). Not a big deal as long as the motor and linear encoder work together properly, but ideally positive would be to the right.
|
| |
|
|
| |
working properly. Other minor issues from merge conflict.
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
the linear-zero position.
Add an initialize function for startup: use the limit switches to find the track extent and then go to zero.
With the above two additions, we should be able to assume that new tests will always start at the zero position.
Also add an initialize file which just calls sys.initialize to find the zero position. This should only be run on power-up (eventually, we should configure the Pi to run this on OS startup).
|
| | |
| |
| |
| |
| | |
Add ability to add SW limits (challenge mode).
Add result file reporting (currently using date-time for the test, which we can assume will be unique per test).
|
| |/
|
|
| |
to test on physical system.
|
| |
|
|
| |
library and successfully got the encoder position controlling the motor speed.
|
| |
|
|
| |
which will be based on the specs of the system. This is the basic implementation we've talked about, but there might be some issues still because the position is only read when we tell it, so keeping track of number of rotations might not be very accurate - will need to test and possibly brainstorm alternate ideas.
|
|
|
implementation details (linear encoder, motor orientation, etc.). Need to compile and test on RPi still.
Convert naming in other libraries to follow Python naming scheme.
|
