projects:sand_drawing:work_logs:further_software
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
projects:sand_drawing:work_logs:further_software [2020/05/13 05:01] – tjhowse | projects:sand_drawing:work_logs:further_software [2020/05/13 13:15] (current) – tjhowse | ||
---|---|---|---|
Line 7: | Line 7: | ||
====== What I've done ====== | ====== What I've done ====== | ||
- | === Inverse | + | === Inverse |
This is a fancy term for " | This is a fancy term for " | ||
- | An interesting and non-obvious (to me) fact I discovered during optimisation is that the two angles calculated for the joints are interchangeable if your arms are the same length. You can apply either angle to either joint and the tool position will be the same. I used this to my advantage when assigning the rotations to the stepper motors. The angles were assigned to the steppers based on which arrangement | + | An interesting and non-obvious (to me) fact I discovered during optimisation is that the two angles calculated for the joints are interchangeable if your arms are the same length. You can apply either angle to either joint and the tool position will be the same. I used this to my advantage when assigning the rotations to the stepper motors. The angles were assigned to the steppers based on which assignment |
== Bounds checking === | == Bounds checking === | ||
Line 25: | Line 25: | ||
=== Straight path motion === | === Straight path motion === | ||
+ | The inverse kinematics calculates an angle for each joint in the system. Initially I assigned the target angles to the stepper motors and each one rotated towards its target at the same rate. This would sometimes lead to weird paths if the rotation required to reach the targets was very different for each stepper. One stepper would reach its target rotation long before the other and there would be a bend in the path. | ||
+ | In order to smooth out the path I first tried scaling the speeds of the steppers based on the proportional distance it had to travel. This way a stepper with a required rotation of 30 degrees would travel at half the speed of the second stepper with a required rotation of 60 degrees. This means the two steppers would finish their moves at approximately the same time. | ||
+ | |||
+ | This approach still resulted in curved paths, since the rate of the movement needs to vary based on the kinematics of the system. This solution was accurate on average, but not actually accurate at any point but the start and end. The tool would actually move in an arc. This is bad in general terms, since it's reasonable to assume a robot moves directly between the coordinates specified in the GCODE, but it can also cause problems if that arc collides with the edge of the enclosure. | ||
+ | |||
+ | I needed to solve this. My initial thought was to break the path up into a number of intermediate points and move between them on the way to the end target point. I wasn't happy with this approach - I felt as though I should solve it " | ||
+ | |||
+ | At the start of each move of a magnitude greater than < | ||
+ | |||
+ | I initially tested with a < | ||
====== What I want to accomplish next time ====== | ====== What I want to accomplish next time ====== | ||
* Build the electronics. | * Build the electronics. |
projects/sand_drawing/work_logs/further_software.1589346067.txt.gz · Last modified: 2020/05/13 05:01 by tjhowse