It bothers me OFM requres Rasp Pi + Nano when the Rasp Pi is capable of both Microscope Server + Microscope Client (if running locally) + running the 3 x,y,z stepper motors.
So - despite being clueless ( a common initial state for me - perhaps sadly) - I was able to Use the OpenFlexure CLI to navigate the microscope with the stepper motors being driven by the Rasp Pi’s GPIO pins. This to me is exciting!
Not sure why it bothers you. The correct design is to split the realtime motor controls into a microcontroller that can guarantee the required tight timings and provides a high level command interface to the main control system. It’s basic systems engineering. This also has the benefit of making it easier to use something other than a Raspberry Pi, which are scarce these days.
I am grateful for your doubt, Thomas (@tkircher ). I very much wish to learn and evolve from that learning. I considered your thoughtful comments and wanted to provide my thoughts in hopes for better understanding (at least on my part because it truly amazes me how much I don’t understand!).
My takeaway from your comments:
You assert the microcontroller guarantees the required tight timing and provides a high level command interface to the main control system. (I am unclear of the specifics of required tight timing. I have not found that to be the case? )
You assert using a Rasp Pi instead of the Nano is wasteful, especially if one cannot find a Rasp Pi (except on Adafruit, because they are awesome to their customers).
Both of the assertions fail testing:
So the interaction between the software and hardware is basically a GPIO pin on/off. the “timing” (I think of it more as a displacement) is made through turning on/off 4 pins of the ULN2003 driver. Thus, doing it through a Nano or Rasp Pi is identical. And the only timing is needed to make sure turning on/off the pins does not collide (thus there is a small amount of time put in between displacements).
And lets not forget why there are a billion 28BYJ-48 motors out they. Their use case scenarios are ones - like automatic blinds, other consumer units - which is why they are ubiquitous and extremely inexpensive BUT NOT PRECISE. In fact, while the specs say 64:1 gear reduction, as many know…" Some patient and diligent people on the Arduino forums have disassembled the gear train of these little motors and determined that the exact gear ratio is in fact 63.68395:1 . …These means that in the recommended half-step mode we will have:64 steps per motor rotation x 63.684 gear ratio = 4076 steps" …Note: From my understanding of the code, it does not accommodate for this discrepancy. The main point is the motor itself is very inaccurate - so anything above it will be inaccurate too.
Again, I thank you very much for your reply. I appreciate the opportunity to give my point of view. I hope my details elaborate on why I am “bothered”
Most moves are indeed not time critical, and the timing requirement for the steppers is usually a matter of not being too fast between steps, rather than precise timing. The fast autofocus is however an important function of the microscope that does rely on timing, looking at regularly spaced images in time from the camera as the stage moves at regular steps in time. It is not impossible to deal with that by making checks if everything is running on the Pi - in principle the Pi program knows which steps came before which image. For the Delta stage timing is more important as two or three motors have to move in order to get movement along a single cartesian axis. I am with @tkircher that the more usual systems approach of embedded moving hardware on the Arduino and the supervisory program on the Pi is more generally useful for not a great deal of cost and effort. There need to be the motor drivers and wiring anyway.
Thank you @WilliamW and @tkircher . I am extremely grateful for your comments.
It saves me so much time. I will stop exploring removing the Nano. Whadawasteatimeamiright?
Have an awesome weekend (and stay cool!)
It is a good suggestion to merge the functionality, but it might not be a feasible for the current openflexure team to take on given finite resources.
I’m sure that if a user wanted to design, develop, test, and document a PCB that incorporates an rPi and a microcontroller, along with the accompanying code changes, Openflexure would love to incorporate a more integrated design. Particularly if all the hardware is in-stock. Maybe an rPi 4b wth 8 gb ram + rPi 2040?
Likewise, I’m sure that if someone want to refactor the code, design, test, and document running everything off a single rPi, while proving that the edge cases don’t get broken, that would also be awesome! It sounds like maybe you have already done this? I personally haven’t had time to contribute this feature set. A more experienced software developer could probably do it much more quickly than me.
Callbacks and imperfect timing can lead to occasional missed steps on a system like rPi. Which is fine if you have a closed-loop controller, or for doing short term experiments, but if you’re running open-loop and longer sequences, a ‘wasted’ microcontroller might be relatively inexpensive.
It’s also worth considering the the 28BYJ-48 units are made by many manufacturers, and you may find through more browsing that some units have a precise geartrain reduction ratio of 63.68395, while others have different gear train reduction ratio. The post you linked to also comes to that conclusion. Unless we’re purchasing parts from openflexure, I think this is an exercise left to the user for proper calibration (perhaps using an inexpensive micrometer stage, or by buying extra and taking one apart to count gear teeth). Also note the Adafruit 28BYJ-48 units have an entirely different step/revolution count (528).
@few Thank you for your reply. It was full of advice/insight that I did not know.
Q: WHAT SPECIFIC FEATURE REQUIRES THE MICROCONTROLLER?
Is it what I infer from @WilliamW’s reply? fast autofocus ?
said another way:
Q: IF AUTOFOCUS “WAS PROVEN” TO WORK WITH RASP PI ONLY IS A MICROCONTROLLER STILL NEEDED?
You asked what I have done. This UI: I have gotten navigation to work through the client:
.
All Arduino code has been replaced w/ Rasp Pi code. The class talks directly to classes defined in the OFM server code.
If it is possible, I’d like your advice on what UI features require a microcontroller Given the pushback, I may not pursue at all. (This is the challenge when we are not all discussing around a white board…) I mean, I get the perspective of dividing moving actuators == microcontrollers … but I do not know and am not smart enough to feel confident it absolutely must be this way. Particularly when there is quite a burden when adding the Nano to the building and maintenance of the system.
Hmmm…I wonder if there is a test suite that docs “good enough metrics”?
I was reading the Adafruit thread you noted. Just to clarify, there is no Adafruit 28BYJ048 specific motor. Yah - Adafruit sells one … but I like Bill’s final reply:
These motors were originally designed for automotive vent controls. Since these only move through a partial rotation, the odd gear ratios are not a big deal. It is strange that there is so much variation between different manufacturers of the same part-number. :?
As this is the case, how is timing the critical feature? I get your point about closed loop which makes sense to me…
Again, thank you. I am grateful for what I learn from you.
Timing is critical in all stepper motor controls, to generate the correct acceleration and velocity profile. You pointed out that there’s a discrepancy in gearing ratio, but that’s irrelevant. To calibrate a microscope movement you use a reticle to empirically measure the step to displacement ratio and provide that number to the controller for each axis. You assert that any inaccuracy in the system means that any other inaccuracy can be ignored, but in reality sources of error are compounded and it is always beneficial to remove as many as possible.
In my case, I am using NEMA8 motors with a gearbox and DRV8834 stepper drivers. It was a simple matter to modify the Arduino firmware for this, but community experience with 3D printers and CNC machines has shown that using GPIO to control three such motor drivers simultaneously is not possible to do reliably with a Raspberry Pi. I am also experimenting with using Tensorflow to identify microorganisms and for the microscope to attempt to follow them, which has more strict requirements than what you might be doing.
Here’s a source for you to understand more about motor controls:
I don’t think that rPi driven motors will work well in all openflexure applications, but being able to set up a minimalist system would certainly be nice for many users (many don’t use motors at all). The easy path would be to fork the existing project and post your modified code on GitHub, along with documentation. Then post it back here in the forums! 
The openflexure team have published many papers about their system, including long tests (a month?) documenting positional errors/drift over time. It is likely not feasible to repeat all that testing for third party contributors, regardless of the submission quality. However, potentially in the future they could merge in some code to allow rPi driven motors for a minimalist system build. Since GitHub is free, making a repository of your own is a great option!
Unfortunately, timing is very critical on most mechanical drive systems. For example, if the system sends a pulse train with timing that constantly changes, it can greatly increase the forces that gears are subject to. Likewise, if using drive systems where you want to control acceleration (which is always a good idea), then the system needs to have well defined interrupt / callback timing. If the computational load on the rPi is increased (such as from recording or processing data, controlling additional equipment, or communicating with external systems), then the timing can become very different. Unfortunately, Linux is not a real-time operating system (callback timing is not guaranteed). As a result, it’s difficult to know exactly when a Linux driven motion control system will perform poorly.
That’s the same reason 3d printers, desktop CNC routers, laser cutters, etc all have embedded microcontroller based boards. 25 years ago, such low cost systems were often driven from windows via parallel ports connected to external electrical drive boards, but the resulting motion control systems were either very slow or very inconsistent.
@tkircher Thank you so very much! Your insight and experience is invaluable! As is obvious, I lack in knowlege. But I hope not in enthusiasm and the ability to learn! This part: " three such motor drivers simultaneously is not possible to do reliably with a Raspberry Pi." That this has been tried, etc. means a lot. Another point is about the absolutely amazing far more interesting things you are attempting: “using Tensorflow to identify microorganisms and for the microscope to attempt to follow them, which has more strict requirements than what you might be doing.” THIS IS SO EXACTLY WHAT I WANT! I love to watch the microbes in my soil (I grow plants). I kept wondering why given where we are with machine learning and auto focus, how hard can it be to detect bacteria, fungi…movement…
Is there a way for me to follow along with your project and try it out as you make progress with Tensorflow microbe id?
I will read the source you kindly included. I can only hope I can understand at least 10%!
I’ll dustball this stuff. The good part is I also appreciate what I learned from the code.
Thank you for the time it took you to provide these insights.
@tkircher - I get a this site can’t be reached. Apparently, pmdcorp.com can’t be resolved by the DNS my machine resolves names with…
I can’t attach a PDF for you, but here’s a screenshot from the document that gives the main point I was after.
