Team 254 Presents: 2015 FRC Code

[Ryan Johnson]

Hi everyone,

Team 254 is happy to share the code base for our 2015 robot, Deadlift.

This year’s software includes new features such as a test harness and simulator code to run the program on a computer, web-based graphing tools, constants editor, and autonomous selection, blocking autonomous routines, and a controller that calculates and follows a trapezoidal motion profile, on the fly. Please take a look at the following repositories:

Robot Code: https://github.com/Team254/FRC-2015
Simulated Robot Hardware: https://github.com/Team254/Sim-FRC-2015
Simulator: https://github.com/tombot/FakeWPILib

[orangemoore]

I am really excited to look through this! Thanks for posting this.

[artK]

Originally Posted by Treefaceman

Couldn't help but notice that nearly all the commits were from Jared and Tom....

Nonetheless, excellent work!

I was a programmer with 254 from 2011-2014. As others mentioned, a lot of the commits are done from Tom or Jared's computer, but students and mentors write the code. 254 programmers usually followed pair/group programming practices, forcing students (and mentors who might be there) to check our work with each other, and a lot of work ends up getting done on a couple of computers. Additionally, when testing the code on the robot, you can only deploy code from one computer at a time, so writing on multiple machines is an unnecessary hassle most of the time.

Originally Posted by AlexanderTheOK

If a team of 254s caliber is seemingly forgoing this utility I would personally like to know why. (Different internal system for tracking bugs? Mentors reviewing code before it goes on github? All just speculation of course.)

Github isn't designed for our practices of code writing. (Though a version control system that works for arbitrary groups of people committing as one would be cool). And for bugs, we usually just chased them down when we found them, getting help for them as needed.

[AdamHeard]

Originally Posted by notmattlythgoe

That doesn't mean anything. All of the commits on our team are tagged with the same name because they are done on the same computer.

You know what also doesn't mean anything?

Implied slander from an anonymous account.

[notmattlythgoe]

Originally Posted by AdamHeard

You know what also doesn't mean anything?

Implied slander from an anonymous account.

Truth.

[Anupam Goli]

So would it be possible to use the simulator and run our own code on it at any point, or are there any steps to make it work?

[AlexanderTheOK]

Originally Posted by AdamHeard

You know what also doesn't mean anything?

Implied slander from an anonymous account.

While it does look rather accusatory (the comment by Treefaceman that is) I still find the observation interesting. I've always found one of the nicest things about any revision control (svn or github) was that it sped up our understanding of the stranger bugs:

#define true ((rand()&15)!=15)

by letting us know who wrote the code in which it was introduced.

If a team of 254s caliber is seemingly forgoing this utility I would personally like to know why. (Different internal system for tracking bugs? Mentors reviewing code before it goes on github? All just speculation of course.)

[JamesTerm]

Originally Posted by AlexanderTheOK

While it does look rather accusatory (the comment by Treefaceman that is) I still find the observation interesting. I've always found one of the nicest things about any revision control (svn or github) was that it sped up our understanding of the stranger bugs:

#define true ((rand()&15)!=15)

by letting us know who wrote the code in which it was introduced.

If a team of 254s caliber is seemingly forgoing this utility I would personally like to know why. (Different internal system for tracking bugs? Mentors reviewing code before it goes on github? All just speculation of course.)

I like using the "blame" utility in SVN where beside every line of code adds a column of who wrote it and which revision of when it was added/edited. Actually though what really happens (from our workplace) is that each engineer is responsible for their own "module ", This seems to work best for us... there by... reducing the need for "blame".

On a side note... what does that #define line of code do? Is that some fuzzy logic?

[AlexanderTheOK]

It was a prank a friend of mine played on me a few years ago (not while programming robots). Basically, true is true... Most of the time... It's not as easy to detect as #define true false. We had a whole slew of these we did back and forth.

[Joey1939]

I followed the directions here to run the robot code in the simulator. I got the following error.

run_sim.rb:6:in `exists?': no implicit conversion of nil into String (TypeError)
	from run_sim.rb:6:in `<main>'

[thatprogrammer]

Some questions (not a very advanced programmer, yet)
1. How do you run autonomous mode despite the looper? If you tried your approach on a normal iterative robot template, the loop would run on the wait commands, preventing it from advancing.
2. You need to generate splines to create paths for motion profiling, right?
3. What is the peacock motor?
Some more questions, but I'll wait for answers to to these first.

[Tom Bottiglieri]

Originally Posted by thatprogrammer

Some questions (not a very advanced programmer, yet)
1. How do you run autonomous mode despite the looper? If you tried your approach on a normal iterative robot template, the loop would run on the wait commands, preventing it from advancing.
2. You need to generate splines to create paths for motion profiling, right?
3. What is the peacock motor?
Some more questions, but I'll wait for answers to to these first.

1. We run the auto in a separate thread. The main thread of the robot which handles iterative updates does nothing in auto mode because all of the marshaling done by the auto modes is done in another thread, and all of the control loops run in a different thread.

2. We didn't use any spline paths this year. All of the control loops were 1d (elevator carriages, drive forward, turn in place). All of the moving subsystems shared a generic base controller which could be tuned for the properties of that system. The motion profiling was done on the fly (this is a much easier calc than generating spline-y paths).

3. The original concept for our can grabber was a system that had 4 individual telescoping arms (feathers) that would go out and grab each can in auto, all starting from the robot centered on the field. This made the robot look like a peacock, and the name for that subsystem stuck through iterations. A motor peacock is just the motorized can grabber assembly.

[Abhishek R]

Originally Posted by Tom Bottiglieri

3. The original concept for our can grabber was a system that had 4 individual telescoping arms (feathers) that would go out and grab each can in auto, all starting from the robot centered on the field. This made the robot look like a peacock, and the name for that subsystem stuck through iterations. A motor peacock is just the motorized can grabber assembly.

How early in the season did that idea come to inception?

[Tom Bottiglieri]

Originally Posted by Abhishek R

How early in the season did that idea come to inception?

We had some sketches of this day 1 of build.

[Jared]

Originally Posted by Joey1939

I followed the directions here to run the robot code in the simulator. I got the following error.

run_sim.rb:6:in `exists?': no implicit conversion of nil into String (TypeError)
	from run_sim.rb:6:in `<main>'

run_sim.rb takes two arguments, the robot code directory FRC-2015 and the sim directory, Sim-FRC-2015. It sounds like you're giving it only one argument.