Topic: Using the tinyG to control a camera rig!

Tagged: smoothness, tuning, typo, wiki

This topic has 4 replies, 2 voices, and was last updated 6 years, 6 months ago by andypop.

Viewing 5 posts - 1 through 5 (of 5 total)

Author

Posts
March 14, 2018 at 11:47 am #10907
andypop
Member
Hello All,

I’m in the middle of an interesting project involving the tinyG controller and a camera attached to an XY gantry system. The idea is to move the camera along predefined gcode paths and take reproducible video of a subject with different gantry motions.

Anyway I had a few questions below – thanks to all in advance for your help:

1) On the tinyG wiki for comms (https://github.com/synthetos/TinyG/wiki/Tinyg-Communications-Programming) under linemode protocol there is a bullet point:

When a {r:…} response comes back from the g2core, add one to lines_to_send.

It’s vital that when any {r:…} comes back that lines_to_send. If one is lost or ignored then the system will get out of sync and sending will stall.

“It’s vital that when any {r:…} comes back that lines_to_send.” seems to be missing a word or two – I assume it wants to say that lines_to_send is incremented but wanted to be sure since its marked ‘vital’.

2) Our priorities for motion differ from a typical system – smooth acceleration/deceleration and basically no jerk at all. The values I’ve tuned to are very different than most I’ve seen but its a result of lots of iteration around getting smooth, consistent motion for the camera (though I’m sure there is lots to go!). If anyone has any advice on good tweaks that would be great. Right now results are somewhat inconsistent.

– a parabolic test path of 60 points/gcode commands runs smoothly during the middle but the start and finish are fairly harsh/jerky

– A three point/gcode command ‘7’ shaped path runs smoothly throughout

– A parabolic test path of 7 points/gcode commands exhibits some pretty harsh start/stop/stutter as it navigates to different points.

the image object seems to not work… link to settings: https://imgur.com/iujnoj8
xjm/xjm/yjm are x 1million, xjd/yjd/zjd are in mm.

Only X and Y axis are responsible for motion.

Thanks again!
- This topic was modified 6 years, 6 months ago by andypop.
March 14, 2018 at 8:36 pm #10909

cmcgrath5035
Moderator

I believe you assumption on 1) is correct.

You might want to post this query at https://github.com/synthetos/g2/issues, it is , as you point out, a bit off the beaten path and Line Mode is very new. Issues is closer to folks who like the far side of the bleeding edge

March 14, 2018 at 10:05 pm #10910

andypop
Member

Thank you for your response!

Follow up! Do you feel that we are limiting ourselves by using the tinyG v8 vs an arduino due + g2core or would the motion that either gives you be about the same?
Strictly speaking about 2 motors and movement in the XY along curves and accel/decel.

March 17, 2018 at 6:24 am #10918
cmcgrath5035
Moderator
tinyGV8 vs DUE ?
Hard to say what differences you might see as you are doing a lot of fiddling with parameters that are not “main stream” (CNC)centric. I don’t believe Line Mode protocol has been backported to tinyG yet.

In a bigger picture sense, you might find that some tweaks to the code are desired, the fw build system for G2core could be your friend.

A major focus for G2Core is 3Dprinter support (in addition to CNC milling, etc.). That translates to precision control of low mass print heads, sort of what you need.
More compute horsepower is almost always a good thing, which implies to me that G2core and DUE might be a better bet.
- This reply was modified 6 years, 6 months ago by cmcgrath5035.
March 19, 2018 at 11:58 am #10924

andypop
Member

Thanks so much for the reply!

I can confirm line mode is in as I’m using that now to send paths over android + serial USB

I’ll check out the DUE – in some ways our needs are less intense than 3DP/CNC as our paths and gcode are much simpler and shorter than any 3d print or CNC part cut path. Most of them I can reduce to < than the queue buffer size!
Author

Posts