REV FRC 2020 Kickoff Updates

Thanks for pointing this out! I’ve commited a fix and we’ll publish an update shortly.

2 Likes

Any update on when the linuxx86-64 binaries are going to be available? And where would they be—should we expect to see them in 1.5.2?

Linux binaries are available now, they were missing from the archive. You can grab them on the web from the maveb location or in the zip file in the same location, 1.5.1

2 Likes

A BIG thank you for these updates, most especially for the USB-CAN bridge/Network tab. I was seriously researching not a few days ago for a viable USB hub to connect all of our SPARK MAX controllers so we didn’t have students trying to wire in a bunch of USB-C cables into the robot or have to plug into controllers individually during competition. This makes training the students and performing the job much easier!

Is there a “blink” function similar to what’s found in Phoenix tuner on the CTRE side?

You also have to import the revrobotics library into your vendordeps if you haven’t done that yet

Yes there is! That feature was included in the latest client release (v 2.1.0)

Please excuse my poor drawing skills

5 Likes

Are you planning to port the 2m distance sensor library to wpilib 2020 ? We failed to use it in our code because it seems it is not up to date with wpilib 2020.

I’m interested in this as well.

We just released some hot fixes to both our LabVIEW APIs and SPARK MAX Client. See below:

LabVIEW API Version 1.5.2

  • Fixes issue with Follow.vi not deploying correctly.

SPARK MAX Client Version 2.1.1

  • Fixes case where some machines did not correctly install the DFU update driver.
  • Fixes driver related issues around firmware updating, especially from versions older than 1.5.0.
  • Improved device recognition and listing on the drop down.

Check for updates on your existing Client’s Help tab or download the update directly through the link above.

We have some additional stability improvements in the works for the Client, but we felt like getting this hot fix out was very important to make it easier for you all to update your older-firmware MAXs.

4 Likes

This is on our backlog, we have filed an issue on github page here

From the spec sheets on the REV color sensor and the REV distance sensor, it appears that both devices use the same address and they are not changeable.

We only have 1 available I2C port on our RIO. Is it possible to use both. Do the REV drivers support multiple devices on 1 bus… If so, I’d buy multiple distance sensors and put them on 1 bus… otherwise, I want a distance sensor that uses an analog input so I can have multiple sensors.

1 Like

There are two i2c busses on the roboRIO. One of them is the port at the top left the other is inside the MXP port on the face. You can directly wire to that or use one of the many breakout boards for the MXP

As I stated, the MXP is occupied by our ADIS chip. Only the 1 i2C bus is available.

The questions was can multiple REV devices be used on the same I2C bus?

SPI and i2c are on different pins in the MXP. A board like the MORE board will allow you to run both.

Since the addresses are the same on devices you can’t run multiple devices on the same bus.

There are i2c multiplex devices on the market that will allow you to run multiple of the same address item on a single bus, but this is not something REV makes.

Thanks… the More board looks like a good option. That would allow us to use one of the distance sensors. I like the breakout; I’d not seen this board.

I wanted to share some fly wheel shooter prototyping that 3005 did using the new SPARK MAX update. We wanted to test the wheel with closed loop PID to maintain a consistent RPM. Instead of programming a roboRIO, or using a drill, or a CIM directly connected to a battery to power the shooter, we used the SPARK MAX controller connected to a battery controlled over USB with client v2.1.1 and firmware v1.5.1. Full closed loop velocity control, no coding necessary.

Here is our control panel:

Using the client we were able to do some basic PID tuning, spin the mechanism up to various RPMs, and plot the change in velocity as we fed in power cells, then export that data to CSV. Here is the excel plot from one such run:

To run this test we did the following:

  1. Connect to the SPARK MAX and select the correct controller from the drop down
  2. To plot the signals on the UI we go to the Run tab, on the left panel select the signals icon, and select signals, then click the + next to the signals you want to add, adjust the range if desired.

  1. Go back to the run tab and select Velocity for the mode, and configure some PID values. For our basic test we simply added kF (feedforward) of 0.000015 and kP of 0.0001 (note the gains are small here due to the default units of RPM being used)

  1. Increase the throttle slowly to verify things are working before running at desired speed
  2. Press stop or ESC to stop the motor
  3. On the top right of the graph click the up arrow to save the CSV file. You can also click the gear on the bottom left to adjust the time scale.

One note about our setup, while using 1 NEO will work, we also wanted to run a second as a follower, inverted from the leader. While we do not currently support this in the UI it is possible to configure it via the ‘Advanced’ tab. To do this we ran quick code on the roboRIO to configure device 7 to follow the inverse of device 1 saved the parameter to flash (motor.burnFlash()). Also make sure you have a terminating resistor somewhere in the CAN chain (100 - 120 ohm resistor between yellow and green wires). In our picture above we just have the two controllers, and a single resistor on one of the CAN ends.

17 Likes

We released an update to the Java/C++ APIs for the Color Sensor V3 that fixes the proximity register issue that you noticed.

Thanks again for reporting it!

1 Like

Glad to help. It’s always interesting what sorts of bugs can be found in code review.

We are trying to do velocity control on the Spark Max and tune the PID. We have oscillation that we are trying to damp out but D gain seems to have no effect on tuning behavior. We have varied it from 10,000 to 0.00001 and behavior is identical for all D gains. Is there a bug? Any ideas what we could be doing wrong?

We are using example code and we are using labview.

P gain is 0.0005 and F gain is 0.00018. We have no I gain and I zone is 0.

The spark max and NEO was from last year.

We just switched to a brand new spark max and NEO from this year and damping now seems to have some effect.

Any idea what the difference might be?