And we didn’t get picked for eliminations.

To say the Crusaderbots are bummed out would be an under-exaggeration. We know it’s not about winning or losing, but now building 2 identical robots, perfecting an auto-aiming turret, and practicing for nearly 100 man hours goes unrecognized. There’s nothing to show that we did in fact have an awesome robot. It feels like it’s no better than last year’s Robespierre, which stood as the perfect example of what not to do.

We knew what we could fix after the Oregon Regional. We don’t know what we could have done differently after this one.

Maybe I’ll think of something better later, but the only takeaway I got from this regional is “Better luck next year”

We had some difficulties on Friday, but our drivers got a chance to learn the ins and outs of Rebound Rumble, and excelled on Saturday.

Our awesome drive team (Image Credit: Jason Marr and Lori Hoover)

Let’s hope we can keep up the momentum in Seattle.

Go Crusaderbots!

1) Hardware would tell software about what the current design is.

2) Software, in their genius, would magnificently code it

3) Software would inform electrical what their needs are

4) Electrical does something.

5) Hardware informs software that the design has radically changed, and most of software’s code is now obsolete.

More monitors than programmers

Somewhere in there testing would occur. Normally, this shouldn’t cause too much of a headache, but communication between teenagers is never optimal. One of the three departments would eventually be living in a fantasy land, and cause the project to be halted because their stuff no longer works.

For software, the easiest defense against this is a reversion system, such as SVN or Git. In the beginning, I made the executive decision that this was unnecessary. We used Dropbox because we only need a common set of code across the computers at school. But then, literally in the middle of the night, the robot started to misbehave after a new feature was being implemented. The entire software team had been working on the same code, so we had no idea what the problem was. It caused high tensions.

Thankfully, out of necessity, I had a clean copy of code on my flashdrive, because I needed a convenient way of transferring the code to a computer that did not have internet. We used this as a template.

We then developed a primitive reversion system: anytime code was in a stable, template-able state, we placed it in “cold storage” either on the Dropbox, or for more major revisions, on my flashdrive. This way, if we ever need to go backwards, we could just use one of the previous copies.

I learned my lesson, and so did my entire department. After hours of debugging and figuring out what we were doing on the pratice bot, we finally got an autonomous that works!

Can you believe it’s nearly the end of Week 6 already?How did the time fly by so fast?

This is my first season mentoring a FIRST Robotics team, and I’ve had the privilege to be a part of the Jesuit Crusaderbots. Since I haven’t mentored before, I don’t know how unusual this is – but I think that the Crusaderbots really embody some of the most important parts of FIRST – gracious professionalism, coopertition, and certainly HARD FUN.

Although I work a full time job as a Program Manager at Autodesk, this team has welcomed the small chunks of time I’ve been able to participate with open arms.  They meet nearly every day, and they are so focused and positive at working toward the goal.  I’m amazed at some of the technology these young high school students are mastering: from Software programming in Java and C, Electrical systems (power and control systems), and CAD – using Autodesk Inventor (selfishly, I must say yay!). But I think perhaps this team’s biggest competitive advantage is their Leadership Team.  This is a small team of experienced students, each taking a lead role in the major functions of the team. They are responsible for making sure that their sub-team is working well together, on track per the overall schedule, and most of all – training the rookies.  This not only builds a great team environment that’s inclusive and fun to be a part of, it also ensures sustainability of the hard work their predecessors have done – keeping the team alive, year after year.

I think every mentor must have a long list of things they are proud of their team for, and I’m no different. And when I initially got connected with FIRST, I nostalgically wished that I’d had this opportunity when I was in high school. But now, I look forward to ensuring that FRC is alive for as many students as possible. And the Crusaderbots are doing their part to achieve that goal.

Good luck this season to my ‘bots and all the FRC teams! I’ll see you at the Autodesk Oregon Regional – I’ll be the one with the huge grin, and a tremendous sense of pride for my team – just like you!

Janna Spicer
Program Manager, Mechanical Design Product Line Group
Autodesk, Inc.

For the last two weeks I have been working on the e-board for our robot Air Charlie. It was a lot easier this time because we wired the Jaguars up with CAN. Instead of long PWM wires all over the place, the Jaguars are daisy chained  so the wiring is a lot neater.

Attaching the E-Board to Air Charlie

Today we got to assemble the chassis, the tower, and the e-board together. After a few stupid mistakes by software, the robot was driving around in low gear. Here is a video of our robot driving around:

This ease of assembly is all thanks to one company: Metal Innovations, Inc. Before the build season, I contacted Metal Innovations to see if they would be willing to laser cut parts for the team, as they had in 2008. They generously offered to donate not only machine time, but material as well. In addition, they agreed to produce enough parts to make two robots: one that will be bagged on the 21st, and another that our drivers will use to hone their skills before competition.  Their generosity has not only helped us build a robot that will work well and look slick, but has helped the team learn about the importance of design.  Seeing the sheet metal parts go from 3D models in Inventor to precision machined parts demonstrated to all of us the power of Computer Aided Design.

