Inversing I2C sensor in robotc

[Eric_J]

We have starte to use I2C sensors this year and is it possible to reverse the tick count (0 is the down position on our lift, and -2000 is the top, I want +2000 to be the top). On the older quad encoders we just swaped the wires so the the direction would change.

I know the motor is running in reverse to have the lift to go up, and I would rather not have the sensor on the opposite motor on the lift.

Could I say the motor is a 269 (not a 393) so the encoder would read the opposite direction?

[OscarMNOVA12]

You could just use the abs function in RobotC and take the absolute value of the encoder value.

Or do greater than the negative value.

[jeffmald]

Or you could just Multiply it by -1

[Eric_J]

@OscarNVCC

You could just use the abs function in RobotC and take the absolute value of the encoder value.

Or do greater than the negative value.

I am curently doing if the number is greater than -2000 then do stuff, but in my opinion this makes the code hard to read. I do not want to use a abs because then I would have to remember to use it everytime I read the encoder.

[OscarMNOVA12]

So,

 

while(SensorValue[liftEnc] > -2000) 
{ 
    //Perform some random instruction
} 

is hard to read in your opinion?
Do you mind posting your code?

[jeffmald]

This is what I would do

LiftEncInvert = (SensorValue[liftEnc])*-1 ;

And just use LiftEncInvert for what ever you need.

[jpearman]

@jeffmald

This is what I would do

LiftEncInvert = (SensorValue[liftEnc])*-1 ;

And just use LiftEncInvert for what ever you need.

Just to reinforce the point, this is the (IMO) best way to do this. When ROBOTC and other firmware is reversing direction based on the reverse flag, this is all that happens.

The other thing you should really do is use nMotorEncoder with the motor port rather than SensorValue. Two reasons to do this.

1. nMotorEncoder will reverse the encoder count so that a positive motor command will always cause the encoder to increase the count. iw. it internally uses the multiply by (-1) trick.

2. nMotorEncoder returns a 32 bit integer, SensorValue returns a 16 bit integer and under certain circumstances it may overflow.

[edjubuh]

@jpearman

it internally uses the multiply by (-1) trick.

Now I have to ask:

-myVariable

or

myVariable*(-1)

Does it matter? Is there a convention?

[drdanielfc]

@jpearman

Just to reinforce the point, this is the (IMO) best way to do this. When ROBOTC and other firmware is reversing direction based on the reverse flag, this is all that happens.

The other thing you should really do is use nMotorEncoder with the motor port rather than SensorValue. Two reasons to do this.

1. nMotorEncoder will reverse the encoder count so that a positive motor command will always cause the encoder to increase the count. iw. it internally uses the multiply by (-1) trick.

2. nMotorEncoder returns a 32 bit integer, SensorValue returns a 16 bit integer and under certain circumstances it may overflow.

I completely agree here. Now if, for some reason, you can’t link your encoder to a motor (ie you have a very strange case) then you could always negate it or write a function or a macro (yes, this again :rolleyes:):

Access encoder value with inverted():

int inverted()
{
  return -SensorValue(pot);
}

Access encoder value with POT_INVERTED :

#define POT_INVERTED (-SensorValue(pot))

@edjubuh

Now I have to ask:

-myVariable

or

myVariable*(-1)

Does it matter? Is there a convention?

Most folks do the first way because it’s prettier and uses less typing. I don’t think it’s a convention or anything though, just more common. They’re otherwise identical.