2012 FRC Team 1717 Uncut

[JamesTerm]

Originally Posted by jakemochas

To detect flywheel speed, we read from a light sensor that was attached to the digital sidecar I/O.

When you say light sensor do you mean optical encoder?

[Jared341]

Originally Posted by JamesTerm

When you say light sensor do you mean optical encoder?

He may just mean a light sensor (like a Banner sensor, or a 2011 KOP line sensor) being used as a digital tachometer with a piece of reflective tape or a photogate. Nothing to "encode" (in a quadrature sense), since your wheel generally isn't changing the direction that it rotates.

[JamesTerm]

Originally Posted by Jared341

He may just mean a light sensor (like a Banner sensor, or a 2011 KOP line sensor) being used as a digital tachometer with a piece of reflective tape or a photogate. Nothing to "encode" (in a quadrature sense), since your wheel generally isn't changing the direction that it rotates.

Thanks Jared, that is what I was thinking as well... I'd love to see how well this compares against an encoder (either kind)... as of now, I am still frustrated with encoders with these high of speeds.

[BradenKing]

I was in awe of your drive system during the whole competition. I designed my teams transmission, and we were also right across from you guys in the pits at St. Louis.


P.S. Sorry to be a little off topic, but did you guys ever figure out exactly why your robot was dying at the Championships during Quarter-Final Matches 1 & 3?

[animenerdjohn]

Originally Posted by BradenKing

P.S. Sorry to be a little off topic, but did you guys ever figure out exactly why your robot was dying at the Championships during Quarter-Final Matches 1 & 3?

And in one or two qualifying matches in the same alliance station (Station 1 red).

We actually had the same problem, and 1717 came over and compared notes with us. We couldn't find anything out of the ordinary that would cause the comms to fail, especially on our end. We both had perfect readings. It was suspicious that it was always the same alliance station.

I hope the results of the Einstien testing unveil what happened on the division field too.

[jakemochas]

Originally Posted by BradenKing

Sorry to be a little off topic, but did you guys ever figure out exactly why your robot was dying at the Championships during Quarter-Final Matches 1 & 3?

Originally Posted by animenerdjohn

And in one or two qualifying matches in the same alliance station (Station 1 red).

We actually had the same problem, and 1717 came over and compared notes with us. We couldn't find anything out of the ordinary that would cause the comms to fail, especially on our end. We both had perfect readings. It was suspicious that it was always the same alliance station.

We have not been able to determine why our robot died in any of our matches. Our Robot died on Friday in Qualification Match 101 on red 1. On Saturday, our robot died in Quarter-Finals Matches 1 and 3 on red 1. Finally, our robot died in Semi-Final Match 1 on Red 3. We died on Red 3 and Red 1 so our original thinking about it only having to do with red 1 was ultimately disproven.

[jakemochas]

Originally Posted by Jared341

He may just mean a light sensor (like a Banner sensor, or a 2011 KOP line sensor) being used as a digital tachometer with a piece of reflective tape or a photogate. Nothing to "encode" (in a quadrature sense), since your wheel generally isn't changing the direction that it rotates.

Originally Posted by JamesTerm

Thanks Jared, that is what I was thinking as well... I'd love to see how well this compares against an encoder (either kind)... as of now, I am still frustrated with encoders with these high of speeds.

Originally Posted by JamesTerm

When you say light sensor do you mean optical encoder?

It is a reflective photointerrupter with emitter and detector facing in the same direction. We have 16 black marks that are evenly spaced on the side of the flywheel to provide data for the detector.

[Akash Rastogi]

Can I just add that even the level of professionalism in each of 1717's students' posts is pretty inspiring. What an amazing group of people you must be to work with. Thank you for such insightful and detailed explanations.

[jb1403]

Originally Posted by Akash Rastogi

Can I just add that even the level of professionalism in each of 1717's students' posts is pretty inspiring. What an amazing group of people you must be to work with. Thank you for such insightful and detailed explanations.

Well said Akash. This has easily been one of my favorite threads on CD this year, mostly due to the timely and professional responses of Jake. Still hoping to see some pictures.

[jakemochas]

Originally Posted by IKE

Congrats on the 150 in a row. That is quite the accomplishment. I seriously doubt that much more than 10% of FRC have even cycled that many balls through their shooter.

Our original goal for the video was to shoot 100 balls because based on our shooter’s performance, we knew this was possible. This video was the first time we have actually counted how many balls we can shoot in a row. After 100 balls, we decided to keep going out of curiosity. By the 150th ball, we were not able to feed the balls into the robot quickly enough to keep up with the rate of fire. We will always be curious to see how many more balls we could have scored.

To tune the shooter, we shot over 3000 balls to get the correct PID values for the flywheel, hood and platform and the correct bank shot for the largest variety of balls. During and after build season, we continued to experiment with different control loops and shots until we found the performance that can be seen in that video. We collected a variety of data on different types of shots, including both swishes and bank shots. In the end, we found that the bank shot was the most forgiving.

Originally Posted by btslaser

1) Does the shooter wheel run continuously at a nominal or the last speed?
2) Is it using camera tracking? Continuous?

Originally Posted by LeelandS

I don't know about you guys, but I'm way more interested in their targeting software!

