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
Post Reply 


Messages In This Thread
Slider Protocol Redesign Proposal - jojoconley - 05-16-2020 02:35 PM

Forum Jump:


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