dotPlan

dotPlan

The robot arm is 5 axes of fun, though it does not have sensors, so any project would only be a bit of fun to implement some fancy movements automatically.

movement

motors

The motor terminology is

• M1 grabber open/close
• M2 wrist pitch
• M3 elbow pitch
• M4 shoulder pitch
• M5 base direction

motion types

M2 - M4 have identical gearing and similar distances to the fulcrums so synchronised motions (which are possible) can lead to quite effective linear travel up/down with just full on. Hence, some canned moves could be easily put together on top of the primitives of off / forwards / backwards.

lowest level motion types

• gripper open/close
• wrist pitch up/down
• elbow pitch up/down
• shoulder pitch up/down
• base clockwise / anticlockwise

physical high level motion types

• fairly steady up/down gripper motion - M2 + M3 moving in opposite directions
• fairly steady backwards/forwards gripper motion - M3 + M4 moving in opposite directions
• gripper pitch up/down motion - M2 + M4 moving in opposite directions
• and much, much more

speed control - sending small pulses

This seems to work, although it may make a terrible noise. The more useful application might be to provide differential drive to different axes when complex multi-axis moves are made - or alternatively to seek to a new position with all motors completing at the same time.

reset - for emergencies see

sudo ./stoparm.py

position dependent motion (would need speed control?) for smoother motion?

the high-level moves should be specified in terms of total angle traversed over time

This would allow the total drive pulses sent to be sent proportionally to the elapsed time to match the rate of angular change.

• the guaranteed angular outcome is the angular traversal
• in order to support anything other than a limited number of full speed moves, quanta of moves will have to be used to allow pulses to be emitted to bring the trajectory on track
• if we're running this from python then it must certainly be assumed that the time slices will not be precise. ** the calculation should record the wall time from the start of the last move ** the calculation then works out the delta from the extrapolated path to see if a new pulse is needed
• Also, to avoid "kinks" the quantum should be small enough to be a fraction of a degree . ** 12 degrees /s > 10 ms == .1 degrees.

Usage improvements

• Currently armdemo.py has to be run under sudo, which I'd like to understand how to avoid
• Windows support?