climategadgets / servomaster Goto Github PK

Current README.md contains obsolete links to http://servomaster.sourceforge.net/, and Wiki is embarrassingly empty.

Starting any demo clears any transition controllers attached to the servos, and doesn't restore it when the demo is stopped (but doesn't change the state of the transition controller dropdown, either).

Need to restore transition controllers (or, optionally, not clear them at the beginning of the demo).

This variable was put in place before generics came out (2000 vs 2004), long obsolete. Need to make it a generic type and make all concrete implementations provide their own specific constraints.

It is outright ugly. Also, silent operation now needs to be supported on per-servo level.

Adafruit 16-Channel PWM / Servo HAT for Raspberry Pi - Mini Kit provides a very reproducible and standard servo controller solution for Raspberry Pi, it would be a shame not to support it.

http://servomaster.sourceforge.net/ is now being decommissioned, need to refresh the documentation and port it to Wiki right here (and possibly to https://climategadgets.github.io/servomaster/ as well)

Currently, Servo#setPosition() throws IOException. However, this will not properly if the position is changed asynchronously, either via hardware means (limited speed or acceleration) or transition controllers.

Need to communicate a failure to the caller in an identical way whether the transition is instantaneous, or delayed.

This is related to #30.

Adafruit DC & Stepper Motor HAT for Raspberry Pi - Mini Kit provides a very reproducible and standard stepper controller solution for Raspberry Pi, it would be a shame not to support it.

This enhancement is much more complicated than #6, though. Steppers, unlike servos, do not have inherent limits, and if a stepper is used as a servo, there will have to be solutions put in place to allow limit detection (limit switches and torque sensors, to name a couple). In addition, stepper positioning model (discrete steps) is different from servo positioning model (floating point 0 to 1 with adjustable ranges and limits), so some extra work will need to be done.

As it stands now, servo controllers will stay in their current state when Servomaster code is shut down (i.e. if they were issuing servo pulse, they will keep doing so, and if they weren't, they won't, or whatever else the firmware is programmed to do).

