For power up two years ago our team used a replay file autonomous that wrote motor values of the talons to a file and replayed it in the game. It worked super fast however motor percentages could only be recorded, so when there was a motor change the robot would loose a small degree of accuracy. Knowing that many other teams do a method similar to this for autonomous is there a way to pass in a fixed voltage to TalonSRX?
Just what I was looking for thanks!
Will that actually fix the problem?
Isn’t the core source of the problem the inherent differences from one motor to another when running at a specific voltage? It would seem you’re counting on identical motor performance at a specific voltage which isn’t guaranteed (as you’ve already seen).
Sounds like what you really want is to replicate the motor / mechanism speeds which would really be driven by sensor readings unless I’m not understanding the question…
– Chris Herzog - 4241 Joliet Cyborgs
This might be because you were using WPI_TalonSRX which implements SpeedController. The set method on a WPI_TalonSRX (inherited from SpeedController) uses the PercentOutput. If you wanted to be able to use a SpeedController with a TalonSRX and set voltage instead of percent output, I recommend creating your own class that inherits Sendable.
In that class, you could have this code in your initSendable where
builder.setSmartDashboardType("Speed Controller");
builder.setSafeState(this::stopMotor);
builder.addDoubleProperty("Value", this::get, this::set);
You could replace the stopMotor, get, and set method references with something else.
This might not be what you’re asking for, but feel free to ask more questions if you want to try something like this.
Yeah what I want to do is replicate exact movement of the robot. There’s two ways to record it, either I get values from the talons or I re-plug in joystick values to the drive train. The problem with is before is sometimes during voltage shifts the robot would shoot forward and miss its mark, so I’ve chalked up this to voltage unless there is another way to fix it?
Yeah I’m recreating it for this year am I’m using just bare TalonSRX not WPI_TalonSRX where I need to input the ControlMode. Is changing the ControlMode what you mean? But the old one from PowerUp used WPI_TalonSRX.
So I think what you might be missing here is that you should really not be writing autonomous commands for a drivetrain by telling a motor to run for a specified amount of time. You can use voltage compensation to get a more repeatable result, but you can get a much, much, much better result using closed loop speed control. You would need some sort of sensor to detect how much each side of the drive turns, such as an encoder. This sensor gets fed into the loop, ensuring your drive moves a precise distance and/or speed. Luckily the Talon SRX is great for implementing exactly this kind of speed control.
So yes, I was thinking that there existed a ControlMode to set the raw voltage, but now I see that it doesn’t exist. I’m unfamiliar with voltage compensation, but the other suggestions about that seem to be reasonable.
What I was also trying to show was that if you want to use a different ControlMode than PercentOutput and you wanted to see the values of that show up in Shuffleboard, creating your own Sendable would be a viable option.
Use someone else’s suggestion about doing voltage stuff, but I’m pretty familiar with Sendable code so if you want to record values of something other than PercentOutput, I can try to explain creating your own Sendable class.
The problem I’m trying to fix is in this video. We are the robot in the bottom left. We were able to score but if you can see the target was overshot a lot from the initial recording and we lost points to penalties. https://www.youtube.com/watch?v=KQ88x2wiktQ&list=PLxusbDuuwWJIv0uFDOqsTvJ7UZVQXcW39&index=89
So to be clear, your recommending recording encoder values rather than direct talon values?
Ok, I think I misunderstood what you were asking. So you can ignore my suggestions about Sendable stuff.
What you need are encoders. From what I understand, you don’t have closed loop control. Are you running your motors for a set amount of time? If yes, you need to rethink your strategy for autonomous code. Setting the speed of a motor for a certain amount of time works well for crossing a line, but when you need to go a certain distance, it’s almost guaranteed to over or under shoot each time.
Does that answer your question? Do you have encoders on the wheels of the robot?
I’m recommending not using a “record values you get in teleop” style autonomous mode at all if you can help it, though if that’s all you can do / know how to do and you’re in a time crunch, it’s a start.
You can create a very simple closed loop autonomous mode to follow a specified path by using an encoder driven control loop for the straight portions, and a gyro driven control loop to turn in place. There are far more advanced things you can do beyond this, but this is really the minimum for a “works basically every time” autonomous mode.
Alright, I looked more into doing it this approach. Unfortunately my team does not have encoders on our drive train, so I’ll get them on it soon thanks!
For more advanced pathing I’d recommend looking here: https://docs.wpilib.org/en/latest/docs/software/wpilib-tools/path-planning/index.html
This type of algorithm has been difficult to implement in years past but now it is much more accessible.
I’ll have to get encoders wired to the robot this year, but I’ll start working on this thanks a ton!
There was a team last year I talked to who used path finding for their autonomous and they talked about PID on the wheels. Is PID a necessity for this type of autonomous?
Yes, PID is pretty much the only surefire way to get consistent results over multiple runs of an auto. You can use it with the new trajectory API, or with just encoders as mentioned earlier:
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.