After being frustrated by inconsistent calls on ramming, I came upon an idea. I think someone might’ve posted this earlier, but not for this purpose.
Why doesn’t FIRST mandate that shock sensors be installed on all robots? Something as simple as this or as complex as an accelerometer would do it: FIRST could monitor and see if an offending robot has triggered the sensor. Then, all ramming calls would be consistent and fair.
Any thoughts?
JBot
Wouldn’t the shock sensor go off on both robots during a ramming incident?
Would the speed (momentum) of the robot being rammed unfairly factor into the shock of the ram?
Couldn’t you just ram into a wall and set off your own sensor?
Yes, but it will be obvious to refs which bot did the ramming. The sensor would be there to verify the call.
Yes; this strategy might not work just because of that. A penalty should not be called just because the sensor went off–some discretion would be needed, but less than what is needed now.
Yes, but the refs would see that; like I said the penalty should not be called just because the sensor went off.
Maybe it isn’t the most solid idea, on second thought…but maybe.
JBot
It’s a fun idea, but there are some serious implementation issues.
If that sensor is controlled via the RC and radio link, then that means it has to interface with them. That interface needs to be inspected, to make sure that it is operating correctly. (For example, teams plug their Nason switch into the wrong ports all the time.) If that interface depends on code, then there is an additional need to make sure that that code is in place, and being called at the appropriate time. (Again, consider the Nason switch, which needs a line of code to trigger the relay.) These things would probably have to be considered during inspection, but unlike the pressure switch, this device would have the ability to trigger a ruling against an opponent. That means that the stakes are considerably higher. As a matter of practicality, the inspectors can’t take the time to continuously verify that every team’s Nason switch is being used correctly; if someone wanted to cheat, all they would need to do is disable the line of code. But that sort of action has a relatively small consequence—pretty much negligible, in the grand scheme of things. Contrast that with the sensor proposed here: if that’s tampered with, a team might very well have the ability to press the switch on their joystick, and transmit a duplicate signal to the RC and radio, pretending that they’ve been hit severely. I’d love to think that nobody would do this, but if they did, the consequences of that ability would be enormous. Afraid of losing an elimination round? Just run into an opponent and send the fake signal. That dramatically increases the likelihood that they’ll be assessed a card—and will weaken their resolve to defend against you in the next match. Even if no tampering occurred, how would the officials verify that the telemetry was accurate?
I guess it might be possible if IFI provided some way to plug the kit accelerometer directly into the master processor. The firmware could handle the accelerometer and indicate a hard hit via the debug light (I’m trying not to use new parts accept for the pins on the RC).
However there still would be problems with calibration and making sure teams don’t bypass the accelerometer. There also would be the problem of bumpers lessening the impact.
It could work as an indicator that could combine with a ref’s judgment, but I am afraid some may become too reliant on the light
I don’t know how you would go about finding a way that was absolutely fair. No matter what they come up with, there are going to be flaws. I didn’t hear the refs calling many penalties on ramming, if at all. There were a few, but I personally think there were many more instances in which there could have been a call made on being a little over-aggressive.
Wasn’t there something about intentional ramming? I don’t remember, but I think that it is clear who is purposely out there to tear you up, and who is just trying to prevent you from scoring. It’s a tough call. I don’t think there really is anybody who’s sole purpose of building their robot is to destroy all the others. That wouldn’t be displaying gracious professionalism.
I think this will always be a problem; it’s one of those things that is really prone to human error. Our eyes can’t analyze each situation and the impact on each robot. Although…it would be pretty amazing if we could.
On the other hand, some sort of shock sensor in the kit would have been pretty neat for autonomous this year. Drive towards the rack until you hit it then hang a ring.
By special request, FIRST would ship any team an accelerometer and yaw rate gyro for free; the accelerometer gives you an analog value based on how much acceleration it is under at any given time. This could be used as a “shock sensor” the way you describe.
Yeah, my idea was fun to entertain for a little while…I see why it can’t really be implemented. However, it is a fun idea to store all of this data on a dashboard computer. I just might have to try that…
JBot
How could you verify it? Isolate it from anything the team controls.
In the inspection checklist, require teams to provide a horizontal 3/4"x1.5" strip of the loop side of Velcro. In the queue, along with their flag, they receive the Ram-O-Meter, which is powered by its own AA batteries independent of the robot and conveniently has 3/4"x1.5" of hook-side Velcro. They attach the Ram-O-Meter in a visible location, run the match (with a slow, yes-it-works flash until a ram, when it goes solid for a few seconds), and hand it back with their flag as they leave the field.
I’m not saying it’s the best solution, or even if it is an actual solution, but there’s a way around the teams.
Refs tend to catch high speed ramming when it happens.
Honestly, I don’t see it as a problem. Unless you make your robot out of cardboard, no 120 pound robot going 9 ft/s is going to damage it all that much.
Robots lived through 2003, they can live through all of these games as long as the teams continue to make them sturdy. We used the kit frame in 2005, there were quite a few hits to us and from us. That robot never broke simply because we were hit. Being tipped is a different story.
We’d drive, full speed, into the wall at the human loader zone. Is that not similar to another robot slamming, full speed, into another robot?
If a team does some high-speed ramming and a robot falls over, then something else can be discussed. At this point, high-speed ramming shouldn’t be breaking robots.
I’m not saying your idea is bad. I’m just saying it’s not necessary.
It’s similar, but it’s not the same. If your robot gets rammed from the side, the wheels take loads they’re not intended to handle. If you get hit by one corner of a fast-moving robot, the impact is concentrated at that point and can definitely dent or bend a non-cardboard frame. Bumpers help, but they can’t prevent being damaged by a too-hard hit.
In order to end the ramming debate, forever, one of two things must happen.
We play Xv0. (And people will complain about how boring it is)
There are NO contact penalties. (And people complain about how they got got beat up)
Regarding an electronic solution, I’d be against it. It seems like there would be too many “what-ifs”, or people complaining about how it didn’t work correctly. I’d much rather leave things in the hands of an experienced ref crew. There should be enough refs that stick around, so that every regional can have an experienced crew. At BAE, no ref had less than 3 years of FRC reffereeing experience. Things were uniform and fair. Why is that so hard to replicate across the country? (Not the 3 years, the uniform and fair)
And if you give a wheel too much side load, it can lose its hub. That’s how we break wheels on our practice robot–lots of run time plus a little too much side load=hubless wheel.
Also, you ram your robot into the wall. Let’s say that your robot travels 10 ft/s. (just a realistic, round number) Now, let’s say that you have two such robots and they meet head-on at full speed. That’s the same as hitting the same wall at 20 ft/s, plus a bit. I’ll let you do the math (force, impact, energy, whatever), but if your robot can’t handle that, it can’t handle the somewhat faster speeds it’ll see coming its way on the field.
I think a ramming sensor is a good idea–it’ll give the refs an idea of where the rough play is happening and who is doing it–but it’ll be tough to implement easily separate from the RC. It should be provided or easily built if one is used. Requirements might include:
Or you can build a small accelerometer into the Robot Controller itself…
If anyone’s ever voided their warranty on their controller and opened it up to peek inside, there seems to be enough space in there for at least a small breakout board sized accelerometer.
While an accelerometer may help to determine high-speed ramming calls, it won’t help for things like pinning or egregious/overly-aggressive driving. While comparing the spikes in the gee forces from one robot to another might help determine which robots did in fact make serious contact, it would still be up to the referees to determine which was the offending bot.
If none of the referees saw the incident take place, there is no way for them to know which was the offending robot based off the accelerometer data alone. Having on-board accelerometers would only help the referees to decide if some “borderline” hits were considered fair play or egregious behavior.
That’s actually not how it works. A wall is assumed to be immovable, so running into it at full speed is effectively the same as two robots running into each other head-on at that same speed. In reality the alliance station wall will react a bit and absorb a little of the impact, but so will the second robot’s bumpers, so it still comes out about the same.
I would see this device as an advantage. As a defense robot, the refs would be especially looking out for our bot during matches (after they got to know us and our bot and our driving style (BTW I’m talking about regionals))… They would claim that if we started 10 ft. away from a robot, and hit it without stopping in between, this was a penalty. The team’s argument was that the bot was in no way going full speed. It is a major time problem to go, stop, go, reverse, wait, go, stop, etc… just to block a team from scoring and not get a ramming penalty. If you must be within 3 (or 5 or something like that) ft. to hit another bot, but must be more than 3 ft. away after 10 seconds, this means a lot of starting and stopping. The light would help us in the sense that it could prove that we aren’t hitting at full speed, and are simply blocking at a speed that is non-damaging. I don’t think that any damage was done to ANY bot that we got a penalty for ‘ramming’ against.
Just a thought. So I say ‘yay’ to the sensor. As far as implementation, I see built-in to the RC as the most viable. This way, it will force teams to more securely mount their RC, at least if they want the hope of getting a ramming call awarded against the opposing alliance. Then, if a ref sees a situation that they would like to call ramming, they need a thumbs up from the IFI guy saying that the accelerometer limit was breached on the victim bot (remember, the opposing ‘defense’ bot may have the opportunity to not have the RC securely fastened. I think that the victim bot needs to have complained about being hit.) Using this system, you really could set a threshold as to what is 'too hard. This doesn’t rely on speed or distance or anything else that may be subject to quick calculations by the ref. It is based on pure hitting force, which is what this rule is intended to defend against (no pun intended).
So I guess what I’m saying is that this device would not necessarily catch cases where ramming occurs that the ref may not see, its more to defend the defense robots against unnecessary calls.
My 98 cents short of a dollar.
Jacob
We’ve discussed implementing an anti-ram circuit on our bot using IR, ultrasonic, or another ‘proximity’ sensor to monitor the closure rate and just preventing our bot from being able to committing them. Prevention instead of detection. The big problem we had was coming up with the metrics to define high speed ramming, but I hear that IRI uses > 8ft/s for more than 2 bot lengths. It doesn’t help you argue if someone rams you, but it simplifies one more thing for the driver that can get you into trouble.
<sucking up>
The planning committee for IRI really seems to be quite wise with a solid ramming definition like this. Hey, haven’t they been using a yellow/red card system for a few years? What other wisdom (i.e. awesomeness) do they have to share with us this year? I hope I get to find out. 
:rolleyes:
</sucking up>
Mark
My thoughts on this are a bit different. Robot to robot contact is something that can’t be avoided, even alliance partners smack each other on occasion.
What about a game/games that completely eliminate physical defense between opposing alliances. All defense would have to be strategic and/or tactical in nature. Games that would require a lot more intra alliance cooperation and interaction.
With everything the GDC already has to do to make these games as awesome as they already are, this would be a HUGE redirection. One that would not make their work any easier.
Just some food for thought.
Just a thought …
Why not just limit the top end speed a robot can go?
Robot interaction is gonna occur, that is for certain.
And, detection methods are okay, but prevention is even better.
I don’t know what the limit should be, but surely some smart person could come up with a way to use accelerometers in conjunction with the speed controller on the drive wheel motors, to set a high end limit.
I know that we can’t really equate power with speed, but I think it would be something that could be looked at.
Sorry if this has already been suggested - I didn’t read all of the posts (my bad)
Mike Aubry
If they could somehow use a sensor, that without any interaction of the mechanical or drive parts, could report the robots speed to the refs, that would be an ideal system.
So, if ramming is considered 10fps or greater, and you hit at 9 you’re fine.
A light could go on when you are “speeding” so the refs know when to call it.