Optical sensors getting tricked
 

In the last competition we had a number of IR and other optical sensors on our robot. Due to the halogen lights however, we kept getting a true when it shouldn't have detected anything. Are there any sensors that you guys use that aren't affected by them or how do you get around that.

Re: Optical sensors getting tricked
 

We usually use shading cones or recess the receiving sensor deeper into an enclosing project box to limit the amount of ambient light striking it.

Re: Optical sensors getting tricked
 

I do not have any ideas on how to shield against light, except to create an enclosure around the sensor. However, you could use some different technology, like hall-effect or mechanical::safety::

Re: Optical sensors getting tricked
 

People here will be better able to help you if you describe what you are trying to do with the sensors.

Re: Optical sensors getting tricked
 

we got around it by designing our robot so it doesn't need any sensors other than the compressor pressure switch. It's amazing what you can do with mechanical design, to eliminate the need for software

Re: Optical sensors getting tricked
 

Closed-loop programming is good enough for most cases. However, when you are building a robot that will be in a different scenario at most times, you cannot rely on closed-loop. Open-loop seems like it would be slower, but it would be trustworthy. Would you rather shoot 100 frisbees into the goal at a 60% accuracy, or would you shoot 60 frisbees and make all 60 into the goal? The latter would be more impressive because that is a 100% accuracy compared to a 60% accuracy of the first one. Also, these numbers above are sarcastic. It would be more of a 7-9 or 8-9 ratio of made goals.

Re: Optical sensors getting tricked
 

I don't see how open loop would be slower. It actually should be much faster than closed loop. In response to the OP we used banner sensors that could be tuned based on light.

Re: Optical sensors getting tricked
 

We had a similar problem in 2012 with sharp IR sensors from Pololu electronics.
http://www.pololu.com/catalog/product/1134
They are inexpensive and worked very well at first to control the indexing of the balls in our pick up. Between the 1st and 2nd competition we change the robot covering for a couple of reasons. That's when we started getting false positives. At that point for many reasons we could not go back to a robot covering that shielded the sensors. The human operator ended up being the controller. A tough lesson. So in the future we would use them again but design shielding in to the robot.

Re: Optical sensors getting tricked
 

Can you explain why you say this? It's pretty much the opposite of my experience.

Re: Optical sensors getting tricked
 

The robot will not be in the same place very often. It needs to adapt by itself to it's surroundings. Also, yes, open-loop can be faster, or it can be slower depending on how you tackle it. In the case that I was thinking about, it would take time to read sensors and joysticks, process that information and then move the robot. That would basically have very little impact, unless you are doing complex processing (like vision). So, you are right. The impact of speed would be very little.

Re: Optical sensors getting tricked
 

I still don't understand your previous post. You seem to be saying that closed-loop control is not capable of dealing with dynamic situations, and that open-loop programming is necessary in such cases. Again, that is completely opposite to my experience. Please tell us what you mean by open-loop and closed-loop in this context.

Re: Optical sensors getting tricked
 

I'm confused. A few weeks ago, you said:

You seem to be contradicting yourself.

Re: Optical sensors getting tricked
 

Microcontrollers can respond to input much faster than a human could. The lag in reading input is barely noticed compared to the time taken off repetitive tasks. For example closed loop code on a shooter could reduce down time between shots and increase reliability. This makes the action of shooting much faster.

Also, open loop relies on human feedback or constants. Humans make mistakes and constants aren't as accurate as battery voltage decreases. Closed loop properly programmed will always be better than open loop code.

Re: Optical sensors getting tricked
 

To address the open/closed loop control issue-
The confusion probably comes from the fact that the poster isn't too familiar with implementations of closed loop control in FRC. It's really hard to make blanket statements about one method being faster than another, or one being more reliable than another unless you have spend a significant amount of time working with both.
I do agree that a well-written closed loop control (PID, bang-bang, take-back-half...) is much superior to an open loop version, but in some cases, a team with little programming resources may not need to have PID control on their arm, but instead have two end of travel limits.
My recommendation to the poster is to spend time in the offseason experimenting with different control methods before commenting on their effectiveness.

