FTCLib / FTCLib

Broad FTC library for all things software.
https://ftclib.org/
Other
187 stars 83 forks source link

Add Current and Voltage Hardware Utilities #145

Open JIceberg opened 3 years ago

JIceberg commented 3 years ago

I think something interesting we could add is features working with VoltageSensor and the "new" (since 5.4, I guess) getCurrent() feature of LynxModule, along with other "buried" features in the SDK. I think that would be an interesting feature for us to implement and could lead to some cool stuff similar in scope to re2.

puravdatta-sudo commented 3 years ago

We should add a motor.isStalled boolean to check if an implement is blocked and such, it can be done with the current going to the motor relatively simply.

JIceberg commented 3 years ago

We should add a motor.isStalled boolean to check if an implement is blocked and such, it can be done with the current going to the motor relatively simply.

Would have to test that with the SDK stuff. We have to see if getCurrent(CurrentUtil) on DcMotorEx will actually change to the stall current if the motor is stalling. It has to be something we can track within a tolerance.

puravdatta-sudo commented 3 years ago

Agreed

On Wed, Jan 13, 2021 at 11:05 AM Jackson Isenberg notifications@github.com wrote:

We should add a motor.isStalled boolean to check if an implement is blocked and such, it can be done with the current going to the motor relatively simply.

Would have to test that with the SDK stuff. We have to see if getCurrent(CurrentUtil) on DcMotorEx will actually change to the stall current if the motor is stalling. It has to be something we can track within a tolerance.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/FTCLib/FTCLib/issues/145#issuecomment-759587991, or unsubscribe https://github.com/notifications/unsubscribe-auth/AO3BXKARS5YHUDEVFT6JW4TSZXHHBANCNFSM4U5BEJKQ .

-- Purav Datta Lead Software Engineer

14614

JIceberg commented 3 years ago

image

