Also take a look at some running commentary from when the trajectory 
planner was disentangled here 
<https://github.com/machinekit/machinekit/issues/476>

On Wednesday, May 10, 2017 at 4:29:25 AM UTC, Brian Schousek wrote:
>
> [1] could certainly use some updating. My key high level insight from 
> today is that the block diagram for the trajectory planner is now *outside* 
> the emcmot loop per this blog entry 
> <http://blog.machinekit.io/2015/02/loadable-trajectory-modules.html>. 
> Many of the internals of the trajectory planner are exposed as HAL pins and 
> I was making things much more complicated than they had to be. I remain 
> convinced that Python could be fast enough to meet the timing requirements, 
> but currently the easier path is to create a realtime component using C. 
> This is *greatly* simplified by using the component generator documented 
> here <http://www.machinekit.io/docs/hal/comp/> and here 
> <http://www.machinekit.io/docs/hal/instcomp_writing_a_component/> and 
> elsewhere. It takes care of 99% of the boilerplate and makes it easy to 
> link C functions to HAL pins. Then the exposed trajectory planner pins can 
> be connected via HAL commands to my C function. 
>
> Note to my future self: look at the documentation for instcomp and 
> wordsmith it to not rely on back-references to the comp documentation.
>
>
>
> [1]: 
> http://www.machinekit.io/docs/code/Code_Notes/#motion-controller-introduction 
> <http://www.google.com/url?q=http%3A%2F%2Fwww.machinekit.io%2Fdocs%2Fcode%2FCode_Notes%2F%23motion-controller-introduction&sa=D&sntz=1&usg=AFQjCNGY6UYFKnqvT5uTn_hlW61_-K_c1g>
>
>
> On Tuesday, May 9, 2017 at 6:14:35 PM UTC-5, Hedge Hog wrote:
>>
>>
>>
>> On Tuesday, May 9, 2017 at 12:30:09 PM UTC+10, Brian Schousek wrote:
>>>
>>> I'm having good luck achieving microsecond resolution pulse trains using 
>>> DMA on a Raspberry Pi at near real-time rates, and I'm confident that with 
>>> some optimization this will be workable for step generation with low cpu 
>>> usage. I currently have this step generation hacked into a Machinekit 
>>> configuration which monitors the trajectory planner position pins. When a 
>>> loop in Python detects a change in axis.0.motor-pos-cmd, for example, it 
>>> queries axis.0.joint-vel-cmd and creates a stream of n steps at the proper 
>>> frequency where n is the number of steps that will fit into my millisecond 
>>> servo loop. 
>>>
>>> The DMA library I am using is capable of synchronizing sequential 
>>> waveforms, so I would like to be able to look ahead in the trajectory 
>>> planner queue a step or two and construct the waveforms in advance where 
>>> possible, which should help solve some latency issues. I have a few 
>>> questions towards achieving this:
>>>
>>> 1) Is there a better mechanism to detect a new trajectory step than 
>>> monitoring changes in the position-commanded HAL pin?
>>> 2) Is there visibility into the trajectory planning queue somewhere?
>>> 3) Perhaps these are not exposed in the current Python bindings; if not, 
>>> is there a good example of accessing it via C calls?
>>> 4) Are there any other tips on source code areas I should investigate as 
>>> resources in putting this together?
>>>
>>> Brian
>>>
>>
>> I have similar questions, although I behind you on the implementation 
>> curve.  Is there any chance you could add you notes/learnings to the MK 
>> documentation:
>> here at [1] is one place you might place any high level insight that you 
>> feel might help.
>> here at [2] is probably where you can add the most value :)
>>
>> If time or other constraints prevent you adding to the docs could you 
>> post your notes here?
>>
>> [1]: 
>> http://www.machinekit.io/docs/code/Code_Notes/#motion-controller-introduction
>> [2]: 
>> http://www.machinekit.io/docs/code/Code_Notes/#backlash-and-screw-error-compensation
>>
>> Best wishes
>>
>>
>>  
>>
>

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Reply via email to