As for the optical sensors, our team uses the banner IR sensors. We've used them on our drive wheels, our shooter wheels, and to detect the bump in 2012. We've found that with high speed control, we'd sometimes see that the speed reported would get cut in half when we went to competition, due to false positives. We fixed this by making sure that when we did high speed sensing, the black and white parts of the shaft that the sensor looked at were equal lengths. This makes it harder for the sensor to skip over one of them and report the incorrect speed. We also turned down the sensitivity as far as it would go without loosing the signal.

Re: Optical sensors getting tricked
 

PID is quite required, to my opinion. Last year (2013), our robot did well, but the shooter wasn't consistent because we didn't have a way to measure the shooter speed. We would just place the shooters at 100% power and shoot from the same place. Programming a consistent robot closed loop can be hard because you need to calculate the motor speed using the hundreds of variables, mostly:
-battery voltage
-motor life
-controller life
-load on motors
-bearing stress
-multitudes of other variables
Yes, you could use vision so that the robot can determine whether the disk went into the goal. However, that would be hard because there is a small slot of time where the disk would show the greatest proof of position and landing. Encoders can be a life-changer when you want to want to have a very accurate robot while remaining simple.

Re: Optical sensors getting tricked
 

Not only is PID not required, you do not need hundreds of variables. A bang-bang shooter algorithm is incredibly easy to program(it's an if statement, if your programmers can program the robot to shoot they can program bang bang). Furthermore it only needs an encoder/ir sensor(we used banner sensors) to feed it RPM. As long as you know the speed of the wheel you don't need to account for any other variables.

For position PID is great. Though we haven't used it before, I have heard that limiting the controller to PD or just P is still a pretty darn effective motion controller.

To sum up, sensors don't have to be complicated. Even with complex code(like vision code) teams like 341 have made it much simpler and easier for the rest of us.

Re: Optical sensors getting tricked
 

The above makes no sense. I think perhaps you are misunderstanding what "closed loop" means.

Re: Optical sensors getting tricked
 

Perhaps I should take a stab at explaining exactly what it means as we're referring to it...

...And reducing the variables (very few of the ones mentioned actually apply in closed-loop control).

Actually, I'll start out with: The only variables listed that would have ANY effect at ALL on, say, a shooter, would be the battery voltage (which really only affects open-loop controls--unless it's totally dead) and the load on the motors (they do have to take a bit of load when the disc goes through--but that's why you have closed-loop control). All of the others have no effect on the control system, or should have been dealt with in the design of the robot (like bearing stress--just get a bearing rated for the load, don't worry about the bearing stress).

Closed-loop control goes something like this: The cRIO sends a command to the speed controller to have the motor go speed X. The controller boosts the motor to speed X (as the controller sees it) by boosting power. A sensor on the shooter wheel indicates speed and sends a signal to the cRIO indicating the actual speed. The cRIO then compares the actual speed to the set speed and then tells the controller to increase power, decrease power, or keep the same power.

cRIO->Controller->Motor->Sensor->cRIO->Controller...

The program could look something like:
speed = 100
if (sensor < 95)
//speed increase
else if (sensor > 105)
//speed decrease


An open-loop control, by contrast, goes:
cRIO->Controller->Motor

and looks like:
speed = 100

in code.

Re: Optical sensors getting tricked
 

I don't remember how many goals we made...but we did get high seed and won the Arizona regional :)

Re: Optical sensors getting tricked
 

This thread is starting to smell of a simplicity VS. complexity argument.

Re: Optical sensors getting tricked
 

Only problem with this is that mechanical problems are harder to fix at competition. At competition it is much quicker to fix a sensor or fix a peice of code than it is a mechanical part. Though if I may ask what sensor have the mechanical parts replaced?

