-
Notifications
You must be signed in to change notification settings - Fork 412
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
C++ API and Abstract classes #681
Comments
Hi @abogani, and thanks for raising this question. We do include a good number of interfaces to help with portability for sensors of the same type. About 10 of these have been around for quite some time in order to collect developer feedback and determine what's the best way to handle them via SWIG. We have since increased the number to over 30 and now, many UPM sensors implement them. The best part about this is that the new interfaces are useful even with the other languages (Java, JS & Python). Actuators are a bit more complicated and this is were we continue to ask for developer feedback and help. Let's use the stepper motor as the example. There are 2 popular generic implementations (step and direction or "direct" coil control via gpio). Add to this hundreds of very custom industrial controllers or weird combinations of the generic methods. I could easily say that step and dir functions will make for a good interface for stepper motors, but then you will come in and say speed control is also very important and should be part of the abstraction rather than user code. And this is where it gets challenging, because setting the speed needs utility classes and the implementation will now vary substantially based on the target device, going against what the abstraction was meant to do. So to summarize, we did abstract a lot of sensors types, but actuators are a different story and we invite the community to take the initiative for them. Hope this helps clarify things but please let us know if you have additional questions or suggestions on this! |
@Propanu Thanks for detailed explanation! What do you suggest me to do then? Should I propose the code of an asbtract class for stepper motors or should I implement an abstraction layer for that type of actuators at user level code (my application)? Thanks again! |
Hi @abogani, sorry for the delay. If you want to open a PR with a new iStepper interface, I will be more than happy to help shape it and get it integrated with the rest of the UPM. With 2 pure virtual functions for step and direction it should be possible to cover most if not all of the steppers in the project. |
Why doesn't UPM use the abstract classes to improve code portability between devices (i.e. for Stepper Motors)? Is it a choice made by design? If yes why?
The text was updated successfully, but these errors were encountered: