# Why not analog sensors??

I am frustrated by the nearly exclusive use of digital sensors in the kit – sensors that output either 1 or 0. The Banner sensors are like that, and the IR sensors in the trackers are like that. Why not analog?

Some may think that “1” or “0” is a much cleaner, noise-free signal than an analog signal, but it is nearly information-free as well!

I know one team used constant tracker hunting to get a better idea of the direction of the IR, and that is a great solution given one-bit sensors. But if each tracker’s IR sensor put out an analog value proportional to the “brightness” of the IR it was seeing, then small pointing errors could be determined as the difference between the values, without having to hunt back and forth with the servo. Integrate the sensor difference and apply to the servo – or something like that.

If two analog line sensors were pointed, “defocused”, at the left and right edges of the line such that the output was a measure of how far off the edge the sensor was, then, again, the small error signal would be the difference of the sensors. Negative means “too far left”, positive means “too far right”, and zero means right on.

Yes, the outputs would have some noise in them – that’s part of the fun, filtering out the noise.

I think part of the reason that the gyro approach works well is that it gives an analog measure of the error.

Thats good enough for me

Except that brightness would also vary by the distance your robot is from the beacon. So, if you read a value of 120 from your analog light sensor, does that mean you’re pointed right at it but 20 feet away, or does it mean you’re right next to it, but pointed 45 degress away from it?

If two analog line sensors were pointed, “defocused”, at the left and right edges of the line such that the output was a measure of how far off the edge the sensor was, then, again, the small error signal would be the difference of the sensors. Negative means “too far left”, positive means “too far right”, and zero means right on.

Do such sensors exist? If they do, you could always buy them as a custom electronic component and use it - you’re not limited to just the sensors provided in the kit. I’d be a little surprised if something like this really exists, though (at least something that would work for this application).

For the most part, regarding the kit, FIRST operates on a two-part plan: 1) what’s cheap, and 2) what’s free. Maybe it was neither to acquire analog sensors which perform the same functions as the digital sensors we received. If you want to use analog sensors, you can, but I don’t see any reason why you should be complaining about what was provided in the kit.

It’s not like FIRST is getting kickbacks from the digital sensors industry…

digital sensors are also easier for novice teams to use, whereas analog sensors are harder to implement algorithms for. there’s no restriction on getting more complicated sensors, but FIRST also probably wants to provide newer, more inexperienced teams with things that are simple to use.

the cheap/free argument is also quite valid.

You’re free to sample the ones and zeros with an A/D as they zip in :).

You’re kidding, right?

How would you discriminate against all of the other sources of 940nm infrared? Would you use a different wavelength for the other beacon?

There’s nothing preventing you from doing this. Radio Shack carries infrared phototransistors.

sigh

-Kevin

Not at all, I was thinking “information theoretically”. One bit is the smallest amount of information. 10 bits is a lot more. Now, it also depends on bandwidth and noise, and if the one-bit case is fast enough, you can get a lot of information.

How would you discriminate against all of the other sources of 940nm infrared? Would you use a different wavelength for the other beacon?

I was thinking of using, say, a 40 kHz beacon (CW, not pulsed) and have another frequency for the other beacon, say, 33 kHz. The rub is that to implement the dual-tracker system I think you would need eight sensors instead of four (four for each beacon frequency). \$\$\$

There’s nothing preventing you from doing this. Radio Shack carries infrared phototransistors.

Lack of time prevents me, at least in a 6-week build cycle. Maybe I can play with this in the off season. sigh…

BTW, I’m here at the regional in Trenton, NJ, and when I asked which beacon was “1” and which beacon was “0”, I got some pretty blank looks. I said, “You know, the IR beacons for IR tracking?” More blank looks. They found someone from IFI who made a few calls and learned that “this” beacon is connected to pwm01 and “that” one is on pwm02.

But I still can’t get it to work. Tomorrow we will have our test beacons, so maybe we can get some answers. It’s pretty hard to debug with only one run every 90 minutes, with no telemetry, just observing the robot from the stands about 200 feet away! :ahh:

sigh

Exactly.

-Norm

You would need two sensors (just like Kevin’s tracker setup). The ratio of the difference to the sum (left-right)/(left+right) would indicate the off-angle-ness: if they have equal outputs, it’s pointed straight; if the left is larger, it’s pointed right; right larger means pointed left.

Or something like that.

Do such sensors exist?

Dunno. I imagine that the internal processing of the sensors in the kit generates the signal I want. And then they run it through some threshold to throw away most of the information(!) and output a 1 or 0.

The IR sensors are used because they are standard and readily available. All IR receivers in home electronics equipment are (almost) identical to these. They have quite a lot of circuitry in them (they just look small :)) so they filter out the noise and decode the binary signal. In my opinion these sensors are much more reliable than those that would depend on brightness. What if someone takes a picture during autonomous?

I personally believe that “Yes” or “No” is sometimes better and much more useful than “well, MAYBE, but, well, I can’t REALLY tell, it’s kinda sorta”…

using two digital sensors is, in tandem, rediculously useful. Think about your eyes – look at an object… if you close your left eye and can see it, check your right eye – if your right eye can’t see it, you need to turn left…
when you can turn left and see it, and you can see it with both eyes, it’s in front of you…

once one eye loses sight, re-evaluate and adjust.

I’m not sure what the point of this discussion is

Sensor choice obviously depends on the application, and I think that FIRST lets you use just about anything you want. In the kit, well, FIRST gives us what they give us, and from what I’ve seen it’s decent stuff that is pretty easy to use. Beyond that, as long the sensors you want to use are legal, then use them

Sometimes Digital makes sense (Encoders, bumpers, IR finding) and sometimes it doesn’t (Position, Air Pressure, current). Basically, you ask “Do I need 1024+ values, or do I just need to calibrate and have a above/below return?”

As has already been said indirectly several times, what’s wrong with a simple signal with a simple algorithm? Sure, it’s really fun to make a complex algorithm that works, but in the real world, the simpler things are, the less likely they are to fail and the easier they are to maintain.

Linux is an example of this. It gives you complete power; you can delete anything, access kernel memory, change kernel memory, etc. It lets you do anything, but if you don’t know what you are doing, you can easily break it. (assuming, of course you are admin; users are a different story.) Windows on the other hand, doesn’t let you do that. It pretty much protects you from stuff that you can do to break it. (It lets itself break itself, but again, another story) The banner sensor are the same way; you don’t have as much power, but they protect you from interference from anything other than what you actually want.

The irony of your analogy, Texan, is that it’s a lot easier to bring down a Windows machine than it is a Linux machine (assuming non-root accounts on both sides, of course)

using two digital sensors is, in tandem, rediculously useful. Think about your eyes – look at an object… if you close your left eye and can see it, check your right eye – if your right eye can’t see it, you need to turn left…

Errrrr… That is nice and all but your eyes resemble analog sensors more than digital. Also your analogy starts to break down when you actually think of the consequences when you loose an eye. You pretty much loose any ability to tell depth. Anyway the rules pretty much prevent the use of most if not all decent analog sensors.

It’s the idea that counts.

It’s the engineer’s impulse: We do it because we can, not because it’s pratical.