awesomebytes/dmp_gestures

Gesture learning and execution via DMPs

dmp_gestures's Issues

rosbag.write writes at 35Hz

While rosbag record writes at 50Hz the /joint_states topic.

Maybe there is too much checking code in my loop here:
https://github.com/awesomebytes/dmp_gestures/blob/master/dmp_gestures/src/dmp_gestures/dmp_training.py#L151

It still works fairly well but I don't like this behaviour.

plotting velocities not done

Plotting the velocities of recorded and generated trajectories is not done.

Should extend the class:
https://github.com/awesomebytes/dmp_gestures/blob/master/dmp_gestures/src/dmp_gestures/dmp_generation.py#L307

Too long trajectories take too long to check for validity

A gesture like crowd_salute generates trajectories of 600 points with 12s of duration which needs 3s~ to be checked.

Proposed solution:
Slice the trajectories in parts that can be computed while executing and send the parts.

Implementation failed because the execution service that manages what trajectories send to what controllers stops the current trajectories when sending a new one and they can't be queued up. Waiting for the last one to finish to send the next one does not work because of the delay of making the call (and probably the low level controllers make the joints stop anyways, but I don't know this for sure).

Filter jerkiness on generated trajectories

There is jerkiness present in the trajectories when plotting them. When executing them on the simulated robot they don't seem to be present but maybe filtering them would be a good idea.

FIR Filter as in this example could be used:

https://mbed.org/cookbook/FIR-Filter

Recorded gestures from play motion take long to train and execute new plans

This has been found out to be because by default many motions include all the joints (even a wave that only moves right arm) which increases the number of joints to compute everything from 7 to 18.