cmorley wrote: I was thinking that using s curve in our jogging planner would probably be a good project too.
rapid acceleration is really the name of the game when jogging slowly.
It would surely be easier to to do then the full motion controller.
Chris M
The complete lack of data encapsulation in the source makes this much more difficult than it should be. The simple_tp_t struct is public and is allocated globally(!) as part of emcmot_joint_t and emcmot_axis_t (in motion.h), and code is touching the internal fields everywhere - e.g. handle_jjogwheels() in control.c sets free_tp.max_acc! I think this needs a major overhaul/cleanup before a sane implementation of a more advanced simple_tp can be made.
Is this something that the active developers would approve, or are people fond of their global state?
Another thing that complicates things compared to the full motion planner is that the simple_tp must be able to re-plan motion on the fly: it often receives a new pos_cmd while moving. The planner needs to be able to handle non-zero acceleration and velocity initial state, as well as changing velocity limits while moving. So while a jerk-limited jogging planner might be easier than a full planner, it's still no small task. But yeah, the data encapsulation issue is the real hurdle, I think.
The way to do data encapsulation would be to do a forward declaration of simple_tp_t in simple_tp.h:
Code:
typedef struct simple_tp_t simple_tp_t;
Then change emcmot_joint_t and emcmot_axis_t to contain a pointer to simple_tp_t rather than the actual struct, and initialize the fields by calling a constructor function ("simple_tp_create()" or similar), probably in init_comm_buffers() in motion.c.
If people are very much against memory allocation like this, the required number of structs could be statically pre-allocated by the simple_tp implementation, and a pointer to the pre-allocated fields could be returned by simple_tp_create() (let's call it simple_tp_fetch() instead):
Code:
joint->free_tp = simple_tp_fetch(joint_num);
Then to clean up all the places that directly modifies the internal fields of the planner...
One thing that worries me is this: STRUCTS_IN_SHMEM. It seems these structs are allocated differently depending on this define. If someone could explain the mechanism & reason behind this, I would be grateful.
