Using Talon Motion Magic with a Potentiometer

Technical
1

Hi, maybe someone can help me out here because I’m a bit stumped.

We have a Pot hooked up to a talon running motion magic on an arm. It works beautifully, but for some reason whenever the robot is powered on the Talon decides that wherever the pot is becomes the 0 value. This sort of defeats the purpose of us using the pot in the first place. Is there a way to have the Talon not zero at all? We just want 0v input to be our 0, at 5v to be our max, and wherever the pot is, is what we read.

Found nothing about it in the documentation, and everyone else seems to be using encoders so I can’t find topics on it. We do have the signal set up in the code as analog.

Thanks for any help!

2

If you’re ensuring the sensor is not wrapping, I would configure it to not be continuous, look here and the API documentation here

In any case, the Talon shouldn’t be zero-ing the sensor on boot if it’s an analog sensor, I would check if you’re setting Sensor Position anywhere in your code, or if you have a limit switch configured to zero the sensor position.

Have you factory Defaulted the talon and done the sensor bring up? Have you performed a Self-Test to compare the raw analog value to the selected sensor position?

3

You can use talon.getSensorCollection.getRawAnalog() to get the position.

Whenever the position gets reset, you can set it to the value you want.

4

Only do this if you know the mechanism is not moving. There’s a slight lag when setting the selected sensor position, so what is set is what was read a few ms ago, causing an inaccuracy if the mechanism is moving.

5

We’ll look into this tonight during our unbag time, I’ll let you know if any of these work.

We did try factory resetting before.

6

This is also generally a bad idea - the data returned by the SensorCollection methods are only updated every 160ms by default.

1 Like
7

Feedback not continues is set to true and it still inits as 0

8

Can you take a self test of the talon using Phoenix Tuner and post it here?

9 
ArmLeft   |   CAN ID is 11

Device NOT ENABLED!
Mode:0:PercentOutput | Output:0.00% [0.00 V]
Motor Leads (Inverted): M+/M- off
Coast during neutral
VCompEn:F CurrLimited:F

PID0 (primary)
Feedback: Analog Pot/Enc
Pos: 1u | Vel: 0u/100ms
Slot Select: 0
Err: 0 u | iacc: 0 u-ms | derr: 0 u/ms

PID1 (aux)
Feedback: Quad/MagEnc(rel)
Pos: 0u | Vel: 0u/100ms
Slot Select: 0
Err: 0 u | iacc: 0 u-ms | derr: 0 u/ms

Quad/MagEnc(rel)
Pos: 0u | Vel: 0u/100ms
Pins: A: 1 | B: 1 | Idx: 1 | IdxEdges:0

Analog: Pos: 523u | Vel: 0u/100ms | ADC:523 | 1.7 V

PulseWidth/MagEnc(abs)
Pos: 0u | Vel: 0u/100ms
Period: 0.0 us
Velocity(if Tachometer): 0 u/100ms | 0.00 RPM

Limit Switches
Forward:Open
Reverse:Open

Auto Zero Position Feature En: LimF = Off | LimR = Off | QuadIdx = Off

    (Fault)         (Now)   (Sticky) 
Reset Dur En :     0          1

Curr:0.00A | Bus: 12.80V | Temp: 22C

FRC Locked:1

“Light Device LED” clears sticky faults.

Build:Feb 15 2019 19:39:58
Press “Refresh” to close.

Here you go, let me know if I missed anything

10

I’m not able to reproduce with the following code:

		_tal.configFactoryDefault();
		_tal.configSelectedFeedbackSensor(FeedbackDevice.Analog);
		_tal.configFeedbackNotContinuous(true, 10);

		_tal.setSelectedSensorPosition(0); //Not needed, but doesn't affect outcome

Could you also post a screenshot of the config screen? Specifically with the advanced sensor and meas, closed loop, hardware limit switches, and home sensor tabs open like below? You can right-click collapse all and open just the ones we care about to make it easier.

image
image1906×713 26.7 KB

11

We got it working thank you! My programmer wanted to let you know “you are the GOAT”.

1 Like
12

What Solution did you find? I was going to ask if you copied the Phoenix then I know they have in their code during the initializing of the object.

/* Zero the sensor */
_talon.setSelectedSensorPosition(0, Constants.kPIDLoopIdx, Constants.kTimeoutMs);
13

We copied the 3 lines tytanrock provided. Something about how our code was setting it up was incorrect

14

Doesn’t this line zero the feedback? I would think this would NEED to be omitted to keep an Analog Feedback device from reporting zero

15

In the case that you configFeedbackNotContinuous, it will ignore any software-set sensor position if using Analog or PWM and will rely solely on the raw sensor and the sensor phasing you set.

Based on this it sounds like Brandon was configuring the sensor to be not continuous at some point, but later un-configured it. That’s why I asked for the screenshot of the configs to confirm this.

16

Well then good to know. It is almost like configFeedbackNotContinuous(true) should be default if the selected feedback device is set to analog.

1 Like
17

That change would have saved us a couple days last month.

18

@ozrien Why is this not a thing? What are we missing as for why not?

19

Behavior Symptoms

I want to emphasize that on boot, an analog or pulse-width sensor will initialize to the absolute value being read from the Talon data port regardless of the FeedbackNotContinuous config. These sensor values do not initialize to 0 unless you explicitly set them to 0 in code.

If your absolute sensor value is being set to 0 when the physical setup/connection of your sensor is good, one of two things is happening:

  1. SetSelectedSensorPosition(0) is being called OR
  2. Talon is configured for clearPosOnLimR/LimF/Idx and your physical switch is being asserted.

Setting configFeedbackNotContinuous(true) isn’t intended to “solve” this problem, but it can be used as a workaround in the event the root cause for (1) or (2) above isn’t determined for whatever reason.

I cannot emphasize this enough - Using FeedbackNotContinuous(true) to solve a sensor zeroing problem is a workaround that masks the problem, NOT a solution to the root-cause. This may be acceptable for your use case, but I want to be clear about what’s causing the behavior you’re seeing.

Default Value

FeedbackNotContinuous being False by default is a significant benefit in the vast majority of cases, and this default value is documented here: https://phoenix-documentation.readthedocs.io/en/latest/ch14_MCSensor.html#analog-potentiometer-or-encoder.

If your mechanism stays within one rotation of the sensor during your movement, then wrapping/not wrapping doesn’t matter. The behavior is the same unless you’re explicitly zeroing the sensor as described above, which you should only be doing if that behavior is desired.

If your mechanism’s range of motion requires multiple rotations of the sensor, most of the time the desired behavior is to have a single range of sensor values for the entire range of motion (ie using an analog encoder, an infinite-turn potentiometer, pulse-width from a CTRE mag encoder, etc).
There are exceptions to this, such as absolute sensors with swerve module angles, but in that case you’re making a conscious decision to turn of wrap-counting.

1 Like
20

Because if you are using an MA3 for continuous motion, like a drive-train, you want it false. I’m not sure how common this is now since CTRE Mag Encoder and changes in latest COTS gearboxes.

That settings also influences position-pulse-width-encoded signals in the same way. If you are using a pulse-width sensor for continuous motion, you also want it false.

I’m not against discussing it on a GitHub issue tracker, perhaps the default could change in 2020, but that has to be weighed against how it impacts teams that rely on it being default set to ‘false’ .