Re: Optical sensors getting tricked
 

http://www.chiefdelphi.com/forums/sh...8&postcount=25

These with the polarizing filter are very tough to fool.

Re: Optical sensors getting tricked
 

This is a textbook bang-bang velocity controller with deadzone - definitely a closed loop system. What I came here to say is that while any control system has to control a setup that does indeed have hundreds, nay, thousands of variables, the magic of a closed-loop controller is that it will compensate for either not knowing them or knowing them badly - your classic open-loop controller assumes it has perfect information about its system, and that the system itself is perfectly modeled by your controller; it has to, since it has no feedback from the system it is controlling. The trick is, in order to actually get a perfectly modeled system, you DO have to consider all those pesky variables, or just tune it for a particular circumstance and pray it never leaves that island of stability. A closed loop controller can have a much rougher model of the system its controlling, and will magically find parameters that optimize its model (some of the really neat ones can even change their models to better adjust for different control regimes). Of course, you do have to worry about things like lag and complexity in your controllers, as well as having to sense things about the system you're controlling to provide feedback, but thanks to the better modeling abilities of a closed-loop controller, it can be operated much closer to instability, which increases the rate at which it converges to the desired output. In short - if you need speed and precision, go closed-loop.

Re: Optical sensors getting tricked
 

Our team has used many different sensors and controllers over the years. My favorite still is the organic analog computer coupled with a organic analog visions processor. Each year we put 2 of them behind the driver station physical connected to the driver station computer. Being an analog system the programming is very difficult. Training a neural net is very time consuming. This year we have devoted allot of resource to train our analog system. We went to ever off season competition we could. Got to train those nets.

Re: Optical sensors getting tricked
 

I have no idea what you're talking about, but the words 'neural net' have piqued my interests... You mean that you have a neural net managing your vision tracking, and that you have to endlessly test to train it?

Re: Optical sensors getting tricked
 

I think he's referring two a couple of students.

Re: Optical sensors getting tricked
 

whoosh

You have no idea how relieved I am :P I thought that FIRST programming had just sailed over my head and continued to evolve while I wasn't looking. My team was considering using an ANN last year, but we figured that the costs outweighed the benefits.

Re: Optical sensors getting tricked
 

The SHARP IR sensors can be GREAT if used in the right application, but here are my lessons learned.

• The version linked above is affected by long wire runs and supply voltage fluctuations. You can remedy this by putting a capacitor 'backpack' on the sensor, across the supply voltage pins (VIN, GND). I think we used soemthing around 300uF electrolytic cap. This significantly reduced our intermittent detections due to supply voltage fluctuation.

• There are quite a few different models of these sensors available, they are each tuned to work at different distances. Make sure you get the right sensor for the job. You need to know the minimum and maximum distances the object you are trying to detect will be from the sensor. This page has a good break down of ranges supported by different models.

• The larger versions that are mounted within their own plastic housing MUST be mounted so that the plastic is isolated from the chassis. I know it sounds crazy, but the plastic shroud on these is conductive.

Re: Optical sensors getting tricked
 

Huh, we have spent a lot of time at competitions trying to get electronic stuff working, and failed. Mechanicals are easy to fix....maybe because I'm a mechanical engineer, with 30+ yrs experience fixing stuff. I guess it's not what it's made of, it's what you know?

Our Ultimate Ascent robot was designed to not require sensors, it just does it's thing based on it's design. Autonomous just requires the robot to be placed where it belongs, and it shoots into the goal. Shooting during a match works by driving the robot into position and shooting...position being determined by parking the robot against the pyramid. Angles and positions are fixed by design, and the actuation is pneumatic, it's either up or down, no "in between" positions that would require sensor feedback to control.

We've spend days, make that weeks, trying to get sensors to deliver useful information to control robots over the years, and generally failed miserably at it.