search

nepfaff / tenaci

Software for a robotic manipulator that can rotate and stack cubes, draw sketches, and prepare a miniature breakfast.
0 stars 0 forks source link

Speed improvements #17

Closed nepfaff closed 2 years ago

nepfaff commented 2 years ago

Our robot is quite smooth but very slow. We should try to increase speed by tuning the velocity and acceleration values of the time-based mode.

It might be desirable to have different velocity and acceleration values at different stages. For example, moving between cubes should be fast but placing down should be slower for maximal accuracy. A simple solution to this would be to have different named groups of acceleration and velocity values (all tested to work well). A stage could then have one of these names associated. This could be achieved by annotating waypoints with these names, where a name represents how to move from the previous to this waypoint. When waypoints are grouped to previous (spline sequence), we would just read the name of the last waypoint in that sequence.

nepfaff commented 2 years ago

Maybe it is sufficient/better to control this by changing the time for a trajectory while keeping one global velocity, acceleration setting?

nepfaff commented 2 years ago

Maybe it is sufficient/better to control this by changing the time for a trajectory while keeping one global velocity, acceleration setting?

This is now implemented (see here)

nepfaff commented 2 years ago

May need additional, less manual speed improvements. Decide this based on the videos from the next lab

nepfaff commented 2 years ago

This shows the effect of tuning our velocity and acceleration values: image

Our time-based mode lets us set the time of the trajectory. We did not use this properly so far. However, we could connect this with out timeForTrajectory values.

Velocity and acceleration units are milliseconds. image

nepfaff commented 2 years ago

Control using the time-based mode and setting t3 to sampling period works in practice. However, we want to send the next command after half the sampling period to avoid deacceleration. Hence, the profile will be more and more behind, prompting the velocity and acceleration to increase more and more. This would only be noticeable for long spline trajectories. Hence, this is probably not a problem. Mitigating this would be lots of work as it would require sending a bigger command then we want and sending the next command when the profile reached the command that we actually wanted.

nepfaff commented 2 years ago

Great success on this so far. Keep tuning this a little after attempting to change the sampling period from 0.1s to 0.05s. See #19

nepfaff commented 2 years ago

works well. A bit of tuning for some trajectories might lead to more smoothness without big speed sacrifices