wpilibsuite / frc-characterization Goto Github PK

Hi, I am starting to do motion profiling for my team, 4338, and I just didn't know how I would refer to the SparkMaxes in the config editor by their CAN id's. We have a six wheel drive with 6 SparkMaxes and didn't decide to use them through PWM. I assumed the default values when I created a brushless max project are for PWM, so it's for the best that I ask.

See title

We currently don't have any unit tests verifying the model. Once #27 is merged, we'll also need unit tests to verify the general case tends to that model for ka -> 0.

Installed via pip3
I get the following error: Unable to revert mtime: /Library/Fonts when running frc-characterization drive new
This is how it renders:

On the readme:

All list values must be lists, even if they have only one element. Do not omit trailing commas (e.g. in (False,)), as this will cause them not to be parsed as a list

Strictly speaking, things surrounded with parentheses are tuples, lists are surrounded by brackets. I tend to use tuples to denote things as immutable, but often lists and tuples are interchangeable.

Why does this matter? Well, [False] is a valid list even without a trailing comma, and so it's a lot harder to mess up. I recommend changing the documentation to use lists (brackets) instead of tuples (parentheses).

I really like this methodology for controlling the robot over networktables... it allows the hard logic to be written once for all languages, and simple code can be ran on the robot side. There are probably other useful ways we can use this methodology to help teams control their robot better.

One thing I'm very interested in is measuring information that would allow us to simulate drivetrain turning better.

Other things that could be done are automated programs to compute feed-forward such as in the TalonSRX user manual.

Perhaps utilities for tuning a robot too?

Some teams use potentiometers on their arms instead of encoders. We should support this configuration.

Also, projects need to be updated for 2019. I'm expecting a PR to come in from someone who emailed me about these.

Might be useful, might not. If a number of people use it, could be worth the effort.

If we know the sensor delay, we can use equation (11) from https://www.textroad.com/pdf/JBASR/J.%20Basic.%20Appl.%20Sci.%20Res.,%202(3)2607-2618,%202012.pdf to correct the controller gain to compensate for the delay. The following figures are for an elevator model running with 5ms updates and 50ms of input lag (input lag is a mathematical dual of measurement lag). The first figure is the LQR without delay compensation.

The second figure is the LQR with delay compensation.

The continuous time, infinite horizon LQR is defined as u = -R^-1 B^T P x. Based on equation (11), the corrected equation should be u = -R^-1 B^T P e^(A - B R^-1 B^T P) x. (Note that equation (11) has a typo of P^-1 when they meant R^-1.)

For the discrete control law u_k = -K x_k, making the controller gain K e^(A - B R^-1 B^T P) instead of K gave the second figure above where A, B, P, and R are from the continuous model and P is from solving the continuous ARE. Here's my python code using frccontrol that's run once after the initial K is computed:

        Q = np.diag(1.0 / np.square([0.02, 0.4]))
        R = np.diag(1.0 / np.square([12.0]))
        P = sp.linalg.solve_continuous_are(a=self.sysc.A, b=self.sysc.B, q=Q, r=R)
        self.K = self.K @ sp.linalg.expm((self.sysc.A - self.sysc.B @ np.linalg.pinv(R) @ self.sysc.B.T @ P) * sensor_delay_in_seconds)

data_analyzer.py doesn't have access to the type of feedback controller used (CTRE/REV onboard PID vs WPILib PID), so we'll need to refactor things so the tool can selectively apply this controller gain correction automatically.

Our team tried to do robot characterization with Spark Maxes. It automatically set the motors to brushed and burned half of our drive train out. There is no way to tell if a motor is brushed or brushless with robot characterization without looking at the code itself. Could you please add an option to the robot characterization tool to specify what mode the motors are supposed to be in.

If you do characterization for the linear case and turning in place, J = ka_angular / ka_linear. I'm not sure what the unit of mass would be (units of J are kg-m^2 in SI).

Based on the SparkMax API docs, inverting a follower must be done by .follow(leader, isInverted) and not by .setInverted(isInverted) (that has no effect!).
The arm and elevator templates are incorrect and don't invert follower motors.

This will better capture acceleration dynamics, resulting in a better fit for K_a.

Hello,
I created a new brushless Spark Max/Neo project. After running a test, it reported the left and right encoder ticks. It then said, "If that seems wrong, you should change the encoder calibration in the robot program or fix your encoders!" I then changed Robot.java in the generated project to report in meters.

After running the tests again and getting satisfactory results of about three meters, I then opened the analyzer program and got the attached error:

I think the error is occurring because it expects numbers that haven't been adjusted for encoder ticks. I don't want to re-run the characterization program.

Is there any way to tell the GUI that it doesn't need to convert the data it's received? Or alternatively, can I easily convert the data to something the analyzer can use?

I have characterization data that I'm trying to analyze on my Mac. The Analyze Data works fine, however click any of the Diagnostic buttons crashes the app. Here is a sample stack trace

`2020-01-18 13:49:26.787 python3.7[52433:6406129] WARNING: <NSOpenPanel: 0x7fc19cb068c0> running implicitly; please run panels using NSSavePanel rather than NSApplication.
Fatal Python error: PyEval_RestoreThread: NULL tstate

Current thread 0x000000010aca5dc0 (most recent call first):
File "/Users/dole/.virtualenvs/py3/lib/python3.7/site-packages/matplotlib/backends/backend_macosx.py", line 193 in mainloop
File "/Users/dole/.virtualenvs/py3/lib/python3.7/site-packages/matplotlib/backend_bases.py", line 3309 in show
File "/Users/dole/.virtualenvs/py3/lib/python3.7/site-packages/matplotlib/cbook/deprecation.py", line 413 in wrapper
File "/Users/dole/.virtualenvs/py3/lib/python3.7/site-packages/matplotlib/pyplot.py", line 269 in show
File "/Users/dole/.virtualenvs/py3/lib/python3.7/site-packages/frc_characterization/drive_characterization/data_analyzer.py", line 1173 in _plotVoltageDomain
File "/Users/dole/.virtualenvs/py3/lib/python3.7/site-packages/frc_characterization/drive_characterization/data_analyzer.py", line 377 in plotVoltageDomain
File "/usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/tkinter/init.py", line 1705 in call
File "/usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/tkinter/init.py", line 1283 in mainloop
File "/Users/dole/.virtualenvs/py3/lib/python3.7/site-packages/frc_characterization/drive_characterization/data_analyzer.py", line 1312 in main
File "/Users/dole/.virtualenvs/py3/lib/python3.7/site-packages/frc_characterization/cli/init.py", line 41 in analyzerDrive
File "/Users/dole/.virtualenvs/py3/lib/python3.7/site-packages/frc_characterization/cli/init.py", line 90 in main
File "/Users/dole/.virtualenvs/py3/bin/frc-characterization", line 8 in
Abort trap: 6`

On macOS, when system-wide dark mode is enabled, all button labels have invisible text as seen here:

When buttons are clicked, the text is visible in white:

With dark mode disabled, the buttons appear normal.

I'm not sure where this project fits in the WPILib realm in terms of support/official-itly. If it is fully official, then I think it would be great if the characterization tool could be launched (and installed) as part of the VS code extension (WPILib --> Start Tool --> RobotCharacterization). I think this would increase the ease of installation quite a bit (as it would be automatic).

Windows kept wanting to kill this "unresponsive" process. The deploy should preferably be on a separate thread.

When using a NavX as the gyroscope connected via USB, the tool doesn’t generate code that imports SerialPort.

Generated projects should only use the vendordeps that it needs. It's not really feasible to expect every team to have vendor setups installed locally for things they don't use. Deleting the offending vendordep is a workaround, but not a solution

See: CrossTheRoadElec/Phoenix-api#68

Or else amber lights on slave will occur and there will be no movement.

Tested on our x4 Falcon drivetrain. Default generated project doesn't work. When motor safety was disabled by manually going into Java code it worked.

The project that is generated for the Talon project type has an error in Robot.java. robotInit() creates local leftMaster and rightMaster objects instead of using the global variables with the same name, which causes a NullPointerException in autonomousPeriodic().

I tried using this with Python 3.6 and ran into an issue with importlib.resources not being found.
I then updated to Python 3.8 and had problems installing robotpy-characterization.
3.7 seems to be the Goldilocks version, though the docs say 3.6 and greater.

It's some kind of math problem... unfortunately I don't really know why, and I don't have time to look further this weekend.

These are all nits, but some thoughts I had while using the program.

1. Move Wheel Diameter into feedback section. Having it at the top implies it used in both feedforward and feedback, but in reality, it only affects feedback values.

2. Have the units entry dynamically change the default values for "Motion Threshold", "Max Acceptable Position Error", "Max Acceptable Velocity Error" to be values you have deemed good in the past. For example, when we did our characterization in meters, we set our Motion Threshold to 0.006096 meters (taken by converting the 0.02 feet shown in the README). This should be done automatically. Additionally, changing the units should also update the labels (e.g. if set to feet, we should get a label Motion Threshold (feet/s)

3. I don't think the Analyze Data button needs to exists. The data should be analyzed implicitly if anything that affects the analysis has changed (e.g. new file loaded, Motion Threshold changed, etc...). I know I got stuck wondering why the graphs didn't change after I changed the Motion Threshold and it was because I didn't re-analyze.

There have been multiple issues in the FRC discord with the program failing to deploy because it is using the global (therefore wrong) version of Java.

This tool should use the JDK that is installed with WPILib as opposed to the global version of Java, installed at WPILib/xxxx/jdk. It should preferably be configurable by default to WPILib's included version.

This would use the velocity-only drivetrain model, but with only one set of motors.

Our team doesn't want to use talons SRX this year to conserve space with the new Falcon 500 motors, so we opted for CANCoders instead for greater precision over the built in falcon 500 encoders. I tried changing the code in Robot.java to read from the CANCoders for the characterization data logger since the it defaults to reading from encoders being plugged into a Talon SRX. However, the robot ended up not moving at all when I tried running the Quasistatic forward process in Autonomous mode and the data logger didn't stop the Quasistatic forward process when I disabled the Autonomous mode. The robot did move when we tested the default code, without making any changes to the default encoder code.

Here's the code we wrote to use values from the CANCoder instead:
leftEncoder = new CANCoder (13);
rightEncoder = new CANCoder (12);
leftEncoderPosition = () -> leftEncoder.getPosition()*encoderConstant;
leftEncoderRate = () -> leftEncoder.getVelocity()*encoderConstant*10;
rightEncoderPosition = () -> rightEncoder.getPosition()*encoderConstant;
rightEncoderRate = () -> rightEncoder.getVelocity()*encoderConstant*10;

This year, REV added support for external encoders in brushless mode but in the Data Analyzer, the "Post-Encoder Gearing" and "Encoder EPR" text fields (which of course influence the calculated kP and kD) are only editable when the Controller Type is set to "Talon" and not for "Spark".

From looking in the code briefly, it seems like the Talon gain analysis works exactly like the Spark Max's analysis, except with Post-Encoder Gearing and Encoder EPR taken into account. Am I right on this?

If I am, it would be awesome to have the "Spark" Controller Type work with the two aforementioned fields, just like with "Talon", and I'd be happy to create a PR for a small change like this.

Would it be possible to choose weather you want to use wheel diameter or measured distance per pulse, using wheel diameter creates issues with inconsistent wheel sizing and assumptions about gear ratios. I think if you had a field for distance per pulse or pulses per distance you could then use the tuner and get encoder clicks and measure how far you moved it and come up with a better representation.

I was trying this tool on my MacBook Air 13 inch, which has a screen resolution of 1440x900. This became an issue when I came to the analyze data screen, where about half of the rightmost section was cut off(with the PID type select).

Whenever we try to characterize our robot now, we get this error.

NT: connect() to 172.22.11.2 port 1735 timed out
Exception in Tkinter callback
Traceback (most recent call last):
  File "C:\Users\6517\AppData\Local\Programs\Python\Python38\lib\tkinter\__init__.py", line 1883, in __call__
    return self.func(*args)
  File "C:\Users\6517\AppData\Local\Programs\Python\Python38\lib\site-packages\frc_characterization\logger_gui\__init__.py", line 101, in connect
    NetworkTables.addConnectionListener(
TypeError: addConnectionListener(): incompatible function arguments. The following argument types are supported:
    1. (self: _pyntcore._ntcore.NetworkTablesInstance, callback: Callable[[_pyntcore._ntcore.ConnectionNotification], None], immediate_notify: bool) -> int

Invoked with: <_pyntcore._ntcore.NetworkTablesInstance object at 0x000002CCA7512870>, <bound method TestRunner.connectionListener of <frc_characterization.drive_characterization.data_logger.TestRunner object at 0x000002CCA75B3F40>>; kwargs: immediateNotify=True

We had characterized our bot several times before, and then this randomly shows up. Our PyFRC is up to date. Is there anything else we can do?

The Spark MAX's exhibited weird behavior (not inverting at all, regardless of true or false) along with odd follower behavior before calling factory reset on them.

The build template files need to be updated for 2020.

Per the CD thread here - https://www.chiefdelphi.com/t/network-table-speed/368462, it looks like the preferred way to force NT to update more quickly is to use the .flush() method rather than setting the update rate.
The various template robot code snippets all seem to use setUpdateRate().
To line up with the method recommended in the linked thread, those calls should be removed and replaced with a .flush() call inside the generated autonomousPeriodic method.

I suspect getFusedHeading() would be better for getting the current heading, for example.

And if they are already useful... add some description somewhere talking about what they mean. They don't seem particularly meaningful to me at the moment.

        with open(fname, 'w') as fp:
            json.dump(stored_data, fp, indent=4, separators=(',', ': '))

Should be self.stored_data. There are several places where this is the case.

Probably would be best to prompt the user for it when logging, and then add the data to the JSON so it can compute things like efficiency et al.

To make it less annoying, could store default parameters in a file when starting, and load those so you just have to hit enter.

Might be useful for someone.

It has been superseded by frc-characterization.

Project will not deploy with WPILib update (2020.2.2) - error message indicates it is looking for the older version of the library

Most users seem to be using the new Ramsete command/controller included this year. The default option when analyzing collected data should probably be velocity mode. I’ve seen a few conversations about invalid gains because of folks assuming the position gains will work.