Trajectory planning compatible with close loop SERVO

[mjtooba]

Hi i like to use this project with close loop DC motor with encoder feedback , i looked at source & found pulse generation codes is embedded with trajectory generation codes and not found any place that provide desired position in fixed interval. to support servo motors we need desired position in fixed interval (1ms typically). so if this feature is not available in code , i ask it as future development or if it is available , glad to provide a help

[justinclift]

This sounds like it would be useful. :smile:

[giseburt]

In brief, g2core takes gcode and makes motion this way:

1. parse gcode into moves and commands, executing some commands and placing the rest of the moves (“blocks”) and commands into the planner queue (some values that don’t involve other blocks are computed here)

2. pre-plan backward from the last added queue item toward the first, primarily determining the highest speeds that can be achieved while being able to stop when out of blocks (cornering values are also determined here)

3. before the next queued block is executed it is fully planned, determining the length of the three sections: the acceleration section (head), cruise section (body), and deceleration section (tail), some of which might not be used in this block. This information is computed relative to the current running speed and target position to determine what is actually achievable

4. each section is broken into same-time-length segments (the total time of the section divided by the ideal segment time, then rounded up) with the start velocity, end velocity, and target position (converted to steps by the kinematics) computed to match the velocity curve for that portion of that section

5. each segment is executed by the runtime, which has a constantly running constant-speed clock (200khz on some of our boards) that deals out the steps to the motors

For a dc Servo step 4 would be altered slightly (possibly in the kinematics) to compute the position differently, and step 5 would likely be wholly replaced with communications to the servos.

Does this help? On Sat, Jun 9, 2018 at 3:44 AM Justin Clift notifications@github.com wrote:

This sounds like it would be useful. 😄

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/synthetos/g2/issues/361#issuecomment-395951995, or mute the thread https://github.com/notifications/unsubscribe-auth/AAXj0SqyEId3j9gQffFjDwtsJ3HJtnhUks5t64rtgaJpZM4UhNNn .

[SchiMa2017]

We are using G2core to control a 4-axis mill over CAN-Bus for more than one year now and it works so far, but has some limitations. We added a 1ms interrupt to main.cpp. We are sending new CAN positions each ms and are using en.en[i].encoder_steps+en.en[i].steps_run as position information. It is working stable as long as your servos are able to follow the trajectory. We invoke a feedhold if we are loosing position and implemented some code to recover back from that state to continiue movement, but that is still quite buggy. We are storing the absolute positions on the servo controllers, so when we start the maschine we already know the position without homing.

[justinclift]

@SchiMa2017 Cool! Is the your version of the g2core code the same as that in #300 (eg you work with @mawildoer), or is it a different implementation? :smile:

[giseburt]

@SchiMa2017 that is fascinating. Can you share more about the project (perhaps on the mailing list, since it’s somewhat off-topic here)?

There is another approach to handling the servos, which is what we did in step_dir_hobbyservo.h: pretend to be a stepper motor, take the step and direction commands, and translate them to the command for the other type of motor.

In our case we’re taking a $10 hobby Servo that takes a PWM signal and controlling it with planned jerk-limited movements. It works rather well when tuned properly to account for the limits of the motor.

In your case you would have the motors occasionally send their intended position over the can bus. This will cause a small delay (which you already have, I believe) where the motor is being told to go to where the g2core system thinks it already is.

I feel a better approach would be to patch into the loader prep to send the commands to the CAN bus subsystem, which should probably use DMA to background the commas and not disrupt the system.

Better yet, if you can set a position in one packet and send an executed flag in another, then send only the position as I just mentioned and then at load you could trigger the DMA to send the execute flag. That would give you timing as close as within step of the plan (depending on latency of the can bus). However you need the DMA or to delay the send until later in the main loop since the load has very restricted timing.

[SchiMa2017]

It's a different implementation. We can make a new branch for it, but we should generalize some functions before we do that. There is a state machine that checks how many axis are connected, then makes sure, that the initial positions are the same for servos and g2core and so on... But that state maschine is rather specific for the communication with the code running on the servos. Would be a good step to make a more general approach at the point. We have no problems in sharing the code as it is at the moment as well.

[SchiMa2017]

To get a very tight synchronization of the position data between g2core and the different servos is not easy. One the other hand the new positions for the servos are send each millisecond. The delay between servo A receiving the new position data and servo B receiving the new position data is low, compared to the overall machine precision. @giseburt I'm not so deep in the g2core code, but I will try to look at the approaches that your are suggesting. We are using the standard CAN Ports of the arduino due. We are using pcbs for the servos that we also developped ourself. We can attach it directly to BLDC motors with a power of around 200 - 500W, costing around 48$ from China. The position sensor is on the pcb itself, it is not super precise in terms of standard servos, but its implementation in the system is super simple. We use sensors like the AS5147P.

[justinclift]

Sounds pretty awesome @SchiMa2017. :smile:

[justinclift]

@SchiMa2017 Nearly two years later... is the CAN approach still in use (and working ok, etc)?

[SchiMa2017]

Yes, we use it on three machines and it is working well. But we are still not fully using the feedback from the servos in g2core. Ideally the multi axis controller would not only send out positions (like all the Step/Dir type controllers are doing) but would also look at the actually positions and could then for example slow down other axis, if one axis is hitting speed limit during G0. We made a total redesign within the last two weeks which is now using the teensy 4.0 to controll the servo motors. Teensy 4.0 has also CAN FD which will allow sending all positions of all axis in one single broadcast. Teensy has also two more CAN ports so that the feedback could be transfered in 1ms intervals are lower. But to really profit from that, a modified or new multi axis controller is needed. We also had a look at GRBLHAL. In a new design all step/dir processing core parts would be exchanged and replaced by a core which is sending out the positions and is receiving the feedbacks and slows down everything if the positions error get to large. It could be handled with a step/dir controller as well if the feedrates can be dynamically ajusted. G2core is maybe not the best choice for that, as we never get that working properly. But could also be the case that we just did it wrong.

[justinclift]

Interesting. Is the Teensy 4.0 approach using g2core for the software component?

[justinclift]

@giseburt This sounds like it'd be interesting to you too. :smile:

Oh, and maybe @mawildoer too, as they have a CAN implementation as well. Might be useful shared "lessons learned" type of thing there. :smile: