Another season has come so its time for an update from your friends at REV Robotics. This year we don’t have a full thread of shiny new products or motors for you, but there are some big updates that we wanted to share.
REV Hardware Client now supports SPARK Max
In 2020, we released a new piece of software called the REV Hardware Client that was launched for our FTC control system items, I am now excited to share a bit more about this software for FRC. This software will be our one-stop place for all of REV hardware moving forward. It does lots of neat things like updating your device firmware, installing the right APIs, live logging, motor control, and even direct support requests to REV. In the future as we release new products, like the 2022 FRC Control system parts, they will also live in the hardware client.
Note - The stand alone SPARK Max client will still function through 2021, but will receive no more updates.
Ultraplanetary 1/2in Hex Adapter - We launched it a while ago, but it might be useful for teams who would like to use the Ultraplanetary Gearbox on their FRC robotics as it makes interacting with standard FRC products a bit easier
We have several new products that will be released when they are ready, several of them in the next couple weeks. I will update this thread as things are available.
2022 FRC Control system components are still under testing and we are planning on releasing more information about them in them in the early part of this year.
Any info on the simulation stuff? I versions and I see things showing up as a SimDevice in the hal gui, but setting things programmatically doesn’t seem to do anything. It does look like changing the value in the gui does get reflected when calling get() / getAppliedOutput(). Do we have to do everything manually?
The schema for your sim device doesn’t match the WebSocket Format, which would be super nice. At the very least I would prepend it with RevMotor: if you don’t want to follow CTRE’s naming convention
See this for info on interacting with the sim data. You can get the "Applied Output"SimDouble/field and set it that way as a workaround. @Will_Toth - it would seem that CANSparkMaxJNI.c_SparkMax_SetpointCommand doesn’t write the output to the simulation objects. I suppose this is a bug. Do you want me to send a bug report to email support? The above workaround can be used until a fix is released. TIA.
Thanks for the report, we’re looking into this. We plan to add some better methods to expose the internal state (instead of using the SimDeviceSim), some examples, which will make usage clear, and some documentation to our new documentation site
REV just announced an launched a few new additions to our product line for both FRC and FTC teams.
Compliant wheels - https://www.revrobotics.com/2in-compliant-wheel-0in5-hex-bore/ We are adding a product that we think fills a void in the compliant wheel space with a 2inch wheel with a plastic core. This makes it easier to ensure power transfer to the game piece of your choice as it won’t slip on the shaft. They are available in 3 durometers.
NEO/ CIM pinions - NEO Pinions - REV Robotics A full lineup of pinions for NEO or CIM shaft motors feature gears on a 12tooth pitch (10,11, 12) or a 14 tooth pitch( 13, 14), a GT2 pulley, and even one for # 25 chain. We also have a 8mm to 1/2 hex adapter 8mm to 1/2in Hex Adapter - REV Robotics
V2 UltraPlanetary output - UltraPlanetary Female 5mm Hex Output V2 - REV Robotics We upgraded the output for the UltraPlanetary to make it easier to control the manufacturing tolerances that would potentially lead to some issues users saw. As part of this redesign it also makes it possible and easier for teams to fabricate their own output types as the spline is now separated from the hex hole. All UltraPlanetary kits shipping from this point forward have the V2 output and the V2 is backwards compatible with all previous stages and gearboxes sold.
Here is a side by side cross section showing the difference
Digital LED indicator -Digital LED Indicator - Red/Green - 4 Pack - REV Robotics Simple controllable LED indicator can be plugged into any digital port on the Control or Expansion hubs to give you a bit of easy feedback for drivers or programmers as you debug your robot.
Orange OTG cable - USB Female A to Micro USB Adapter - Orange - REV Robotics We found that quality of OTG cables used by FTC teams varied widely. Because this is such a critical part of your robot, we made our own to ensure quality. The orange color is because…well…we like orange.
550 Motor pinions (NEO550 and HD Hex motor) - 550 Motor Pinions - REV Robotics We have added a few direct pinions for 550 sized motors to work with 32DP gears, GT2 Belts and the UltraPlanetary for supporting any type of 550 motor attaching to the gearbox.
We continue to recognize that this season is strange, but we will keep working to make cool things for teams so that when everything returns to normal robotics is more exciting than ever!
On the flex wheels, what is your expectation on the directional cutouts’ impact on intake performance? Have you done any testing to validate that this performs differently or better than symmetrical cutouts like we have seen on other flex wheels?
There isn’t much difference in the direction really. The direction opposite of the cutout’s direction will be a bit choppier but overall the compliance of the wheel is pretty equal in both directions. Doing the directional cutout is what helped allow for the plastic core, and after we did some testing we feel as though the ability of the wheel to be effectively compliant has not suffered.
To echo what Nick said. We like the directional cut outs because it does make the motion a bit more consistent when you are spinning inwards in the cut out direction. When spinning the opposite direction they are a bit more comparable to existing compliant wheels with a minor bump. When prototyping, we liked the performance with the directional cut outs, but it really will depend on your application if you see a significant impact on your robot.
The biggest improvement with these vs others on the market is the plastic hub so they won’t ever slip on the shaft or have the outer profile deform due to stretching over an undersized hole
In 2018, we used 4" compliant wheels with plastic hubs for our intake. We had inadvertently used 1/2" Thunderhex shaft for the driving shaft. Although this was not the design intent, we really didn’t know that we needed to discriminate between standard 1/2" Hex shaft and 1/2" Thunderhex, so no one had bothered to check which style shaft had been used.
Throughout the season, we broke many of the compliant wheels. The failure mode was that the plastic hub split in half (cracks starting at the points of the hex bore radiating outward to the rim of the hub). Once the crack had split the hub in half, the compliant wheel would spin on the shaft and the intake would stop working.
We traced the root cause of this failure to the fact that the corners of the Thunderhex shaft are rounded off which allows the shaft to rotate in the bore if enough torque is applied. The plastic bore was compliant enough to flex and allow the shaft to rotate. Of course significant stresses were introduced in the hub when you did this and those stresses concentrated at the points of the hex bore. After only a few rotations of the shaft in the bore, the hub would crack at 2 or 3 of these points and within a couple more rotations, the hub would completely split into either 2 or 3 pieces. We shared these results with the supplier and I believe that they modified their hub molds to increase the thickness of the plastic in the bore area to give it more strength.
I can’t really tell the details of the hub geometry from the drawing on your website, but it appears there is some sort of notch on one of the hex points on your hub. You may want to test your hubs to see if this same failure mode is possible with your compliant wheel hubs. If it is, then you may want to provide a recommendation not to use Thunderhex shaft with these wheels in higher load applications. You may also want to test your hubs with a standard hex shaft. I expect that you will find that the torque required to “skip a cog” with the standard hex shaft is higher than with the Thunderhex and may result in a different failure mode of the wheel (disbonding between the hub and the rubber rather than cracking of the hub itself).
You may also want to publish the torque to failure numbers for each type of shaft in your technical specs. These are interesting results that the user community may benefit from when designing their robots.
Are there any updates regarding both these bugs (I’ve noticed them in Java)?
Output values aren’t set in simulation. I expect that implementing sim onboard control would take time, but duty cycle commands aren’t being set either.
CANSparkMax.close() is a stub that does nothing. I assume that it should be moved to CANSparkMaxLowerLevel and call CANSparkMaxJNI.c_SparkMax_Destroy(handle).
I’ve been told that REV is aware of these bugs and working on them, but they aren’t on the Trello. Should I send an email to support?
RE: the REV hardware client –
We were setting some CAN IDs yesterday, and I noticed a few issues that would be neat to see resolved / some features that would be nice to implement:
When I tried entering in the value “14”, it kept throwing an error when I typed the “1” because “1 is already assigned to a device on the CAN bus”, so I had to use a really sketchy workaround, and it would be great if we could have the option to adjust the value without it automatically checking whether the value conflicted with another CAN ID until we burn flash
Setting a CAN id to 0 is impossible, which is a bit of a pain for teams who want to set CAN ids to PDP port numbers for easier debugging. I’m not too knowledgeable about the FRC CAN Protocol, but it appears it’s possible in the CTRE software, so it would be nice to have it as an option
It’s still not possible to set CAN IDs wirelessly, which can be a major pain with the tight wiring of some FRC robots, so that would also be nice to see
When I tried entering in the value “14”, it kept throwing an error when I typed the “1” because “1 is already assigned to a device on the CAN bus”, so I had to use a really sketchy workaround, and it would be great if we could have the option to adjust the value without it automatically checking whether the value conflicted with another CAN ID until we burn flash
Thanks for the bug report, we’ll get that fixed.
Setting a CAN id to 0 is impossible, which is a bit of a pain for teams who want to set CAN ids to PDP port numbers for easier debugging. I’m not too knowledgeable about the FRC CAN Protocol, but it appears it’s possible in the CTRE software, so it would be nice to have it as an option
As @auscompgeek said, this is intentional. An address of 0 means that the device is unconfigured.
It’s still not possible to set CAN IDs wirelessly, which can be a major pain with the tight wiring of some FRC robots, so that would also be nice to see
The SPARK MAX has no wireless capability, so do you mean “via CAN”? Even if that was implemented, it’s not all that useful, because it would only work if just a single device was unconfigured.
You can avoid this problem by taking a minute to assign each SPARK MAX a unique ID before putting it on the robot.
