Post Reply 
 
Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Slider Protocol Redesign Proposal
05-16-2020, 02:35 PM (This post was last modified: 05-16-2020 02:36 PM by jojoconley.)
Post: #1
Slider Protocol Redesign Proposal
I recently purchased the Slider kit knowing that it wasn't exactly what I wanted but was definitely close, rather inexpensive (comparatively), and seemed pretty solid. Now to make the slider closer to something that is more universally usable I dug into the arduino source code and noticed that all of the tracking is done on device. My thought here is to instead make the arduino fairly dumb, it will take commands on what speed to fire the stepper at and for how long (both rail and platform steppers).

This would allow a shared library to be written for the ios and android apps that could do all of the tracking computations and then send a queue of commands to the arduino to then run through.

The major benefit here being that new functionality could be added by just adding in new functions to the app to translate wanted movement into this queue.

Say we have a 700mm slider and we want to move in a linear fashion from one side to the other while rotating 60 degrees, since the movements are linear we can send just 2 commands to the arduino:

<move, 10mm/s, 70s>
<rotate, 60°/70s, 70s>

Now This would perform a simplified version of what is already available in the app and through the arduino code, but we could now do something like have 2 joysticks in the app, one for linear motion, one for rotating the device. If I move the linear joystick left it could send the command:

<move, -15mm/s, 0.1s>

Then slightly before that previous command runs out, read the joystick value again and send:

<cancel_move>
<move, -20mm/s, 0.1s>


We can even go so far as to have a counter on the arduino that we can reset and adjust to keep track of the offsets since the app pressed a button. This would allow for complex moves by recording deltas from a previous point.

I could have a start position of B:

_____________A__________

Move to B and hit record:
___B____________________

Then move to C and hit record:
_____________________C__


Hit a "Home" button to move back to A and then hit Play to repeat the sequence. If each step is then customizable you could have A -> B slower than B -> C.


Going further, if a limit switch is added to one side we could then home your slider on startup, and save off these recordings so that they could be played back at any time, even if you have turned the device off and back on.

Did a quick wireframe of what a recording page would look like. The track at the bottom would be for a setup similar to the current object tracking setup that is currently available.
[Image: 2Mo7EPx.png?1]

Any thoughts or comments? I believe I can do a lot of the arduino code based on what is already currently available and I can work on the android app. The only problem is I wouldn't be able to work on the ios code since I do not have a mac. I plan on having the library for creating the queue done in c++ so that it can be shared.
Find all posts by this user
Quote this message in a reply
05-16-2020, 07:59 PM
Post: #2
RE: Slider Protocol Redesign Proposal
(05-16-2020 02:35 PM)jojoconley Wrote:  I recently purchased the Slider kit knowing that it wasn't exactly what I wanted but was definitely close, rather inexpensive (comparatively), and seemed pretty solid. Now to make the slider closer to something that is more universally usable I dug into the arduino source code and noticed that all of the tracking is done on device. My thought here is to instead make the arduino fairly dumb, it will take commands on what speed to fire the stepper at and for how long (both rail and platform steppers).

This would allow a shared library to be written for the ios and android apps that could do all of the tracking computations and then send a queue of commands to the arduino to then run through.

The major benefit here being that new functionality could be added by just adding in new functions to the app to translate wanted movement into this queue.

Say we have a 700mm slider and we want to move in a linear fashion from one side to the other while rotating 60 degrees, since the movements are linear we can send just 2 commands to the arduino:

<move, 10mm/s, 70s>
<rotate, 60°/70s, 70s>

Now This would perform a simplified version of what is already available in the app and through the arduino code, but we could now do something like have 2 joysticks in the app, one for linear motion, one for rotating the device. If I move the linear joystick left it could send the command:

<move, -15mm/s, 0.1s>

Then slightly before that previous command runs out, read the joystick value again and send:

<cancel_move>
<move, -20mm/s, 0.1s>


We can even go so far as to have a counter on the arduino that we can reset and adjust to keep track of the offsets since the app pressed a button. This would allow for complex moves by recording deltas from a previous point.

I could have a start position of B:

_____________A__________

Move to B and hit record:
___B____________________

Then move to C and hit record:
_____________________C__


Hit a "Home" button to move back to A and then hit Play to repeat the sequence. If each step is then customizable you could have A -> B slower than B -> C.


Going further, if a limit switch is added to one side we could then home your slider on startup, and save off these recordings so that they could be played back at any time, even if you have turned the device off and back on.

Did a quick wireframe of what a recording page would look like. The track at the bottom would be for a setup similar to the current object tracking setup that is currently available.
[Image: 2Mo7EPx.png?1]

Any thoughts or comments? I believe I can do a lot of the arduino code based on what is already currently available and I can work on the android app. The only problem is I wouldn't be able to work on the ios code since I do not have a mac. I plan on having the library for creating the queue done in c++ so that it can be shared.
Sounds GREAT! I will translate the APP to iOS. No problem. Actually, I was looking for something very similar and as you have said, the camera slider is too close but not there. Your idea is a different approach that can provide very good results.

I wanted to take some photos from different pre-set points / angles and that can not be done at all with the current APP.

I will be checking this thread for updates! Cool project!
Find all posts by this user
Quote this message in a reply
05-16-2020, 08:00 PM
Post: #3
RE: Slider Protocol Redesign Proposal
VERY good idea. We can, as well, create the iOS APP. It is sometimes a pain, but this idea worth the effort.
Visit this user's website Find all posts by this user
Quote this message in a reply
05-24-2020, 08:12 PM (This post was last modified: 05-25-2020 12:44 AM by jojoconley.)
Post: #4
RE: Slider Protocol Redesign Proposal
I broke off the pins for stepper 2 on my original board and then the wifi seems to have stopped. After receiving another board and doing a good chunk of the new arduino code I threw together a quick mock up of the app that does allow the joysticks to be used.





Right now the arduino receives commands through udp packets that tell it to either perform a X steps over Y milliseconds for either the linear motion or the pan motion. A queue of events is then used for each stepper independently that will count down the steps for a given event, step the motor and go to the next event if steps remaining is zero.

I have step tracking for each motor, and will add reporting these values back to the app to allow a list of movements be created, stored and then sent. We'll be able to press a record / snapshot button to remember the current position and then string these together to perform more complicated slides.
Find all posts by this user
Quote this message in a reply
05-25-2020, 08:53 AM
Post: #5
RE: Slider Protocol Redesign Proposal
(05-24-2020 08:12 PM)jojoconley Wrote:  I broke off the pins for stepper 2 on my original board and then the wifi seems to have stopped. After receiving another board and doing a good chunk of the new arduino code I threw together a quick mock up of the app that does allow the joysticks to be used.





Right now the arduino receives commands through udp packets that tell it to either perform a X steps over Y milliseconds for either the linear motion or the pan motion. A queue of events is then used for each stepper independently that will count down the steps for a given event, step the motor and go to the next event if steps remaining is zero.

I have step tracking for each motor, and will add reporting these values back to the app to allow a list of movements be created, stored and then sent. We'll be able to press a record / snapshot button to remember the current position and then string these together to perform more complicated slides.

Wow! LOOKING GREAT
Find all posts by this user
Quote this message in a reply
Post Reply 


Forum Jump:


User(s) browsing this thread: 1 Guest(s)