As the programmer responsible for the shooter, I will give an overview of the shooter code. I think many people are going to be surprised how we aim our shooter. Originally, our goal was to shoot from anywhere on our half of the field. As the build season came to an end, we decided to hold our shooter back as part of our withholding allowance to continue working on shooter code. In the time before our competitions, we ultimately got the camera tracking to work from anywhere. However, we were surprised to realize that we could shoot more quickly and accurately with crosshairs on the drivers station and a video feed. After we watched a regional in week one, we reassessed our shooting strategy and reduced the number of locations on the field that we felt were strategically advantageous and worked on those.

In order aim the shooter, we created 5 preset values. For the key, there are left, center and right presets. For the fender, there are left and right presets. Our co-driver holds down either the “fender” or “key” button on his joystick and moves the joystick towards the direction of the hoop. For the fender, it will set the platform angle, flywheel speed, and hood angle to the correct values to make the shot. No other adjustments have to be made for the fender shot because it is a relatively high percentage shot. For the key, our co-driver moves the joystick to the left, middle, or right to get the preset hood angle, platform angle, and flywheel speed. From that distance, the presets would only work if the driver perfectly lined up the robot to the left, right, or center. To compensate for any robot misalignment, our co-driver uses a video feed on the driver station with crosshairs to make the final adjustment to the platform angle. The hood angle and flywheel speed are taken care of by the code. Although our shooter is capable of shooting more quickly than we do in a competition, we have a limiter on the shoot button that detects when a shot is fired and pauses for 100ms to make sure the previous shot has cleared the rim.

The flywheel runs continuously at its last speed. Our flywheel is only set to two different speeds: one for the fender shots and one for the key shots. A PID control loop maintains the speed of the wheel as balls are shot. Additionally, the co-driver can incrementally increase or decrease flywheel speed. This feature was implemented in case the wheel speed sensor failed and we had to run open-loop.

[JamesTerm]

Originally Posted by jakemochas

However, we were surprised to realize that we could shoot more quickly and accurately with crosshairs on the drivers station and a video feed.

Before I reply to this quote I wanted to thank you for everything written in this last post... it was very inspiring.

I am very surprised by this statement too, and I'm wondering if you feel that you have done everything possible to make the vision code as fast and efficient as possible. Also was the vision code processed on a PC based driver station, or in the cRIO?

I'd be curious to know how fast the vision detection could lock on to the target... as I've heard (and seen video) of other teams that could lock on to the target in real-time.

[LeelandS]

Originally Posted by jakemochas

However, we were surprised to realize that we could shoot more quickly and accurately with crosshairs on the drivers station and a video feed. After we watched a regional in week one, we reassessed our shooting strategy and reduced the number of locations on the field that we felt were strategically advantageous and worked on those.

Wow... This surprises me. I knew of a handful of teams throughout the season who effectively used camera cross hairs. 1507, a shooter powerhouse at Finger Lakes, won the regional with those cross hairs. I believe I heard at one point 217 was using them as well, and 67 had borrowed the code for them for some time (thought this may be incorrect. Memory doesn't serve me well nowadays).

But I never expected 1717, one of, if not the, most precise shooters in the world, would use them. This really convinces me that you don't need complex systems to do well.

[Hjelstrom]

Originally Posted by jakemochas

We have not been able to determine why our robot died in any of our matches. Our Robot died on Friday in Qualification Match 101 on red 1. On Saturday, our robot died in Quarter-Finals Matches 1 and 3 on red 1. Finally, our robot died in Semi-Final Match 1 on Red 3. We died on Red 3 and Red 1 so our original thinking about it only having to do with red 1 was ultimately disproven.

Have you looked at your driver station log files from those matches?

[smistthegreat]

Originally Posted by LeelandS

Wow... This surprises me. I knew of a handful of teams throughout the season who effectively used camera cross hairs. 1507, a shooter powerhouse at Finger Lakes, won the regional with those cross hairs. I believe I heard at one point 217 was using them as well, and 67 had borrowed the code for them for some time (thought this may be incorrect. Memory doesn't serve me well nowadays).

But I never expected 1717, one of, if not the, most precise shooters in the world, would use them. This really convinces me that you don't need complex systems to do well.

Not trying to hijack the thread, but I just want to clear this up. We did not use crosshairs. We just had the straight camera feed that we used to line up.

Also, this thread is just full of awesome.

[Gdeaver]

Our team has done 4 wheel 360 rotation independent swerve also and loved looking at your drive at champs. Similar but different design. In the past we have used a least distance algorithm for steering. Sometimes it's quicker to rotate a short distance and reverse the drive motor. Do you do that in your code also? This year we eliminated the motor reversal part. We still check the shortest rotation direction. The bot seams to drive much smoother this year. How did your team handle the steering algorithm?
We do not have field centric control but are looking to add the gyro this coming year. In a match on average how long did the gyro go before errors added up to the point it affected driving? How many seconds before a zeroing was needed? Did you try any digital (I2C or SPI) gyro's or only analog?
One last question. What wheel angle sensor did you use. Do you feel it's accuracy and resolution are good enough or do you feel high resolution is needed. How many degrees of lash does the steering have. Our bansbot gear boxes have allot of lash. We haven't found another gear box solution that we can afford.