It would be a good idea to provide a convenience method to ServoController to put the servos into de-energized state, to save energy, wear and tear, and improve hardware maintenanceability (it's nice not to have to struggle with servos that want to stay where they were, not necessarily where one wants them to be).

Unless special measures are taken, the multi-level build will not be able to resolve its dependencies. Need to address this.

It's obsolete and slow. Out.

Currently, silent support is implemented only on per-controller basis. However, these days most controllers implement disabling the servo pulse per servo. Need this supported.

Currently, in order to stop the test, the mouse needs to be moved. Need to change the behavior in such a way that the demo can be started and stopped without moving the mouse.

Currently, if an error happens in the middle of a transition, it is just logged, and that's it.

However, the way Servo#setPosition() communicates the status allows to pass it to a TransitionController and further to Servo#setPosition() caller.

Current Gradle build issues this warning:

Deprecated Gradle features were used in this build, making it incompatible with Gradle 5.0.
Use '--warning-mode all' to show the individual deprecation warnings.
See https://docs.gradle.org/4.9/userguide/command_line_interface.html#sec:command_line_warnings

As an application maintainer, I want to integrate the build with GitLab CI/CD so that sanity checks are done in the background regardless of whether I forget to run unit tests or not.

Acceptance criteria: GitLab CI/CD successfully builds the project.

At least OpenJDK 1.8 performs instantiation in such a way that an object instantiated via abstract method call may use not yet initialized variable values, resulting in erroneous values being used. Case in point these two together result in zero "servo/precision" property upon instantiation:

As an Application Maintainer, I want to enable test coverage calculation as a build pipeline so that I can have an idea about what code can be (somewhat) trusted.

Current implementation of silentStatusChanged() (in the controller and the servo),exception() (in the controller and the servo), positionChanged() and actualPositionChanged() allows the listeners to sabotage the servo by either throwing an exception or getting stuck. Need to fire a set of messengers to all listeners and notify them asynchronously, in correct order. Further need to protect the messenger queue from a listener getting stuck, and log a message about that.

Need to implement a per-servo UI control to adjust servo transition acceleration for controllers that support it.

Console class was created specifically for showcasing any driver's abilities. However, it will work only with specific classes, and the secret of invoking it is long lost.

Need to create a simple harness that would be a one-line no-brainer Console invocation for someone that sees Servomaster for the first time in their life and has no Java proficiency.

Expected Result

Other projects hosted anywhere can use this project as a dependency without jumping through hoops

Actual Result

Build artifacts are not published anywhere

Corrective Action

Modify CI/CD pipelines so that build artifacts are published

Even if it is just @Override, it's already better than before.

Currently, touch() and/or wakeUp() are called from driver specific servo implementations. Need to make the call uniform and move it to setPosition() where it would be called regardless of whether a particular class supports silent operation - simplicity wins over [negligible] performance hit.

Currently, the Swing demo enumerates all the servos supported by the connected controller. That may be too much (who would connect 16 servos to the test bench?) Need to skip the servos that aren't enabled at the Console.

Zero value for "servo/precision" property makes the controller to simply stop the transition immediately without ever changing the actual servo position.

Expected Behavior

It is not possible to make a mistake and put a value in seconds into a field that expects milliseconds, or the other way around.

Actual Behavior

It is. Oops.

Need to implement a per-servo UI control to adjust servo transition velocity for controllers that support it.

Currently, the precision and range are read at instantiation and are not updated if the servo range is adjusted, which causes the actual position slider, and requested position ticks to be off after range adjustments.

As an Application Maintainer, I want local and CI/CD builds to produce ErrorProne reports so that they can be available on the spot without jumping through the hoops with IDE plugins.

Acceptance Criteria: the build composes ErrorProne report.

Existing Behavior

• servomaster-common - contains things that don't belong there, and the name doesn't match currently accepted conventions
• servomaster-serial
• servomaster-usb
• servomaster-raspberry-pi

Desired Behavior

• servomaster-api - must contain everything necessary to interface with abstractions but none of the implementations
• servomaster-serial
• servomaster-usb
• servomaster-raspberry-pi
• servomaster-console

PCA9685 controller supports silent (de-energized) operation on per-servo basis. So far, the only controller that supported it was Phidget v3, but Servomaster support for this feature was never implemented.

Currently, the transition queue is never cleared (ref). Need to implement the advertised behavior.

#15 needs changes that break DisconnectListener callbacks in controller-specific legacy views (they need to be retired anyway). Need to implement a disconnect listener panel that will be instantiated according to rules set forth in #14.

Lazy implementation just keeps sending setPosition() every 50ms instead of every second, as a decent clock would do.

Currently, Console expects a class matching the servo controller class with a View suffix (case in point: PhidgetServoController, PhidgetServoControllerView). Code supporting the view is boilerplate. It will make perfect sense to implement this code once and for all and activate upon feature presence, based on servo controller and servo metadata.

Original code was written before dependency injection became commonplace. Need to update the behavior - it shouldn't be possible to change the object heritage once it's been instantiated.

Right now, there's a mess with calling init() from constructors causing all sorts of instantiation race conditions - there's no sensible solution other than a total separation of instantiation, initialization, and use.

• https://www.phidgets.com/?prodid=56
• https://www.phidgets.com/?prodid=1032

Why? Because hardware support for position, velocity, acceleration, and current sensing.

Task Definition

As an Application Maintainer, I need to migrate build scripts from Groovy to Kotlin so that they are written in a well known language learning which has other benefits than just being able to write Gradle build scripts.

Acceptance Criteria

Gradle build files are written in Kotlin DSL.

Current TransitionController support is overcomplicated - it involves two threads and asynchronous exchange between them. It works, but it can be made simpler using just one thread and a proxy with access to AbstractServo#setActualPosition().

This issue is related to #5.

v0.x behavior didn't mention anything about silent operation, whereas gen2 does - need to correct implementation to conform to the advertised behavior.

Should be probably called PresenceListener and have an ability to issue notifications about arbitrary entities.

As an application maintainer, I want to integrate the build with Travis CI so that sanity checks are done in the background regardless of whether I forget to run unit tests or not.

Acceptance criteria: Travis CI successfully builds the project.

Too many to count

Granted, TransitionCompletionToken (coming from net.sf.jukebox.sem.ACT) predates java.util.concurrent.Future by about 10 years, but the former is unique, and the latter is the part of Java core now.