Trouble Turning in Autonomous

We are trying to turn in our Auto but it will turn a bit until it stalls in one place. We can turn manually just fine in teleop. We even put our motors to 100% power in Auto to turn but it still stalled and made us smoke out one of our Neos. We are using 6 Spark Max’s and 6 Neo’s on a 3 cim gearbox.

Any Suggestions?

Let me know if you need screenshots.
Thanks.

are you guys using PID to make it go to place? if then, how much room of error are you giving? if the room is too tight, it’s not actually stalling but trying to get that exact point before being able to move on to the next step. From what you provide, this is the only thing I can think of. If you want to put your code up or even the video of your robot turning, that would be helpful.

1 Like

We will edit the PID but we also tried straight turning in Auto without PID and it still stalled/Wouldn’t turn.

I will provide Examples later today.

What’s in your periodic tasks?

Given you have 6 Neos in you drive, is it possible you’re inverting the direction of at least one of the motors incorrectly, possibly only in Autonomous? I doubt it’s the cause but maybe something to double check.

2 Likes

+1 to @Jjmase123 comment, to smoke a neo is tough unless they are fighting each other.

Are you able to make the code available for us to see, either through github or here?

Assuming the above is the case, you probably need better encapsulation. Encapsulation is the principle of grouping parts of code together to create a “black box”. This box takes in input, and send out an output, but you don’t get to see the internals. This can be critical for setting something once that you know will work and never having to worry about it again.

The above definition is a vague, so I’ll give this example. Let’s say in code, you are trying to make a drivetrain with 2 motors per side move.

One might go about saying the following in (pseudo) code:
Motor1.set(joystick1.getX)
Motor2.set(joystick1.getX)

This works great for months, and then someone makes a change and accidentally writes the following:
Motor1.set(joystick1.getX)
Motor2.set(joystick1.getY)

This then causes the motors to try to move at different speeds and fight each other.

To prevent this, we can encapsulate our motors within the subsystem.
private motor1
private motor2

public void setPower(double power){
motor1.set(power);
motor2.set(power);
}

This new set up makes it impossible for other classes to arbitrarily set the value of the motors and instead forces them to use the setPower method, which makes sure that both motors are set to the correct power.

Hopefully this can be a help to someone. Feel free to PM me with any questions.

Keep in mind, you’re using a different programming paradigm.

They should be setting up the motors in Begin.vi (or drive controller).
They should be either reading the reference in teleop/auto or using the drive command if they’re using command and control.
There shouldn’t be different motor setups for auton/teleop as a result

Whatever problems exist with inversion of motors should exist with both. They won’t be working with classes.

We definitely want to see the code, though. I suspect they’re doing more than they should in periodic tasks and this is working well in teleop while fighting with other settings in auton.

1 Like

How do you know they are using a different paradigm? I don’t see where it has been specified in the thread what they were using. Even so, does the paradigm matter when it comes to whether one should or should not use encapsulation? If so, what paradigm doesn’t use encapsulation?

Edit: This is not mean to sound rude or snarky, I’m generally interested to know so I can better my explanations for the future.

The OP started this thread in the sub-forum for NI LabVIEW.
The question is about LabVIEW programming.

subforum

The paradigm’s are greatly different.
To get better, teach yourself some LabVIEW.

To get better in general, learn as many unique languages as come your way.

1 Like

It wasn’t taken that way.

As far as the question about encapsulation, I agree with encapsulation in principle. But, it’s important to understand what the target audience is working with.

There are two general styles of projects for LabVIEW programmers (in FRC): Arcade (for lack of a better term) and Command and Control

Command and Control is built on the idea of subsystems and controllers. Here, encapsulation becomes much easier because the controller has complete control of the motors it requires. The motors can only be accessed by calling the API designed to command that controller. This is one of the key reasons I recommend it to teams using LabVIEW (besides the idea this is similar to the MVC architecture that is more beneficial to them beyond the FRC competition).

In Arcade, they have several VIs (methods) to work from: Begin, Finish, Autonomous, Teleop, Periodic Tasks

In this architecture, they initialize the motors in Begin and create a reference to the motor. (Later, they use this reference in Finish to close out the motors) They can access this reference in any of the three other VIs to do things with those motors. If you try to use encapsulation here, you’ll isolate one of the three VIs OR you’ll needlessly initialize/close motors frequently throughout the running of the robot. Many (likely the majority) of LabVIEW teams use this architecture. If we want to move them towards encapsulation, we should be suggesting the Command and Control project instead of the Arcade and helping teach encapsulation that way. We wouldn’t want to complicate the Arcade project.

If you want to chat about these more, feel free to reach out. I don’t want to distract too much from the OP’s request.

@Mark_McLeod Thank you guys for letting me know, I completely missed that it was a lab view question.