Recent Posts

Pages: [1] 2 3 ... 10
Misc classes / Subwoofer class slides
« Last post by Louis L on July 25, 2017, 09:55:45 PM »
Robot Software / Making a swerve object
« Last post by Louis L on July 16, 2017, 06:16:57 PM »
WPIlib does not have a built-in swerve drive object. We should take what we've done and repackage it into a generalized object and donate it to WPIlib.

Met with Matt & Brayden at Tatnuck on July 15. Meeting summary below.

Basic stuff used in our implementation:
  • 4 speed controller drive (any)
  • 4 speed controller rotation (any)
  • 4 rotation sensors (AndyMark/PG71, required)
  • 4 PIDs for steering (HW/talon or sw)
  • 4 absolute encoders (optional, allow T of rotation sensor to absolute encoder)
  • 1 gyro (multiples)

Definitions and enums
  • width & length = center to center distance.
  • angles = in degrees
  • enum LF, RF, RL, RR

Phase 1 - create a swerve drive module tailored for the AndyMark product. Convert our code to use it and prove it works.
  • constructor (8 speed controllers, 4 encoder, width, length)
  • constructor (4 speed controllers, 4 talons for rotation, width, length)
  • swervedrive (3 joystick inputs - fw/bk, l/r, rot)
  • swervedrive (3 joystick inputs, gyro)
  • getmode(); setmode(fieldcentric | robotcentric)
  • resetwheelangle (4 current angles)
  • setrotationpid (4 PID values, tolerance)
  • setinvertedmotor (speed controller enum, boolean)
  • setsafety ( )

Phase 2 - Generalized swerve module

In addition to above:

setgearratio ( )
setpulseperrotation ( )

Error reporting
if (mode=fieldcentric && using wrong swervedrive command)
                                     default gyro=0, report error
Things we learned / Reading vaues from the Dashboard does not always work
« Last post by Louis L on May 29, 2017, 08:50:00 PM »
The scenario we're working with here is where the robot code wants to read a value from the dashboard before starting autonomous. The idea is to read a value set by the user and then act on that value. For example, the value may indicate which of several autonomous options to execute. The problem is that the value read via the network tables may not be the current value but rather the one that was in the table from the previous run of the code (previous match for example). Whether this happens outside of autonomous is unknown.

We have come across this problem in LabView (2016) and Java (2017). Presumably C++ has the same problem. It didn't seem to happen as often with LabVIEW as with Java but that's hard to quantify. We tried different timing techniques to try to make sure that the Dashboard value would be set prior to the robot's start of execution but so far we've had no luck in fixing this. And it's not clear if there's a way to prove that we fixed the problem - not seeing the behavior does not mean the problem has been fixed since we don't really know what the problem is in the first place (we only have suspicions).

For now the most reliable way to select different auto modes is to either program them in or have a hardware selection switch on the robot itself.
Got this from Brayden; followed up searching on Chief Delphi.

It seems command groups are constructed once when the robot first starts. This means the command group can not obtain an external value at a later time (ex: read a sensor value) and then conditionally do something based on that value. Values must be set when the command group is constructed; not later. The same command group object is reused each time it is called (ex: in response to a button press). The workaround for this is to create multiple command groups and externally execute the conditional which then fires off the correct command group.
Misc classes / Re: Subwoofer
« Last post by Louis L on May 08, 2017, 03:13:57 PM »
The schedule for this class is as follows:

Monday May 22 - Thursday May 25 (or shorter if we get it done sooner)
Note - you can't miss classes because each relies on the previous class. By the end of the week, each student will have a design that is custom designed for their specific needs.
  • The science of sound reproduction
  • Listening
  • Designing a subwoofer for a system
  • Run simulations
[Skip the week after due to graduation and other school activities. This also gives time for the parts we order to arrive]

Monday Jun 5 - Friday June 9 (or shorter if we get done sooner)
  • Build, Test, Measure and Tweak.
Building a proper box can take some time. Hopefully we'll be able to finish the core of each box. Any additional finishing of the exterior, if not done in these 5 days, can be done at home.

Things we learned / Battery retirement
« Last post by Louis L on May 03, 2017, 05:00:03 PM »
Robot batteries take a lot of beating. We don't treat them well at all; especially when they are discharged beyond what is reasonable. Our batteries are not labeled "deep cycle" yet we often treat them as such in practice and competition. So let's make sure we retire old batteries before they surprise us and die at the wrong time.

We're on a schedule where we keep batteries 4 years. So for 2017 (2016-7 school year) we retired batteries bought in FRC 2013.

All batteries should be labeled with the year of acquisition.

Retired batteries can still be used for other purposes such as lighting in the outside container, test-bed use, etc.

When they finally totally die, they need to be properly recycled (they contain lead).
Things we learned / Check Battery terminals
« Last post by Louis L on May 03, 2017, 04:54:53 PM »
We use a 5 ton press to secure the Anderson cable wires inside the terminals. Those terminals are then mounted to the battery with nuts/bolts. Be sure to check all battery cables regularly. Wires can pull out over time and bolts can work themselves loose.
Arcadia / Arcadia hardware internals
« Last post by Louis L on May 03, 2017, 04:48:29 PM »
The 2017 version of Arcadia ran off a raspberry pi.
For 2018, I'm looking at changing this to a laptop, probably running Ubuntu or maybe Windows (if necessary). Pros and cons below.

pros - laptops are more portable and easier to work on. No need to hook up a monitor, keyboard, etc. I have a bunch of surplus Dell D630 laptops perfect for the job. They also have more disk space and memory. Running a desktop Linux OS is also easier in terms of support than running an embedded version in those in a micro-controller (like Raspian for the Pi).

cons - laptops take up more space in the arcadia cabinet than a Pi or similar micro-controller.
General Topics / Doing the wave
« Last post by Louis L on May 03, 2017, 04:39:30 PM »
Tired of waving at the motion sensing lights in the workroom?
Then build a automatic wave machine.

I have quite a few controllers (arduinos and similar). There are also several sets of Atmel chips (used in Arduinos) that can be programmed to do stuff.

Challenge - design and implement something clever that responds to the motion sensor.
  • must have on/off switch so we can enable and disable this device.
  • must be portable and not too large. size limit TBD.
  • must be battery powered. Wall outlet is allowed but must be an option not a requirement.
  • must not make a mess nor get in the way of productivity in the workroom. This means it can't be noisy, annoying, or otherwise be a distraction.
Who's in?
Misc classes / Subwoofer
« Last post by Louis L on May 03, 2017, 04:31:07 PM »
This post-season class is intended to be primarily a fun construction project (who doesn't like BASS!). But in the spirit of STEM, there will still be science and engineering involved. The end goal is for each participant to build a custom subwoofer to suit their needs (size, cost, power handling, etc.)
Pages: [1] 2 3 ... 10