User Tools

Site Tools


projects:sand_drawing:work_logs:further_software

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
projects:sand_drawing:work_logs:further_software [2020/05/13 05:08] tjhowseprojects:sand_drawing:work_logs:further_software [2020/05/13 13:15] (current) tjhowse
Line 30: Line 30:
  
 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. 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 "properly" and do the maths to work out the velocity profiles for the two steppers to result in a straight line. I gave up on solving this problem with my own brain and decided to look it up. It turns out this is a [[https://www.pmdcorp.com/resources/type/articles/resources/get/motion-kinematics-article|Hard Problem]] in non-cartesian robotics, and many solutions do exactly as I had imagined. With the reassurance that other engineers had been as lazy as me I proceeded with the dodgy numerical approach.
 +
 +At the start of each move of a magnitude greater than <nowiki>PATH_SPLIT_SIZE</nowiki> I calculate a vector that moves towards the end target by at most <nowiki>PATH_SPLIT_SIZE</nowiki> units. This vector is used to offset the current position to a new intermediate target. This repeats until the tool is less than <nowiki>PATH_SPLIT_SIZE</nowiki> units from the target and the robot then does a move to the final target.
 +
 +I initially tested with a <nowiki>PATH_SPLIT_SIZE</nowiki> of 5mm. This resulted in fairly noticeable judder in the movement, so I dropped it to 1mm and the movement is much smoother.
  
 ====== 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.1589346518.txt.gz · Last modified: 2020/05/13 05:08 by tjhowse