Today we worked on learning how to use the REV Robotics Blinken LED driver. Previously we learned how to set the user colors, but we did not know how to control the color modes.
The REV documentation listed PWM values for a RoboRIO controller that would activate different color levels. The RIO has a PWM output range that differs from the FTC control units. We created a Wolfram Cloud notebook to try to figure out what the values would be for FTC. Our first approach was to find the step value for each different color:
From there we wrote a small OpMode to start at what the REV documentation said was the beginning of the FTC output range (.2525) and step through colors one by one, taking note of what colors and patterns we saw for each value.
We learned that, though the REV documentation says the range only goes to
.7475, some values are above that published range. Black — or “off” — is at 0.7775, for example. We determined that the colors we are most likely to use are:
Re (.6725) for when we are the Red alliance
Blue (.7425) for when we are the Blue alliance
Green (.71715) for a “go” alert color
Yellow (.6975, actually gold) for a second alert color
Black (.7775) to turn the lights off.
On the next page is our observations of colors and patterns based on
PWM signals to the REV Expansion Hub.
We finished assembly of our chassis today and started testing it.
Our first observation is that while the robot was very fast, it is
difficult to control at low speeds.
We started talking about how we could make the controls more manageable.
At the recommendation of Mr. Porter, we looked at several different methods
of mapping user input to motor speeds Here is some of what we looked at:
Our first attempt used a linear control mapping. It maps the joystick input directly to the motor speed. We found this to be far too fast.
We looked at logarithmic functions next. This didn’t look particularly appropriate for a drivetrain, so we did not spend a lot of time with it.
Next we squared the driver input. This produced a nice curve that would allow us to ramp speed up more slowly. Unfortunate, it also meant that we would have to multiply by the sign of the user input if we ever wanted to go backwards.
Cubing the driver input produced a somewhat nicer curve than squaring. It was a little easier to drive, but not much. Not needing the sign term in the teleop was nice.
We tried $x^5$ as well. It was not noticeably different than $x^3$, so we figured we could end or exploration of quadratics here.