Banging the driver station

[nstephenh]

Originally Posted by Abrakadabra

NO - this is not an excuse, especially from a team that just this weekend won an Innovation in Control Award!! (I certainly hope it wasn't for your "navigation" system.)

The Control Award was for our vision system. In addition to goal tracking, we have also been working on using neural networks to track balls. We don't currently implement ball tracking, but we are working on it.

Originally Posted by Abrakadabra

Everybody else seems to be able to avoid it - why can't you?

This is a good question, and there are various different reasons. How the robot handles when it hits the defense comes down to a lot of different variables, including what type of drivetrain was used, wheel size, and exact angle that we hit it. Our drivetrain is certainly not perfect at going over defenses, and we have to hit the rock wall just right to get enough traction to go over.

If you look at some of our matches on Saturday, you will notice that we stop before the alliance wall in our first few matches. The question then is what changed between then and the end of today. This requires a bit of explenation. Our autonomous reads values from the Dashboard via Network Tables for an autonomous (do nothing, drive, drive and aim, etc) and a distance to travel. At some point the robot stopped reading these values at the start of auto while on the feild (expect another post about this tomorrow). We don't know why; It worked just fine on the practice feild, and we tested multiple times. Since we no longer had the option of reconfiguring the distance our robot drives based on what defense we were in front of, we were faced with the option of having no autonomous or having an auto that goes x inches, and to change that we would have to recompile and redeploy.

We played a match; auto went fine (crossed the defense, didn't hit the wall). We played another match, and we got stuck on the rock wall. We now had the choice between not always being able to get over the rock wall or definitly getting over the rock wall by running for all of autonomous (just in case we get stuck). We chose the more strategically viable option, in order to get the most points.

Originally Posted by Abrakadabra

I know we try to be all GP and everything here on CD, but in this instance, I think some public shaming of those who persist in this lazy practice is totally appropriate.

Lazy? Perhaps. I would certainly describe some programmers on my team using this word at times, myself included. But in this case, particulary our case where we had to make this change at competiton due to an undiagnosable issue, we feel it was the right decision. Furhtermore, we're not entirely sure how we would detect our total distance traveled. We've talked about adding an ultrasonic sensor, and I believe we've experimented with using our NavX MXP to detect distance traveled, but we've had trouble with both of these methods in the past. Encoder values have been the most relable way of detecting distance traveled. This doesn't work when we loose traction with the ground.

Originally Posted by Abrakadabra

(And no - my team is not one of those who have had their DS unceremoniously dumped - at least not yet! I just think it's a real shame that some teams have no consideration for the teams behind the opposite driver station and for the hard work that others have put into controlling their robots properly.)

I expect that most teams that build custom driver stations have velcro on the bottom, or put velcro on the bottom of their laptops (We did after we noticed wall-banging in Palmetto). Furthermore, most refs have been allowing teams to catch falling driver stations/controllers, crossing the line with no penalty.

I appologize for typos or anything else messed up or confusing about this post, I've been at a robotics competition for a while and am very tired.

[T3_1565]

To me I don't think its worth a yellow card.

There are so many reasons why a robot could smash into the DS wall in this game without it being "attempting to damage the opponent's DS" which is the only thing worthy of a yellow card.

What if the code is off? What if I sensor fails or gives a wrong reading? What if it's a rookie team that has no sensors and was just guessing?

In teleop it seems to me that most of the time teams are running into the wall because they can't see whats going on and its much easier to hear that you hit something and turn to low goal then it is to hope your close enough that you don't run into the invisible barrier on the batter and beach yourself.

I don't think anyone is trying to attack other driver stations. It just comes with the "violence" (not in a negative way) of this game

[Abrakadabra]

Originally Posted by bdaroz

Let me ask a rookie team question....

If you are low-bar capable, one thing you could do is always ask your alliance partners if you can have the low bar spot - it never hurts to ask. And if one of them has a low-bar autonomous that does more than cross (i.e. also scores) then you should consider not running auto that match or else just run a short distance for the 2 point REACH.
Another thing you can try without adding any additional sensors is reading the current from your speed controllers directly from the PDP. Presumably you will see a spike in current as your bot climbs over the defense, then it will level out once it reaches the other side. Just do a moving average of the current over time and stop when you see it going down.
If you can add encoders to one or both sides, then you can better measure distance traveled, and again, averaging over time will give you velocity. When you see the bot speed up after the defense, then shut it down. (of course, this presumes that your wheels don't slip excessively while crossing).
In the future, you might want to consider an ultrasonic sensor (relatively cheap, but prone to signal scatter from the diamond plate walls) or for a little more money, one of the new compact LIDAR units.

Originally Posted by alicen

I just wanna touch on this one tiny thing - sometimes you think your auto is right, then it's not. If a student makes a small error, should they be yellow carded immediately for it?

A Yellow card is meant to be a warning - there is no immediate penalty, but it is a strong incentive to not do it again. Giving an "extra strike" as Greying Jay suggests would be difficult to track unless FIRST goes to a 3 card system.
I am of the school that believes no code should be run on the field unless it has been duly checked out on the practice field, and if that can't be done before a match, then you just have to forego the potential auto points until you can. Of course, there are always things that can go wrong due to unforeseen special circumstances (see 3467's whirling dervish can grabbers from last year), but the Yellow card warning would be a strong incentive to figure out why it happened (as we did) and make sure it never happens again.

[AWoL]

Originally Posted by kmodos

Use a second gyro if possible and tilt it on its side to measure if you are flat. Or use the accelerometer. Or ultrasonic sensors to measure the barriers between defenses. There are many ways to do this with many different sensors.

Encoders?

[nstephenh]

Originally Posted by AWoL

Encoders?

Encoders aren't going to work with rough terrain/rock wall/ramparts/moat unless you have a robot with treads that goes over them slowly like a tank because you lose contact with the ground and have a free-spinning wheel that's still counting up inches.

[lorykzarr]

Originally Posted by bdaroz

Let me ask a rookie team question....

Our autonomous is strictly time/heading based as we only have the FC Round 2 Gyro to use. We've timed our bot over distances to get an approximate ft/s speed and use that to run our auto.

Given that we have to add a "fudge-factor" to get over some obstacles, how do you suggest we accomplish breeching and guaranteeing we don't hit the tower wall? (And no, we don't have the money for an IMU - I tried.)

(FYI - we won't be able to test any of our autos until Thursday this week, robot got bagged before we could.)

854 tested and determined approximately how long it took to get over the more difficult defenses in auto in about 5 minutes total. Then we just adjusted our auto depending on what we were doing.

[Abrakadabra]

Originally Posted by nstephenh

... Our autonomous reads values from the Dashboard via Network Tables for an autonomous (do nothing, drive, drive and aim, etc) and a distance to travel. At some point the robot stopped reading these values at the start of auto while on the feild (expect another post about this tomorrow). We don't know why; It worked just fine on the practice feild, and we tested multiple times....

Thank you for the detailed explanation. I feel your pain on the flaky Dashboard readings. We too were struck with this bug in Week One - several times the autonomous just didn't run at all, even though the drivers swore it was selected on the SmartDashboard. It seems there may be a timing issue, whereby you have to wait until your DS is connected to the field before you make any Dashboard selections. We're just hoping it gets figured out before our next event in Week Five.

[Abrakadabra]

Originally Posted by nstephenh

Encoders aren't going to work with rough terrain/rock wall/ramparts/moat unless you have a robot with treads that goes over them slowly like a tank because you lose contact with the ground and have a free-spinning wheel that's still counting up inches.

But most teams have all wheels on a side driven by the same axle either via chains or belts, right? So unless you have independently-driven wheels (with an encoder on only one of them) or unless you catch a lot of air during your crossing, chances are that the encoder readings will be reasonably accurate. Not perfect, but good enough.

[kmodos]

Originally Posted by Abrakadabra

But most teams have all wheels on a side driven by the same axle either via chains or belts, right? So unless you have independently-driven wheels (with an encoder on only one of them) or unless you catch a lot of air during your crossing, chances are that the encoder readings will be reasonably accurate. Not perfect, but good enough.

We have wheels connected by gears yet still have incorrect encoder readings due to slippage. Encoders are far from perfect. There are many other sensors you can use instead.

[VacioArconte]

Autonomous wall banging should not be penalized - autonomous is hard enough as it is, and the wall can certainly take a hit.

Teleop wall banging should be penalized - first with a warning from the head ref, then a yellow, then a red.

Red cards should not be given out lightly - FIRST is about inspiring students, and getting a red card is a mighty quick way to un-inspire students.

[Abrakadabra]

Originally Posted by VacioArconte

..Red cards should not be given out lightly - FIRST is about inspiring students, and getting a red card is a mighty quick way to un-inspire students.

Yes - please tell that to all the refs who *inconsistently* handed out red cards last year (including one to my team's human player) for doing something relatively trivial involving the chute door. I can assure you it was a very big deal to him.

At least in this case it would be for dangerous operation of your robot...

[GreyingJay]

Originally Posted by Abrakadabra

Thank you for the detailed explanation. I feel your pain on the flaky Dashboard readings. We too were struck with this bug in Week One - several times the autonomous just didn't run at all, even though the drivers swore it was selected on the SmartDashboard. It seems there may be a timing issue, whereby you have to wait until your DS is connected to the field before you make any Dashboard selections. We're just hoping it gets figured out before our next event in Week Five.

My team opted for a hardware solution as we have heard a few horror stories like this before.

We installed this on our robot:

http://www.robotshop.com/en/rotary-e...module-v1.html

Using the analog input we can read 12 discrete positions which we are using to select our auto mode. There's no way to specify parameters as in a Dashboard solution but so far we have managed without. We could always install more switches

[AWoL]

Originally Posted by nstephenh

Encoders aren't going to work with rough terrain/rock wall/ramparts/moat unless you have a robot with treads that goes over them slowly like a tank because you lose contact with the ground and have a free-spinning wheel that's still counting up inches.

Have you tried them? With the fairly-standard drive train we're running this year (we haven't revealed yet, so can't say much) I'm doing motion control over the defenses with encoders and that's been working fine; I have not seen any egregious loss of telemetry on the defenses.

Originally Posted by Abrakadabra

But most teams have all wheels on a side driven by the same axle either via chains or belts, right? So unless you have independently-driven wheels (with an encoder on only one of them) or unless you catch a lot of air during your crossing, chances are that the encoder readings will be reasonably accurate. Not perfect, but good enough.

Precisely.

Originally Posted by kmodos

We have wheels connected by gears yet still have incorrect encoder readings due to slippage. Encoders are far from perfect. There are many other sensors you can use instead.

What other sensors are you going to use to easily get distance information?

[TDav540]

Originally Posted by Abrakadabra

A Yellow card is meant to be a warning - there is no immediate penalty, but it is a strong incentive to not do it again. Giving an "extra strike" as Greying Jay suggests would be difficult to track unless FIRST goes to a 3 card system.
I am of the school that believes no code should be run on the field unless it has been duly checked out on the practice field, and if that can't be done before a match, then you just have to forego the potential auto points until you can. Of course, there are always things that can go wrong due to unforeseen special circumstances (see 3467's whirling dervish can grabbers from last year), but the Yellow card warning would be a strong incentive to figure out why it happened (as we did) and make sure it never happens again.

This is where I have to interject. To start, my opinion on this issue: If it's a repeated autonomous, the head referee/lead FTA should ask the team to investigate other ways to deal with the situation, possibly even going as far as to make recommendations himself/herself. Additionally, they should also expect, but not require, the team to investigate help with it's autonomous. While I don't believe that teams should run into the wall in autonomous, I don't find it a serious enough issue (especially with velcro on the driver station) to warrant a card.

Now to my point: not every event has a practice field, and not every team has/can afford sensors. For example, there was no practice field at Columbus this past weekend. In this case, teams did not even have a chance to test autonomous modes. Additionally, there were a couple of teams that had autonomous modes that ran into the driver station. These teams were generally rookies. While I'm not saying that all rookies cannot afford sensors, many cannot. As a result, I do not feel like there can be any expectation for teams to not run into the driver station wall in autonomous. The rules cannot change just because a team is a rookie; what is applied to one must be applied to all. Would I like them to test it? Of course, the less violent, the better for everyone. But I don't think it should be required.

Tele-op, however, is rather straightforward; if a team continues to hit the driver station, a red card is completely warranted.

[orangemoore]

All actions have consequences.

Regardless of intention, if you prevent another team by your direct (including autonomous) actions from playing to their full potential you deserve a penalty.

I find it difficult to believe that anyone on the receiving end of a direct hit that stops them from playing would being okay with a team not getting any type of penalty. It wouldn't be fair to the team affected.

What that penalty is debatable. I think a combination of a Foul and a yellow/red card if repeated or egregious.