Something that might be useful? We can set an alert. Apparently this information can also be bulk read, so we might want to add this to the new motor groups as well (#164)

puravdatta-sudo commented 3 years ago

can this run in a separate thread with a callback or is this thread locked? because I think RTP is blocking and if its jammed it would block the thread. Correct me if I'm wrong.

JIceberg commented 3 years ago

can this run in a separate thread with a callback or is this thread locked? because I think RTP is blocking and if its jammed it would block the thread. Correct me if I'm wrong.

Luckily for us, we run our own RTP and keep the motor in RUN_WITHOUT_ENCODER, so that shouldn't be a problem.

puravdatta-sudo commented 3 years ago

shouldn't be a problem.

famous last words

JIceberg commented 3 years ago

shouldn't be a problem.

famous last words

yikes. We can probably (for MotorEx, since this a DcMotorEx feaure), do something like

private Runnable onStall = () -> motorEx.setPower(0);
public void onStall(@NonNull Runnable action) {
  onStall = action;
}

public void set(double output) {
  if (isStalled()) {
    onStall.run();
    return;
  }
  ... // here and below is the actual set power routine
}
JIceberg commented 3 years ago

Actually, I'm not sure how we would specify onStall. Because typically the user might want to run the motor some other way, but if they call set, that creates infinite recursion. I think a different solution is needed.

JIceberg commented 3 years ago

Maybe we just have it stop the motor if it stalls.

public void set (double output) {
  if (isStalled()) {
    motorEx.setPower(0);
    return;
  }
  ...
}

And print something to the logs?

puravdatta-sudo commented 3 years ago

IDK if that should be a default behavior, ex: when we were lifting in RR2, I think we stalled the motor and there was a significant current draw but if it stops there, the robot drops. it should be configurable.

JIceberg commented 3 years ago

IDK if that should be a default behavior, ex: when we were lifting in RR2, I think we stalled the motor and there was a significant current draw but if it stops there, the robot drops. it should be configurable.

Yeah that's a good point. Is there any way to check if a lambda refers to a specific function? I'd rather have it throw an IllegalArgumentException that says "Cannot call set() while the motor is stalled. As an alternative, try calling .motorEx.setPower() with the internal DcMotorEx object." when the user tries to specify an action that could cause stack overflow and crash the program.

NoahBres commented 3 years ago

Why don't you just leave such protections as an opt-in flag. Maybe one day it can become the default but leaving it on by default would be confusing to many people. Just default off, simple toggle, and if you see a non-trivial population making use of it then enable it by default.

JIceberg commented 3 years ago

Why don't you just leave such protections as an opt-in flag. Maybe one day it can become the default but leaving it on by default would be confusing to many people. Just default off, simple toggle, and if you see a non-trivial population making use of it then enable it by default.

So encase it in a flag? Like,

public void set(double output) {
  if (stallProtectionFlag && isStalled()) {
    onStall.run();
    return;
  }
  ...
}

And have stallProtectionFlag be switchable but false by default?

puravdatta-sudo commented 3 years ago

That makes sense

NoahAndrews commented 3 years ago

can this run in a separate thread with a callback or is this thread locked? because I think RTP is blocking and if its jammed it would block the thread. Correct me if I'm wrong.

Just for the record, RTP is not blocking. You can use it as a set-and-forget way to keep a motor in a particular position.

JIceberg commented 3 years ago

can this run in a separate thread with a callback or is this thread locked? because I think RTP is blocking and if its jammed it would block the thread. Correct me if I'm wrong.

Just for the record, RTP is not blocking. You can use it as a set-and-forget way to keep a motor in a particular position.

Yeah afaik it runs on the board separate from the SDK stuff. Correct me if I'm wrong.

serivesmejia commented 3 years ago

can this run in a separate thread with a callback or is this thread locked? because I think RTP is blocking and if its jammed it would block the thread. Correct me if I'm wrong.

Just for the record, RTP is not blocking. You can use it as a set-and-forget way to keep a motor in a particular position.

Yeah afaik it runs on the board separate from the SDK stuff. Correct me if I'm wrong.

Yup, apparently it does

Also this

Didn't knew RTP was also ran on the hub, cool!

JIceberg commented 3 years ago

Idea: add some sort of RevHub class that will have both the integrated RevIMU and some current/voltage utilities. This might be useful for checking for brown-outs or ensuring the current draw for any one device never exceeds a specified threshold.

What do y'all think?

puravdatta-sudo commented 3 years ago

That would be cool except that if u brown out, everything restarts so you wouldn’t be able to detect it and it wouldn’t make too much of a difference.

On Thu, Feb 25, 2021 at 12:39 AM Jackson Isenberg notifications@github.com wrote:

Idea: add some sort of RevHub class that will have both the integrated RevIMU and some current/voltage utilities. This might be useful for checking for brown-outs or ensuring the current draw for any one device never exceeds a specified threshold.

What do y'all think?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/FTCLib/FTCLib/issues/145#issuecomment-785655786, or unsubscribe https://github.com/notifications/unsubscribe-auth/AO3BXKDJBW4FRKBTQ6SA2UTTAXWCLANCNFSM4U5BEJKQ .

-- Purav Datta Lead Software Engineer

14614

NoahAndrews commented 3 years ago

That would be cool except that if u brown out, everything restarts so you wouldn’t be able to detect it

If an Expansion Hub restarts, that gets detected here: https://github.com/OpenFTC/Extracted-RC/blob/f47d6f15fa1b59faaf509a522e0ec04f223ec125/Hardware/src/main/java/com/qualcomm/hardware/lynx/LynxModule.java#L505-L509

JIceberg commented 3 years ago

That would be cool except that if u brown out, everything restarts so you wouldn’t be able to detect it

If an Expansion Hub restarts, that gets detected here: https://github.com/OpenFTC/Extracted-RC/blob/f47d6f15fa1b59faaf509a522e0ec04f223ec125/Hardware/src/main/java/com/qualcomm/hardware/lynx/LynxModule.java#L505-L509

Definitely going to be using this in the feature. So simply, we can just send a LynxGetModuleStatusCommand and check the response to see if it's been reset. I'm not sure how to actually make this useful on the user-end, but it could be neat for some custom logging.

NoahAndrews commented 3 years ago

That would be cool except that if u brown out, everything restarts so you wouldn’t be able to detect it

If an Expansion Hub restarts, that gets detected here: OpenFTC/Extracted-RC@f47d6f1/Hardware/src/main/java/com/qualcomm/hardware/lynx/LynxModule.java#L505-L509

Definitely going to be using this in the feature. So simply, we can just send a LynxGetModuleStatusCommand and check the response to see if it's been reset. I'm not sure how to actually make this useful on the user-end, but it could be neat for some custom logging.

@JIceberg If you end up doing this, make sure that you set clearStatusAfterResponse to false, or else you'll prevent the SDK from getting the current status of the hub.

It's also important to note that if the SDK beats you to the status request, you'll come up empty, since the SDK has clearStatusAfterResponse set to true when it performs status requests.

Honestly, a much better way of doing this would be a new API in the SDK that calls a callback whenever a hub has a non-empty module status. That way both FTCLib and the SDK would be guaranteed not to miss out on any module status events. If that's something you'd like us to add, please file an issue on the main FtcRobotController repo.

NoahAndrews commented 3 years ago

@JIceberg By the way, if all you're planning to use this for is logging, that shouldn't be necessary. The SDK already logs interesting module statuses. See all of LynxModuleWarningManager. If/when you make the issue, please present at least one specific use-case for exposing this data to users and 3rd-party libraries.