As I'm trying to polish up Sabertooth, Joystick, and provide an interface in python you can do this

motor.attach(joystick.getAxis("y"))

I noticed MotorControl has getPowerLevel() & getPowerOutput()  

It looks like getPowerOutput level in some implementation goes through a Mapper.  I'm pretty sure the range in MotorControl "always" be -1.0 to 1.0.  The details of how these values should be "re-mapped" should be in the MotorController, not MotorControl.

-1.0 to 1.0 represents a (nearly) infinite range expressed in a consistent and regular manner.  If MotorController handles the details of how this value translates to what is needed on the driver level, then MotorControllers become much more "pluggable"

On a different topic, I have currently made this possible

motor.attach(joystick.getAxis("y"))

but it involves writing a onJoystickData in AbstractMotor...
There's something which bothers me with this implementation - my AbstractMotor is aware perhaps of "too" many things.  The route should be from Joystick to MotorControl.move not AbstractMotor.onJoystickData.

Which means Joystick needs another publishing function which publishes a single double value of the correct range (-1.0 to 1.0) 

More work, but possible...

I think Servo's knowledge if IKData is a problem of the same type ...

If the Services have less knowledge of each others inner workings to work properly themselves, they will naturally become more "pluggable"

Mats

7 years 1 month ago

On the subject of mapping, I totally agree that any mapping should be made in MotorController, not MotorControl. In AbstractMotor there is a default mapping that I had to override when I implemented MotorHat4Pi. 

Standardizing ranges in the interfaces is a good thing. I hit a similar problem with the ranges for analog values when I built DiyServo. Arduino publishes values ranging from 0-1023, but Ads1115 from 0-65535. This is because they have different precision. So currently DiyServo has logic to know from what service the analog input comes and makes the remapping. 

Perhaps we should have a Mapper service that can take the different types of input and remap between different input/output ranges. Then you would route Joystick => Mapper => Motor, or Joystick => Mapper => Servo  or any other combination where a mapping is needed.

Just an idea. Perhaps there is a better way, but making it possible to combine input/(outputs freely so that you easily can combine services without the need to rewrite the services for each different combination would be great

I can think of many other alternatives, like that a message sending an Anlog value, also contans the min/max values so that the listening service can remap to whatever it needs.

Or that there is a standardized way for the "input" to query the "output" for it's reange. 

 

Great Mats !

I'm glad we are thinking along the same course.

I was concerned that I saw a mapper in MotorControl and it was being used with motor.getPowerOutput.

My first task will be removing them.

We agree all translation should be done in MotorController.

MotorControl I "think" could support invert & min/max - but never do range mapping.  Do you agree with this statement ?

Yes. I agree. I think it's good if MotorControl can support min/max and invert. That makes it easy for the MotorController.

This is a statment I found for the IBT-4 50A module that I test with a drill motor:

http://www.ebay.com/itm/Double-IBT-4-50A-Motor-Driver-High-power-module…

- Drive can work at 0%-98% of the PWM duty cycle, because the drive is NMOS circuit,NMOS circuit features is not to 100% PWM, when PWM 100% of control circuit,long time carries out the operation can lead to drive damage

So being able to limit the min/max to 98% would be good in this case. Like:

Default:

motor.setMinMax(-1,1)

In the case above:

motor.setMinMax( -.98, 0.98)

to avoid drive damage.

And inverting could be simply multiplying by -1. 

 

Please Review - https://github.com/MyRobotLab/myrobotlab/commit/d3a88ebc366ed5bc6ee5ab503d45a40e15080a9c 

For MotorControllers which were "primarily" only MotorControllers I made an AbstractMotorController which implemented MotorController interface.  

Abstracts are certainly nice to normalize member variables.  Java 8 interfaces can only implement default functions and static members (not usually as useful).

Within the AbstractMotorController I have a powerMapper - which for the Controllers I found I 'guessed' the appropriate range mapping.  

Sabertooth I successfully tested..  The others I do not have hardware for.

Hopefully, I put some workable updates - but please adjust or review as necessary.

Regrettably, this was done on my Linux laptop from which I have not grown accustom to the merging tools.  Another reason to review.
Thanks.

I went thru the changes and what I can see they look good. Made a few minor updates to AdafruitMotorHat4Pi and MotorHat4Pi. Mostly cleanup. Thanks :)

Only made a code review. Will soon test with real hardware.