miniEngine version 2 - idea thread

[wsp35]

Thanks to Airic for his work on the engine so far, it is awesome. I hope to have my rig up and running soon, once that happens I will have a look at the code to see if I can implement any of these changes myself. Having gotten a bit further on the development of my PT head here are some of my suggested features, some may be repeats of what others have asked for, but I am putting them up since I agree they are very desirable. Most important features listed first.

Multiple axes:

Although adding more axes to the base unit would be good, I think that a better solution may be to create a different board that can be daisy chained to the current V2 or the future V3. The new board would offer connections for more motors, but wouldn't have a screen or controls, keeping down costs. Control of all motors will be done using the main mini engine unit, and each extra unit will be responsible for running one or two motors. A simple bus network could be run between the boards carrying signal and power.

The motor-only boards could probably use the simpler Atmega chips, and could potentially be made as a dedicated board, rather than a shield. In addition to the motor connections, limit switch imputs and a few other imputs/outputs could be broken out on the pcb to allow for a bit of expansion and customisation.

The original mini engine v2 should also be able to act in a slave mode when on the bus, so it can be used alongside the motor-only boards, being controlled by another v2 or v3.

Better control input for real time moves:
Although you can use the potentiometer to control a single axes in real time it would be good to have a solution which can control multiple axes at once. I have previously used an Xbox handset to control my rig (https://vimeo.com/51856361), but this required a PC to take care of the drivers, I am unsure if an xbox controller could be hooked up to an arduino with USB host, but it is a possibility. I am unsure about just putting a joystick on the v3 as this will still limit you to 2-axes and there are lots of gaming handsets available that have already had a lot of money invested into ergonomics design etc...

3 point keyframing
Would allow more complex moves to be completed with just the miniE

Manual triggering
Would be good for stop motion work and use.

Ministudio - programmed moves keep running once computer is disconnected.
I really like that you have started development of the ministudio and it is one of the main reasons I bought the miniengine, keep up the good work, I will try it out as soon as possible. If this hasn't been implemented already it would be a great feature.

Gigapan
This is another one that I implemented on my own controller before switching to miniE. It should be fairly simple, allowing the user to select the top left and bottom right extents of their photo, or just select 360 for a full rotation. Then set the number of column and rows, then time between photos.

Bluetooth
Adding bluetooth (or possibly wifi) support so that in the future a phone or tablet client could be made for the v3. Maybe a footprint can be left on the pcb to allow the user to choose if they want to add the bluetooth module? Perhaps when daisy-chaining is implemented a bluetooth board could be connected to the bus to allow control via portable devices?

Compatibility with other moco suites
As I mentioned in a previous post it would be cool to have dragon frame compatibility. GB timelapse is another that some use that may warrant integration.



Thanks for all your hard work, hopefully I will have something completed to post on the forums soon.

[wsp35]

Keep in mind I am yet to get my miniEngine up and running yet, so these suggestions are just going off what I know already. Some of these features may already be present!

[Airic Lenz]

(11-25-2014, 09:11 PM)wsp35 Wrote: Thanks to Airic for his work on the engine so far, it is awesome.

Thanks for the great feedback!

(11-25-2014, 09:11 PM)wsp35 Wrote: Multiple axes:

Although adding more axes to the base unit would be good, I think that a better solution may be to create a different board that can be daisy chained to the current V2 or the future V3. The new board would offer connections for more motors, but wouldn't have a screen or controls, keeping down costs. Control of all motors will be done using the main mini engine unit, and each extra unit will be responsible for running one or two motors. A simple bus network could be run between the boards carrying signal and power.

The motor-only boards could probably use the simpler Atmega chips, and could potentially be made as a dedicated board, rather than a shield. In addition to the motor connections, limit switch imputs and a few other imputs/outputs could be broken out on the pcb to allow for a bit of expansion and customisation.

The original mini engine v2 should also be able to act in a slave mode when on the bus, so it can be used alongside the motor-only boards, being controlled by another v2 or v3.

Developing different boards for different purposes will not happen as it takes to much development time, adds unneeded complexity to the system and also adds to the cost (no it does not get cheaper this way as you need to consider the effect of cost-drop for bigger volume-production runs. This one should not be underestimated!). On top of that have the simple Atmega chips not the power that is needed to handle multiple Bézier curves at a time. These Bézier curves are needed for controlling the motors precisely in the two dimensions position and time.

Version 3 will have the capability to move 3 motors but I am already working on a daisy chaining solution for the v2 (communication only - no power as this is not feasible with multiple amperes to be delivered). The next release (late this year or in January) will introduce this feature. V3 will also integrate all needed components and be a standalone solution - no Arduino and no shield needed.

(11-25-2014, 09:11 PM)wsp35 Wrote: Better control input for real time moves:
Although you can use the potentiometer to control a single axes in real time it would be good to have a solution which can control multiple axes at once. I have previously used an Xbox handset to control my rig (https://vimeo.com/51856361), but this required a PC to take care of the drivers, I am unsure if an xbox controller could be hooked up to an arduino with USB host, but it is a possibility. I am unsure about just putting a joystick on the v3 as this will still limit you to 2-axes and there are lots of gaming handsets available that have already had a lot of money invested into ergonomics design etc...

This is a tough one but maybe one could add some kind of plugin-port for adding this kind of gadgets. It would use a simple serial port but could be used for all kinds of extensions.

(11-25-2014, 09:11 PM)wsp35 Wrote: 3 point keyframing
Would allow more complex moves to be completed with just the miniE

This will possibly come with v3.

(11-25-2014, 09:11 PM)wsp35 Wrote: Manual triggering
Would be good for stop motion work and use.

This is already implemented as there is a trigger port for external triggering which starts the engine. Stop-motion though is not implemented yet.

(11-25-2014, 09:11 PM)wsp35 Wrote: Ministudio - programmed moves keep running once computer is disconnected.
I really like that you have started development of the ministudio and it is one of the main reasons I bought the miniengine, keep up the good work, I will try it out as soon as possible. If this hasn't been implemented already it would be a great feature.

The miniEngine does keep running when the computer is disconnected. You can actually upload the data to the miniEngine, disconnect it and then start the move on the miniEngine.

(11-25-2014, 09:11 PM)wsp35 Wrote: Gigapan
This is another one that I implemented on my own controller before switching to miniE. It should be fairly simple, allowing the user to select the top left and bottom right extents of their photo, or just select 360 for a full rotation. Then set the number of column and rows, then time between photos.

Can you send me some information about how you implemented your solution? This should be straight forward but why develop something twice if it is already there?

(11-25-2014, 09:11 PM)wsp35 Wrote: Bluetooth
Adding bluetooth (or possibly wifi) support so that in the future a phone or tablet client could be made for the v3. Maybe a footprint can be left on the pcb to allow the user to choose if they want to add the bluetooth module? Perhaps when daisy-chaining is implemented a bluetooth board could be connected to the bus to allow control via portable devices?

This one is a more complex topic. Radio add a lot of cost to the device (e.g. FCC certification) and also makes it much more costly to add the needed parts to the device. I am not saying that this will not happen but it will surely take some time if.

(11-25-2014, 09:11 PM)wsp35 Wrote: Compatibility with other moco suites
As I mentioned in a previous post it would be cool to have dragon frame compatibility. GB timelapse is another that some use that may warrant integration.

This one I'd like to leave open for the community as my time is limited and the code is open to everyone.

Thanks a lot for your input! I really appreciate it as it helps to make the system better with every single comment / idea / bug report.

Cheers,
Airic

[wsp35]

Haven't checked the forums in a while as I have been waiting for components, but my miniE is pretty much altogether now. Just waiting for a couple more bits. The reply function on the forum is a bit messed up, had to do some trickery to be able to post this.

Quote:Developing different boards for different purposes will not happen as it takes to much development time, adds unneeded complexity to the system and also adds to the cost (no it does not get cheaper this way as you need to consider the effect of cost-drop for bigger volume-production runs. This one should not be underestimated!). On top of that have the simple Atmega chips not the power that is needed to handle multiple Bézier curves at a time. These Bézier curves are needed for controlling the motors precisely in the two dimensions position and time.

Version 3 will have the capability to move 3 motors but I am already working on a daisy chaining solution for the v2 (communication only - no power as this is not feasible with multiple amperes to be delivered). The next release (late this year or in January) will introduce this feature. V3 will also integrate all needed components and be a standalone solution - no Arduino and no shield needed.

I would have thought the hard stuff could be handled by the master controller and the slave units could just have an atmega hooked up to a driver to receive instructions from the main controller. Kind of like the dynamic perception nanomoco can do with the NMX controller. I welcome the move from arduino shield to stand alone, would you also move to SMD for the components? As I pesume there is no through hole version of the ARM micros.

Quote:This is already implemented as there is a trigger port for external triggering which starts the engine. Stop-motion though is not implemented yet.

Quote:This will possibly come with v3.

Quote:The miniEngine does keep running when the computer is disconnected. You can actually upload the data to the miniEngine, disconnect it and then start the move on the miniEngine.

Excellent!

Quote:Can you send me some information about how you implemented your solution? This should be straight forward but why develop something twice if it is already there?

I don't have the code anymore unfortunately, but it was a pretty basic implementation, just a couple of nested for-loops for columns and rows.
One thing I did find was that most gigapan stitchers (or at least the ones I used) expect the image sequence to be captured column by column from the top down.

Quote:This one I'd like to leave open for the community as my time is limited and the code is open to everyone.

I'll take a look at getting it working with dragon frame.
http://www.dragonframe.com/arduino/serial.php

S

[wsp35]

Another suggestion after getting my PT head working:

For the manual axis jog tool smooth accelerations should be used, rapidly changing the velocity to match the input speed causes frequent stalling even if the speed is well within those capable by the hardware (when smooth acceleration is used).

[Airic Lenz]

(06-22-2015, 12:56 PM)wsp35 Wrote: Another suggestion after getting my PT head working:

For the manual axis jog tool smooth accelerations should be used, rapidly changing the velocity to match the input speed causes frequent stalling even if the speed is well within those capable by the hardware (when smooth acceleration is used).

I'll try to replicate the error next weekend.
/Airic

[oobikinoobi]

Hi Airic
One idea I think could be really useful is the ability to specify a time delay for when a motor would start once the program is running. For example, axis 1 could start its travel immediately, axis 2 could be delayed for say five minutes, and axis 3 delayed for ten minutes, combined with ramp in/out this could create some interesting moves and effects. I hope this makes sense?

I know this capability already exists in miniEngine Studio, but sometimes taking a laptop/notebook to certain locations isn't always an option.

Best regards
Darrell

[Airic Lenz]

(10-23-2015, 12:22 AM)oobikinoobi Wrote: Hi Airic
One idea I think could be really useful is the ability to specify a time delay for when a motor would start once the program is running. For example, axis 1 could start its travel immediately, axis 2 could be delayed for say five minutes, and axis 3 delayed for ten minutes, combined with ramp in/out this could create some interesting moves and effects. I hope this makes sense?

I know this capability already exists in miniEngine Studio, but sometimes taking a laptop/notebook to certain locations isn't always an option.

Best regards
Darrell

This is already possible when using the miniEngine Studio. You can define your moves as complex as you like it and precisely define when which motors is supposed to be where.
Cheers.