Creating a class for a new piece of hardware

[F22Rapture]

How difficult would it be (and indeed would it be possible) to be able to handle this proximity sensor?

http://www.automationdirect.com/adc/...s%29/AE6-AP-4F

Our robot was designed by non-programmers... using hardware for which no prior FRC software exists, which I'm not even sure can be handled electrically by the hardware we have available to us. I'm balking at the idea of having to write a class to handle this plus everything else in 2 weeks by myself (I'm the only programmer), but like I said I'm not even sure it can be done.

Here's the relevant details:

Inductive proximity sensor, 8mm diameter, short body, extended range, 10-30 VDC, 3-wire, PNP, unshielded, 4mm nominal sensing distance, normally open output, 3kHz switching frequency

If it's not workable, which I assume it won't be with only 2 weeks left, I need to know so we can adjust our absurdly and needlessly complex design asap.


Which brings me to a second question: if it isn't possible, can we use ultrasonic sensors instead? It has to be able to sense the head of a screw to within a couple of millimeters of accuracy.

http://www.andymark.com/product-p/am-2434.htm

Vertical accuracy I'm not worried about because that sensor should have 1mm resolution, however, I'm not sure whether the cone of detection would be small and precise enough to only detect the screw within an acceptable range. Distance between the sensor and the screw will only be about 2-4 millimeters. Can ultrasonic sensors even operate effectively within that range?

Thanks,

Daniel A

[DonRotolo]

Neither sensor needs its own class.

The first can use a digital input, the ultrasonic (which won't do what you want) uses an analog input.

Think of the inductive sensor as a switch - it is either on or off. Just using a transistor, not an actual switch.

How about sensing your screw head with an actual lever-type limit switch instead? Or a magnetic reed switch?

[F22Rapture]

The belt is going in both directions, so a limit switch would get caught.

Where on the Sidecar would that be attached?

[toastnbacon]

What are you trying to do? You would be amazed at all the problems that can be fixed in programming.

[MrRoboSteve]

Limit switches go to the digital inputs on the DSC. We'll probably have 10 on our robot this year.

[DonRotolo]

Originally Posted by F22Rapture

The belt is going in both directions, so a limit switch would get caught.

Even one like this?

[F22Rapture]

Originally Posted by DonRotolo

Even one like this?

Perhaps not, but I don't think spending $190 on a limit switch is a good use of our somewhat limited resources.

I will add that you have to be careful using these sensors. We used them as limit switches on our arm. Towards the end of the match on more than one occasion while many of our motors were on, our voltage dropped below 10 volts. As a result the sensors were no longer powered and our arm was able to over extend.

That shouldn't be a problem in our use case. The lift mechanism for the frisbees itself has a KoP photoswitch (from 2011) on the top and bottom to prevent it from allowing a frisbee to go too far in either direction. This sensor is only for determining the position of the lift by picking up on screws on it they passes by.

As Alan mentioned if it was NPN you could just use a DIO and they do have an NPN version AE6-AN-4F (replace the AP with AN in the part number) Thus when the switch is closed it will be sinking the DIO to ground, when the switch is open there is a built-in pull up resisitor in the sidecar which pulls the DIO high by default.

So if I'm understanding you correctly, that sensor should work without any modification (ie. resistors and/or code workarounds) whatsoever?

Thanks, I'm emailing this to our mentor.

[DonRotolo]

Originally Posted by F22Rapture

I don't think spending $190 on a limit switch is a good use of our somewhat limited resources.

"like" that, not that exactly. Surely you can find a $2 limit switch and make it work like that? Oh, NVM, you're a programmer...

My point was that there may be hardware out there of which you are unaware, that will solve your problem for a lot less complexity and money than that prox sensor.

[inkspell4]

You could also use a light sensor. Such as:https://www.sparkfun.com/products/9088

[Alan Anderson]

Originally Posted by F22Rapture

Inductive proximity sensor, 8mm diameter, short body, extended range, 10-30 VDC, 3-wire, PNP, unshielded, 4mm nominal sensing distance, normally open output, 3kHz switching frequency

The PNP part makes it harder to connect to a FRC robot. If it were NPN instead, it could be wired directly to a Digital Input. As it is, you'll need to add some simple circuitry to reduce the output voltage to something that a Digital Input pin will handle, and to pull the signal low when the sensor is not active. It's just a couple of resistors; I think a 5k from the DIO signal pin to ground and a 7.5k from the DIO signal to the sensor output should work.

[GrimmReaper]

As Alan mentioned if it was NPN you could just use a DIO and they do have an NPN version AE6-AN-4F (replace the AP with AN in the part number) Thus when the switch is closed it will be sinking the DIO to ground, when the switch is open there is a built-in pull up resisitor in the sidecar which pulls the DIO high by default.

So high the switch is Open, Low the switch is closed. Just use the DigitalInput class and you should be golden...

let us know if that works for you.

[kylelanman]

Originally Posted by F22Rapture

Inductive proximity sensor, 8mm diameter, short body, extended range, 10-30 VDC, 3-wire, PNP, unshielded, 4mm nominal sensing distance, normally open output, 3kHz switching frequency

The past two years we have used sensors very similar to these. Not realizing it at the time we ordered PNP. I don't remember the value off the top of my head but we just needed one pull-up resistor for each sensor and they worked great.

I will add that you have to be careful using these sensors. We used them as limit switches on our arm. Towards the end of the match on more than one occasion while many of our motors were on, our voltage dropped below 10 volts. As a result the sensors were no longer powered and our arm was able to over extend.

The first couple of times this happened we the programmers got blamed very quickly. It wasn't until later we were able to deduce what happened.