MotorControl MotorController and the power range between them

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


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


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"

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Mats's picture

MotorControl / MotorController mapping

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. 


GroG's picture

Great Mats ! I'm glad we are

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 ?

Mats's picture

Yes. I agree. I think it's

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:

- 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:



In the case above:

motor.setMinMax( -.98, 0.98)

to avoid drive damage.

And inverting could be simply multiplying by -1. 


GroG's picture

Please Review

Please Review - 

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.

Mats's picture

Looks good

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.