Blinken LED Driver Exploration

Ryan works on learning levels for the Blinkin
Determining the proper step value for the Blinken

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.

TeleOp Smoothing

Our summer robot’s controls aren’t great. It accelerates far too quickly and it does’t allow for fine control. Our goal today is to make the robot easier to drive, building on our exploration of quadratics last week..

We started with a very basic linear teleop.

Our first attempt at drivetrain input functions

Our first attempt at smoothing was to apply a quadratic to joystick input.

Quadratic smoothing of drivetrain functions

This still accelerated too fast. We decided then to create a “slow” zone
in the first half of the joystick range that would always drive a consistent
speed.

Quadratic with a dead zone

This proved best. We could easily go fast when we needed to, and we
can easily turn and inch slowly when we need to. If we use a 6WDC
chassis this year, this will be our teleop drive function.

Ryan and Chase testing the drivetrain

Summer Chassis Testing, Teleop Test

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.

Our default (linear) control mapping

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.

Logarithmic control mapping

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.

Squared control mapping

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.

Cubed control mapping

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.

Quadratic $x^5$ control mapping

Summer Chassis Assembly

Today we started assembling our practice drivetrain and coding a
teleop for it. Jonah taught Chase and Kristoffer basic trigonometry and how to program mecanum wheels. Chase and Kristoffer didn’t know how to use polar coordinates yet and our programming wasn’t very functional so, Jonah gave them a quick overview. Afterwards Chase attached new gear boxes on the motors and helped Emilio and Ryan assemble the drive train. They got the wood we cut out earlier, filed out the wholes for the motors, and fit the motors and bearings. After, Emilio and Ryan put the two halves together. Jonah tested a new language for programing the teleop, tested, and fixed issues.

Jonah teaches Kristoffer the trig he’ll need to program a drivetrain
Chase assembles Vex VersaPlanetary gearboxes

Summer Chassis Assembly

Last Saturday, we cut out our side panels and top panel out of wood for our “Summer Demo Robot.” Today we finally started putting together our robot using the cut-out panels. We found that using Fusion 360 easily allowed us to design a functioning robot. With this knowledge we were easily able to assemble one side pod this meeting and plan to assemble the rest in the following meetings.

Emilio and Ryan assembling side pods
Our first assembled sidepod

CNC Cut Chassis Sides

After fully completing the CAD Robot, we decided on reaching out to a
former Suit Bots alumni Brian because he invited us to use his CNC Machine to cut some of our various custom parts for our robot. He said we could come over on July 6th. Upon arrival, we wentover how to use Fusion 360 in a way that allows us to view a simulation on how the CNC Machine will cut the stack of wood and create our panels. After that, we uploaded the 6WDC file onto the machine’s program that allows us to send the information to the machine. After 2 ½ hours, we had cut out all our panels. After we cut them out we sanded them down to be more usable and proper.

Our first CNC milled part: a side panel for the 6WDC chassis

Finalized CAD Model For 6WDC Chassis

Today one of our new freshman members Andrew came in. We showed him around and taught him how to use F360. Additionally with Andrew’s help we finished the side panels and top design for the 6WDC chassis.
Now the top and side panels are now ready to be CNC machined.

Rendering of our summer 6WDC robot

Fusion 360 Tutorials

Today we met one of our incoming freshmen. His name is Kristoffer and
he was drafted out of one our local middle schools, Clifton. We also
found that he is the youngest Disneyland Rider on this side of
Anaheim.

We also began the engineering tutorials for Fusion 360. We watched
several tutorial videos before having to leave. Jonah found it
inconvenient that you cannot mate in Fusion 360.

Jonah and Kristoffer learning how to use Fusion 360