Do you actually rely on the "rail length" feature

[equilerex]

Hi guys, i need some feedback.

Im about to rewrite this whole thing, partly as a code practice, partly since it needs new features like

• stepper motor with multiple speed
• multiple motors for several axis
• physical end of the rail Indicators (buttons the slider would run into)
• Possibility for dedicated physical buttons for start/stop/direction, etc.
• Manual controls for video

So if anyone actually reads/keeps eyes on this thing, would you mind sharing if you are actually relaying on the "rail length" and the slider switching back and fourth automatically according to it?

Since my construction is not static with me taking it apart every time i move, its always been a bit funky, so now i'm thinking if its worth keeping that feature alive if il have physical buttons indicating that its at the end of the rail? (i would enter how many minutes i want the time lapse to take instead and it would just keep looping for that ammount of time or until i hit stop) The only problem i see with that is that its hard to get a good overview of how many shots you will get from one length of the rail.

In case of stepper motors, it would actually be pretty tricky to keep track of rail length anyways so i think those need a switch regardless.

So any thoughts on that in general or any more feature requests

[JulioCVM]

It sounds awesome to me that you're planning to develop this enhancements for the project. I personally would love all the ones you have listed, but exceptionally the possibility of adding more motors, as I'm planning to add a second motor to provide turning control to the camera. Than you so much again for your work @equilerex. As I once contacted you via e-mail to solve some questions, I can say other users you are such a wonderful dev.

[equilerex]

@JulioCVM thanks, glad youve found it useful. And yeah, everything listed will be included, just the question of "when" probably going to be a few days of intense work but have to find that slot first :)

[philip100]

Hi guys, i need some feedback.

Im about to rewrite this whole thing, partly as a code practice, partly since it needs new features like

• stepper motor with multiple speed
• multiple motors for several axis
• physical end of the rail Indicators (buttons the slider would run into)
• Possibility for dedicated physical buttons for start/stop/direction, etc.
• Manual controls for video

So if anyone actually reads/keeps eyes on this thing, would you mind sharing if you are actually relaying on the "rail length" and the slider switching back and fourth automatically according to it?

Since my construction is not static with me taking it apart every time i move, its always been a bit funky, so now i'm thinking if its worth keeping that feature alive if il have physical buttons indicating that its at the end of the rail? (i would enter how many minutes i want the time lapse to take instead and it would just keep looping for that ammount of time or until i hit stop) The only problem i see with that is that its hard to get a good overview of how many shots you will get from one length of the rail.

In case of stepper motors, it would actually be pretty tricky to keep track of rail length anyways so i think those need a switch regardless.

So any thoughts on that in general or any more feature requests

Hi equilerex

First - awesome build!

I made similar project using Arduino Pro Mini and bluetooth, instead of Pi. To answer your concerns:

• Rail length is none of an issue - you can always incorporate rotory encoder for the motor (unless you have a motor with encoder built in).
• Stepper motor is very easy to control (easier than a regular DC motor), but for me it's disqualified in video making because of the noise it produces.
• Estimating times (or shoots per length) is much easier with a stepper than with a DC motor.

Overall, since you've built nicely working slider based on Pi, I would not think of sliding processes (despite tools you choose, untill they're "readable", it's just a matter of math), but rather simplifying the functionality by incorporating libraries available on linux platform into your project, f.ex - something like gphoto2. You could get rid of some unnecessary settings ("wait time" before slides - you could just read exposure time from camera, add it to the time automatically, and count/check total time/length) and bake two cakes at once: slider + camera control wirelessly :-D Moreover - a holly grail (day -> night -> day) timelapse automation, which wasn't yet incorporated in any autonomous system.

As I mention - I've built the same thing using an Arduino micro board. If I had any clue of how to use Pi (basically linux) to do the same things, I wouldn't bother of mechanical aspects and keep focus on program itself

Keep going! :-)

[equilerex]

Hi Philip,

Thanks for the feedback... got quite a bit of insigth since i had no idea about libraries like gphoto and devices like rotory encoder.

gphoto sounds like it might be a pretty neat venture but the documentation looks horrid and from the git page, it seems pretty fiddly and unstable.

overall, i have no issues with the capture and settings on the current version. The "wait" time is a must have since in most cases, i dont want the next shot to happen as fast as possible, rather then give it some time depending on what im shooting. in here, gphoto2 could help with validation, making sure the camera value is not smaller than the app value but not really worth the hassle i think. (Im also guessing you looked at the screenshot that says "shutter speed". You normally do not need to define that as long as the shutter speed in the camera is less than the "wait. On the screenshot however, the "bulb" mode is enabled, which allows to control the camera's shutter speed from the app)

the day/night/day already works fine as well, as long as you leave the camera on auto with max shutter speed lower than the wait time.

so the main issue thats left that i see is still the stepper motor... its not exactly just a maths issue since its a generic library while different stepper motors come in loads of different flavours in terms of how fast they are, how big of a difference there is from one speed to another, etc... i cant really think of a way where i can reliably calculate the rail width without knowing all the variables, there for the best i can think of are physical buttons (which is safer, dumber and there for more reliable anyways). And steppers have been tricky since javascript is too slow to be able to control them directly, they need very precise data pulses so i need some kind of a middle man library in python or something)

This project got really sidetracked as well over the past year+. its finally back on the agenda for this year so should get it going again sometime soon :P