JJRobots COMMUNITY
Slider Protocol Redesign Proposal - Printable Version

+- JJRobots COMMUNITY (http://forums.jjrobots.com)
+-- Forum: JJrobots (/forumdisplay.php?fid=1)
+--- Forum: Motorized Camera SLIDER (/forumdisplay.php?fid=47)
+--- Thread: Slider Protocol Redesign Proposal (/showthread.php?tid=2522)



Slider Protocol Redesign Proposal - jojoconley - 05-16-2020 02:35 PM

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.


RE: Slider Protocol Redesign Proposal - JohnQ - 05-16-2020 07:59 PM

(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!


RE: Slider Protocol Redesign Proposal - JJrobots JP - 05-16-2020 08:00 PM

VERY good idea. We can, as well, create the iOS APP. It is sometimes a pain, but this idea worth the effort.


RE: Slider Protocol Redesign Proposal - jojoconley - 05-24-2020 08:12 PM

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.


RE: Slider Protocol Redesign Proposal - JohnQ - 05-25-2020 08:53 AM

(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


RE: Slider Protocol Redesign Proposal - Oki - 06-17-2020 12:32 AM

(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.

Great job! Would you mind to share your code?
Did you thought about Blynk App?
I was not able to make motors working via Blynk due to lack of my knowledge how to correctly control the stepper motors. Basic example arduino code for Blynk would help not only me but anyone could build his own App Smile


RE: Slider Protocol Redesign Proposal - MisterMaker - 06-19-2020 11:00 AM

Is there anyway we can remove the password on the wifi? It is not that someone is going to hack into my slider and control it.... That is just stupid.
Because I have to forgot the wifi network and reconnect everytime, since android flips because it has no internet.
Normally this would be easy as you could just do NULL in the code, but I don't have the code of the esp. Does this esp has OTA enabled?


RE: Slider Protocol Redesign Proposal - Stubby - 06-19-2020 03:09 PM

(06-19-2020 11:00 AM)MisterMaker Wrote:  Is there anyway we can remove the password on the wifi? It is not that someone is going to hack into my slider and control it.... That is just stupid.
Because I have to forgot the wifi network and reconnect everytime, since android flips because it has no internet.
Normally this would be easy as you could just do NULL in the code, but I don't have the code of the esp. Does this esp has OTA enabled?

Fortunately, my iPhone IOS memorizes the password the first time you use it.

I have the Camera Slider running on Blynk; I'm just waiting for J&J to announce it officially here on the board. I have it working with the JJRobots and Neweer sliders.
Here is the link to the project: Arduino-based Camera Slider interface using Blynk


RE: Slider Protocol Redesign Proposal - jojoconley - 07-04-2020 02:59 PM

(06-17-2020 12:32 AM)Oki Wrote:  
(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.

Great job! Would you mind to share your code?
Did you thought about Blynk App?
I was not able to make motors working via Blynk due to lack of my knowledge how to correctly control the stepper motors. Basic example arduino code for Blynk would help not only me but anyone could build his own App Smile


I do not plan on using something like blynk. In my experience, most drag and drop systems just fall far short of anything I could do in a relatively short amount of time myself.

Writing a relatively simple android app is doable in a weekend I have only a few features left to implement for the arduino. This is mostly communication from the slider to the phone. This is for things like telling the phone how many mm's the sliders have moved since being "homed". This allows for a stack of actions to be used to tell the slider to move in a given direction for a given amount of time. This should make these movements repeatable.