| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\ |
|
| | |
| |
| |
| | |
shakiness on deinitialization (need to coordinate GPIO.cleanup with threads), but program does exit and return home normally. Swingup test now runs very smooth and SW limits were increased with the drastically improved response time. Pushing to merge back to master.
|
| | |
| |
| |
| | |
as expected. Run this to check before actually running the system.
|
| |/
|
|
|
|
|
| |
accuracy and SW interrupt accuracy. Coupled with changes from the interrupt enhancement branch, the limit behavior should be much improved.
Added a parameter to allow user to set their own SW limit-reached routine (default behavior is still the same). This should also help prevent over-excursion in the swingup test.
Slightly modified swingup test to use new SW limit-reached routine. This should help prevent the system from over-excursing when the soft limits of the program are reached. Theoretically the program shouldn't be able to hit the HW limits anymore.
|
| |\ |
|
| | |
| |
| |
| | |
expected. Commiting to merge to master - will need more testing before we know if it's a perfect solution.
|
| |/
|
|
|
|
| |
has been fired. This should help with the occasional issue where the ISR thread is interrupted and moves back to the primary thread where movements continue.
May need to add another line in adjust() that if interrupted==True then coast the motor (not sure what the ramifications of this would be though: if in the process of going home and thread switches back, it might not get all the way home...)
|
| |
|
|
| |
keeps coming loose if the speed is changed too quickly, rod will hit base if swinging too near extents (need to cut wood on both sides to allow free swinging.
|
| | |
|
| |\
| |
| |
| | |
https://github.umn.edu/damic014/ee4950-inverted-pendulum
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
requirements of web server.
|
| |/
|
|
| |
controller working. Not sure if the code is good enough to make it happen...
|
| | |
|
| |
|
|
| |
be set to upright instead of hanging). Updated system to allow for different angular units to be used (passed by argument on constructor, then passed to encoder.read_position when used). Bug fixes to system_swingup_test. Swingup test now runs properly (and almost actually did a swing up at one point), couldn't keep testing because the system accidentally destroyed itself, so called it time to stop to let glue dry....
|
| |
|
|
| |
potentially runs now.
|
| |\
| |
| |
| |
| |
| | |
https://github.umn.edu/damic014/ee4950-inverted-pendulum
Merge changes from Raspberry Pi testing with control code provided by Andy (created/modified on another computer).
|
| | |
| |
| |
| |
| |
| | |
(system_swingup_test.py), which modifies the code from homework8.ipynb and swingUp.py to (potentially) run on our physical system instead of the simulator. Needs to be compiled and tested on the RPi, but theoretically all of the major components should be there.
NOTE: Potentially should remove the gym imports; not sure if these will work on the RPi, might need to be replaced with something else.
|
| | |
| |
| |
| | |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
