# NEW : Advanced Profile Generator for Pick & Place

**URL:** <http://discourse.heig-vd.ch/t/new-advanced-profile-generator-for-pick-place/370>\
**Category:** OpenCN Framework\
**Created:** [December 23, 2022, 9:10am UTC](http://discourse.heig-vd.ch/t/new-advanced-profile-generator-for-pick-place/370 "2022-12-23T09:10:08Z")\
**Posts on this page:** 14\
**Page:** 1

<div class="post-metadata">

**Author:** ![Raoul](http://discourse.heig-vd.ch/user_avatar/discourse.heig-vd.ch/raoul/32/21_2.png) [@Raoul](http://discourse.heig-vd.ch/u/Raoul)\
**Post date:** [December 23, 2022, 9:10am UTC](http://discourse.heig-vd.ch/t/new-advanced-profile-generator-for-pick-place/370/1 "2022-12-23T09:10:08Z")

</div>

I’m happy to announce that our “Advanced Profile Generator” for Pick & Place is available.  
It is a new OpenCN component for fast tracking of moving objects under kinematic constraints.  
We also built a HW demonstrator in order to validate the algorithm.

Please check out our video:  
[https://www.youtube.com/watch?v=jZ1T2v-ZfzU&t=6s](https://www.youtube.com/watch?v=jZ1T2v-ZfzU&t=6s)

The Advanced Profile Generator will soon be merged to the Master branch.

best regards,  
Raoul

---

<div class="post-metadata">

**Author:** ![yakunix](http://discourse.heig-vd.ch/letter_avatar_proxy/v4/letter/y/bb73d2/32.png) [@yakunix](http://discourse.heig-vd.ch/u/yakunix)\
**Post date:** [February 2, 2023, 8:03am UTC](http://discourse.heig-vd.ch/t/new-advanced-profile-generator-for-pick-place/370/2 "2023-02-02T08:03:41Z")

</div>

Hi @Raoul ,

Does this profile generator functions as a 1-D trajectory planner? If so, how could we use it in robot pick and place application? For example, if the robot current position is (x0, y0, z0), the object position is (x1 + v\*t, y1, z1), how could we synchronize each axis (same time duration of each axis)?

In the document, it assumes a constant speed of the object. Could this profile generator be used to track a varying speed target? For example, if the conveyor speed has some fluctuation, could we track it precisely?

---

<div class="post-metadata">

**Author:** ![Raoul](http://discourse.heig-vd.ch/user_avatar/discourse.heig-vd.ch/raoul/32/21_2.png) [@Raoul](http://discourse.heig-vd.ch/u/Raoul)\
**Post date:** [February 2, 2023, 8:22am UTC](http://discourse.heig-vd.ch/t/new-advanced-profile-generator-for-pick-place/370/3 "2023-02-02T08:22:13Z")

</div>

Hi Yakunix,

at the moment being, the profile generator is a 1-D trajectory planner.

For 2-D or 3-D the profile generator could be applied as a first step individually to each axis in order to determine which axis takes the most time.  
In order to synchronize simultaneously, the other axes have a little bit of “freedom” since they are not time critical.

---

<div class="post-metadata">

**Author:** ![yakunix](http://discourse.heig-vd.ch/letter_avatar_proxy/v4/letter/y/bb73d2/32.png) [@yakunix](http://discourse.heig-vd.ch/u/yakunix)\
**Post date:** [February 2, 2023, 8:52am UTC](http://discourse.heig-vd.ch/t/new-advanced-profile-generator-for-pick-place/370/4 "2023-02-02T08:52:43Z")

</div>

I see. In this case, we will plan trajectory for each axis. So we might not be able to limit the velocity norm of the robot but the velocity magnitude of each axis?

---

<div class="post-metadata">

**Author:** ![Raoul](http://discourse.heig-vd.ch/user_avatar/discourse.heig-vd.ch/raoul/32/21_2.png) [@Raoul](http://discourse.heig-vd.ch/u/Raoul)\
**Post date:** [February 2, 2023, 9:31am UTC](http://discourse.heig-vd.ch/t/new-advanced-profile-generator-for-pick-place/370/5 "2023-02-02T09:31:02Z")

</div>

Exactly.  
The norm of velocity would induce a “coupling” between axes which would complicate things.

---

<div class="post-metadata">

**Author:** ![yakunix](http://discourse.heig-vd.ch/letter_avatar_proxy/v4/letter/y/bb73d2/32.png) [@yakunix](http://discourse.heig-vd.ch/u/yakunix)\
**Post date:** [February 3, 2023, 8:13am UTC](http://discourse.heig-vd.ch/t/new-advanced-profile-generator-for-pick-place/370/6 "2023-02-03T08:13:17Z")

</div>

Thanks Raoul,  
But If axis1 takes time _t1_, axis2 (to be synchronized) takes time _t2_ and _t1_ \< _t2_, how could we expand t1 to t2 then (assume the initial robot speed is non-zero)?

---

<div class="post-metadata">

**Author:** ![Raoul](http://discourse.heig-vd.ch/user_avatar/discourse.heig-vd.ch/raoul/32/21_2.png) [@Raoul](http://discourse.heig-vd.ch/u/Raoul)\
**Post date:** [February 3, 2023, 8:42am UTC](http://discourse.heig-vd.ch/t/new-advanced-profile-generator-for-pick-place/370/7 "2023-02-03T08:42:21Z")

</div>

In this case, the solution for axis1 is feasible without violation of any constraint (vmax, amax, jmax), and there are infinitely many solutions where the end time of axis1 is t2.  
I did not cogitate a lot about this.  
There is one paper which comes me in mind : discretize the time axis, and as unknowns put a piecewise constant jerk. Boundary conditions are linear. This should be cast as a linear program (LP). One might put as objective function minimizing the infinity norm of the jerk.  
But maybe there are other more elegant or simpler solutions.

---

<div class="post-metadata">

**Author:** ![Raoul](http://discourse.heig-vd.ch/user_avatar/discourse.heig-vd.ch/raoul/32/21_2.png) [@Raoul](http://discourse.heig-vd.ch/u/Raoul)\
**Post date:** [February 3, 2023, 8:59am UTC](http://discourse.heig-vd.ch/t/new-advanced-profile-generator-for-pick-place/370/8 "2023-02-03T08:59:26Z")

</div>

Here is the paper I talked about :

[Dynamically Compensed Motion.pdf](http://discourse.heig-vd.ch/uploads/short-url/ayqMuMn87fNm6xaZiMLpFijZx1y.pdf) (503.3 KB)

---

<div class="post-metadata">

**Author:** ![yakunix](http://discourse.heig-vd.ch/letter_avatar_proxy/v4/letter/y/bb73d2/32.png) [@yakunix](http://discourse.heig-vd.ch/u/yakunix)\
**Post date:** [February 3, 2023, 9:21am UTC](http://discourse.heig-vd.ch/t/new-advanced-profile-generator-for-pick-place/370/9 "2023-02-03T09:21:48Z")

</div>

Cool. Thanks for providing the material.

I think this library ([Ruckig](https://github.com/pantor/ruckig)) does the same thing as the profile generator. And it supports non-constant speed of the target. Multi-dof synchronization is also supported.

---

<div class="post-metadata">

**Author:** ![Raoul](http://discourse.heig-vd.ch/user_avatar/discourse.heig-vd.ch/raoul/32/21_2.png) [@Raoul](http://discourse.heig-vd.ch/u/Raoul)\
**Post date:** [February 3, 2023, 9:32am UTC](http://discourse.heig-vd.ch/t/new-advanced-profile-generator-for-pick-place/370/10 "2023-02-03T09:32:37Z")

</div>

Yes, I was in contact with the developers of “Ruckig”.  
They have a slightly different formulation where the acceleration at synchronization needs not to be zero.

They founded a company, and sell a “pro” version of their SW code.

---

<div class="post-metadata">

**Author:** ![yakunix](http://discourse.heig-vd.ch/letter_avatar_proxy/v4/letter/y/bb73d2/32.png) [@yakunix](http://discourse.heig-vd.ch/u/yakunix)\
**Post date:** [February 3, 2023, 12:21pm UTC](http://discourse.heig-vd.ch/t/new-advanced-profile-generator-for-pick-place/370/11 "2023-02-03T12:21:06Z")

</div>

Cool! For Pick & Place application, the constant speed (zero acc) assumption may be good enough. Some conveyor system do not have a servor to control the motor running at constant speed and the speed oscillates due to friction, so it might be necessary to also follow the varying speed. But normally the conveyor acceleration is hard to be obtained because of the existence of the sensor noise. Do you have any idea of dealing with this case?

---

<div class="post-metadata">

**Author:** ![Raoul](http://discourse.heig-vd.ch/user_avatar/discourse.heig-vd.ch/raoul/32/21_2.png) [@Raoul](http://discourse.heig-vd.ch/u/Raoul)\
**Post date:** [February 3, 2023, 4:36pm UTC](http://discourse.heig-vd.ch/t/new-advanced-profile-generator-for-pick-place/370/12 "2023-02-03T16:36:55Z")

</div>

It depends what sensor informations are available :  
-) only setpoint value of the conveyor speed  
-) incremental encoder for the conveyor position  
-) vision system for the target objects on the conveyor

If sensor data are poor and too noisy individually, maybe that a Kalman filter could be used to combine different informations ?

Are you sure that this is really a problem in practice ?

---

<div class="post-metadata">

**Author:** ![yakunix](http://discourse.heig-vd.ch/letter_avatar_proxy/v4/letter/y/bb73d2/32.png) [@yakunix](http://discourse.heig-vd.ch/u/yakunix)\
**Post date:** [February 4, 2023, 4:20am UTC](http://discourse.heig-vd.ch/t/new-advanced-profile-generator-for-pick-place/370/13 "2023-02-04T04:20:03Z")

</div>

I have encountered a situation where the conveyor system uses a frequency converter instead of a servo motor, and the position information is obtained by an encoder. Due to the changing friction force of the system during operation, the conveyor position will have a significant drift compared to a constant speed after a certain period of time. After differentiating the encoder position, the velocity fluctuation is found to be relatively large and acceleration may become more oscillatory.

---

<div class="post-metadata">

**Author:** ![Raoul](http://discourse.heig-vd.ch/user_avatar/discourse.heig-vd.ch/raoul/32/21_2.png) [@Raoul](http://discourse.heig-vd.ch/u/Raoul)\
**Post date:** [February 4, 2023, 11:20am UTC](http://discourse.heig-vd.ch/t/new-advanced-profile-generator-for-pick-place/370/14 "2023-02-04T11:20:21Z")

</div>

I see your point.

Indeed, in this case, important fluctuations of conveyor speed and high precision requirements for the pick & place operations, a profile generator able to cope with this situation is clearly better.

However, the complexity of computations will also increase in the profile generator.