this a the first update in a long time. For those of you wondering why – I needed a little distance from the software development to gather new energy (this does not mean that nothing happened but see for yourself…)! It’s as simple as that. What matters most is that I am currently working on the next release and also have some other great news so let’s get to it!
White screen issue
The white screen issue was solved – finally. As it turns out, there was an update on the hardware of display which is used for the miniEngine version 2. This update was done without any recognizable information to the public (thanks for that ITEAD!). This basically meant that they updated the hardware of the display without updating the documentation. The new display uses a new driver chip and this is was what causes the white screens. I guess ITEAD produces the displays with the driver chip that is available very moment without worrying about their customers… Here is the result.
Anyways, here is how you fix the white screen issue – Open your miniEngine v2 code and change the lines 319 and following in the file miniEngine2.ino
Upload the new software and you should have a working miniEngine!
Next software release
The next release is in the works and will be published within the next 30 something days. This release will bring the following two major updates:
Bouncing functionality that will repeat a shot in reverse direction until one presses the START / STOP button to abort it.
Daisy chaining – You will be able to connect multiple miniEngine v2. One will be the master and control the connected clients. This will allow you to add more axes to your move or shoot simultaneously from different angles with 2 or more cameras.
some time ago I started working on the next version. That included gathering ideas and requirements for a “next level” miniEngine and sorting all of that. I started developing the hardware and so some fist hardware prototypes are being tested by me to make sure that the final miniEngine works as flawlessly as possible. Here is a photo of a little 4-layer test PCB that was tested recently.
This next version version will be entirely surface-mount-technology (SMT / SMD) and readily assembled so that there is no (or almost no) need to solder. It will support 3 instead of 2 motors and most likely have another display than the current version 2 (for obvious reasons 😉 ).
Here is a list of all major updates and changes to the system:
Added the minEngine Studio
Added minEngine functions for the the minEngine Studio software
Added new “Keyframes Mode” which is dedicated to (currently) only work together with the miniEngine Studio
Added a function that updates settings to the new version during a software update (no configuration gets lost any longer)
Improved dashboards to show only relevant data
Improved settings menu-header
Optimized system modes and run styles for easier use
Fixed a bug where the motor was not moving when motor sleep was enabled
Fixed a bug that not saved the keep powered status.
The new Windows client has no documentation yet but should be pretty self explanatory as all button have a tooltip to guide you as much as possible. I also tried to make the user interface as clean and straight-forward as possible. If anyone of you still is not able to figure out how it works, please contact me via the forum. I will help you as good as I can to make it work together with your miniEngine!
If you have any suggestions or find bugs, please let me know. This is the very first release and there is surely lots of space for improvements!
…but mainly I just hope it is of any use for you guys!
Here are some limitations to the functionality which I am aware of:
The defined curves can not yet be stored on the miniEngine. After a reboot everything is gone and needs to be sent to the miniEngine again (this will surely some later).
The communication between the Studio and and miniEngine might not work 100% in any case. If something is not working, try pressing the button again.
The system is not yet “water-proof” and might have some unexpected behavior. I highly recommend using it with care, common sense and limit switches to not destroy your hardware.
It does not work together with the miniEngine v1.
I also added a big portion to the documentation which should explains the system-assembly in much more detail.
Thank you all for submitting feedback and bugs! This allowed me to improve the software and here it is: alpha version 2.0.3! This release fixes some bugs and even adds some new stuff. I highly recommend updating to this release (Don’t forget to update the libraries too)! These are the changes:
updated the documentation (added small system-user-manual)
added some information about updating the software
fixed a bug which started moves from the wrong position if not moved to home before
fixed a bug that moved the motor in the wrong direction when using the function “Move home (all)”
fixed a bug which caused the motor direction to change sporadically during motor jogging
added a new menu font and a font-option to the settings
Minor user interface changes
added all needed libraries into the repository
The biggest change, which you will see immediately, is the new font. I thought it might be nice to have a more readable and clear option. There is a new option for choosing the font so that you can go back to the old one if you like:
I also started working on a Windows client for creating keyframe-based moves. This is in the very early stages but I hope to be able to release it before the summer. Main focus will be defining the bezier-curve based moves and then either save them as a files or directly submit the data to the USB-connected miniEngine.
after some weeks of vacation and some more weeks of coming back to work it is time for another update. This time it will be focused less on the hardware or the user interface but on the core functionalities of the engine. This means that I am currently working on the keyframes engine which will then be used to control the motor movement.
But first let me explain what I am aiming for and why. The motor control-engine of the older miniEngine version don’t allow precise planning of the moves. This means for example that I can precisely define how far the motor should move but I have no real power over its timing. There are possibilities to tweak the speed with which the motor moves but this is far from intuitive and precise. To overcome this issue, I am currently working on ways to have a better control.
The basic idea is to base this new motor-move-management in curves as in the following picture:
This is a screenshot of a small test-application I wrote in Processing 2. It shows a cubic Bézier-curve which would be the perfect solution for defining motor moves. Out of many of these curves side by side, one could create highly complex moves. Here is an example for 2 motors:
Unfortunately are these Bézier-curves pretty processor intensive which is bad because I am using an Arduino. Have a short look at the Wikipedia page of Bézier-curves and you will understand why. For being able to control a stepper-motor with such a curve (or something similar but function-based), I need to calculate the curves y-position (= motor position at this time) based on the time that has elapsed since the program started. The Casteljau’s algorithm can solve this. After I have the y- and thus the motor-position, I can move the motor to that spot. Then I do another calculation based on the new time and so on… All this needs to be done for the two motors + the handling of the cameras, triggers, communication, …
My current main-task is to find a way to do this whole loop that way so that the motor movement is still smooth. To do this I need to find a performant way to do the calculations, pre-calculate as much as possible or use timer-interrupts and time-fragments of constant speeds. I am following different approaches for this and hope to find a good and solid solution.
When this basic technology is developed, I can go ahead and implement a first ready-to-use version which will be based on this new core… This will then be made public to all of you. It will just contain a basic set of features but I know you are waiting to start playing with the new version!
On the hardware side I can tell that the main-PCB is final. I received Revison C and tested it. On the picture below you can see an updated version (Revision D) which just has a nicer silkscreen:
it’s time for the promised update! The last weeks I was working on the system quite a lot. This is what was done…
I received the revision B prototype-boards but had the great “luck” that my order had some production failures and 2 of the 3 boards had random shorts between the different signal and buses (this is the reason for the wires you can see on the pictures). The (free) 2nd run is finally produced and will arrive here within the next couple of days.
I already can tell though, that there will be a 3rd revision of the boards as I want them to be perfect and also received some last-minute ideas which I just have to include! One of them is to add DIP-switches to the motors-driver-board so that one can set the motor-mode easily from 1/8 step to all the way up to full-step.
The other big part of my development work was the implementation of core parts of the software. The basic UI-engine is implemented and running to my satisfaction. I guess I found a good way to realize a smooth user-input-system with just 2 buttons and a rotary encoder. I really like the encoder input and still can use on more button and then there is the touch-input which will be implemented for later versions greater than 2.0.
Here is a picture of the settings menu with 4 of the 5 so far existing menu points fully implemented (the ones that show data on the right side):
when pressing the “edit” button one will see a new screen, dedicated to the selected setting. This screen will contain some basic explanations about what the setting is all about. This way a basic help will be included.
Here is how the main screen will look like (sort of) – this screen will show all the data that is relevant to the actual shoot. The data is still missing but I hope you get a feeling for how it will look like:
As you can see, I added a functionality to read the input voltage and thus display some battery information. This is self-calibrating and will show perfect values after one full battery-cycle (After the system knows the values for fully charged and fully empty). Another feature which I always wanted was the support for color schemes. Here is a picture with the “night-vision” scheme activated.