A picture of the chassis being built from the laser cut sheet metal donated by Metal Innovations:

Well, it’s week 4, and the code is in the most fantastic position it has ever been in. Ever. Previous years, the software team was limited to one or two people, furiously trying to code all of the motors and few sensors we had. They struggled to implement a fully functional PID control system to smooth out the drive train during autonomous. The main reason they struggled is because they had about 2 days to test everything.

This year, things are severely different.

This year, we have 3 people working full time, instead of just one, with each person being designated a specific section of the code to write and compile. This departmentalization has worked wonders for the team.

As I said, it is week four, and the robot is fully coded.

I could not be happier. But I could be better rested.

An interesting dynamic which occurs in any group effort, is peer pressure. As the mechanical and electrical departments busily work late into the night, Software finds itself at the mercy of the group. We are encouraged, nay, Inspired by the dedication of those brave souls, willing to risk limb and finger for a robot, to continue and double our coding efforts.

It has not been without struggle. Because I am also the head of my School’s game design club where we are working on a game for the Oregon Game Project Challenge, I find myself stretched thin. I can only come in on Fridays and Saturdays, with an occasional interlude another day of the week. This means I must be triple organized, talking with my team every day to see what has been done, and what still needs to be done, so when I come in Friday, I can see how far we have come, and how far we have to go.

But it has all been worth it. This year, instead of just having encoders on our motors to see how fast our robot is moving, we have an entire sensor suite. Let me show it to you:

We have a tower which both stores and picks up balls from the field. We designated this a separate class, and assigned one of our coders to write and compile it. Included in the tower are two motors for controlling the pickup of balls, and delivery of balls to the pitcher. Along the way, we have two Infra-Red sensors, one at the top, the other at the bottom. The one at the top keeps track of how many balls are leaving the tower, and the one on the bottom keeps track of how many are entering the tower. We then pass this information on to the driver station so they can decide what they want to do.

We also have a turret. This is a complicated piece of work. The main job of the turret is to rotate the pitching machine, which will deliver the balls into the hoop. The real question is how to measure it. We are still not entirely sure what sensor will be used to measure it. To rectify this, we coded two different strategies to calculate how to measure the rotation of the turret. We can either use a potentiometer attached to the turret and measure the angle directly, or we can use an encoder on the motor to calculate how much the turret has moved. From this, we can measure the angle.

The pitcher itself has several other sensors. It has an encoder attached to its motor controlling the launch of the balls itself, so we can calculate the actual velocity of the balls exiting the pitcher. We then are using a potentiometer to calculate the angle at which the balls are launched.

But wait, there’s more!

Our most exciting sensors are rather mundane. Two gyroscopes are connected to our robot. One is standing upright, the other on its side. Using these, we have a PID Control loop which will rotate our robot 90 Degrees for us, in any direction we choose, and it will auto-balance our robot on the bridge.

Finally, the Pièce de résistance, our webcam. Now I know what you are thinking: “A webcam? How is that so great?” Well my good sir and/or madame, It’s not so much that we have it, but in how we are using it. We are using our faithful webcam, Rufus, to calculate the distance of our robot from the hoops, and to auto-aim our pitcher using our turret so that the drivers can focus on picking up and shooting.

It has been hard to code all of that, and to make it all integrated. It has taken serious pain, sweat and tears, but we are extremely happy with our result. Not only do we have a fully integrated robot, but we have several robot codes so that if we wanted to test a single subsystem, say the tower, we can.

Now, I wonder when Mechanical will get us the rest of the robot to test….

See you at the Portland and Seattle Regionals!

CAO Anna Calkins with the Platt Electric Grant

The Crusaderbots give a big thank you to all of our sponsors!

While the pitcher team worked on their prototype, the mechanical department got to work on machining parts for the chassis while the CAD team worked on the CAD for the pitcher, incorporating ideas from the prototype. We got an assembly line of sorts running, as part drawings passed from “station” to “station.” If we keep up the pace, and hopefully avoid mistakes, we should be able to finish two robots right on schedule. The field elements team finally completed the backboards and plans to start the bridge next week.

Software also kept itself busy, even without a robot to test on. Shivani finally got the Classmate and the cRIO re-imaged and updated after countless troubles. John and Ananth have been hard at work getting vision targeting to work for auto-aiming.

As for myself, I’ve dedicated myself to perfecting the website. The homepage got a slight makeover and now includes rankings for the five people who have spent the most time in the shop. We’re all hoping the friendly competition doesn’t become unfriendly.

30 Days to Stop Build Day!