Design review (calibration)
Final step in the coin detector challenge. Created by Brit Cruise.
Want to join the conversation?
- The coin detector very helpful to find coins......(4 votes)
- I personally think that it's more helpful to know what kind of coin you found than finding coins.(3 votes)
- so if the coin is smaller it will cause more digrees?/(3 votes)
- Yes, more from where your 0 degree is. The larger, the closer, the smaller the angle.(2 votes)
- could you modify it so that the moter moves to hit the coin and were is stops to say true or false and when false ejects coin and when true takes coin?(3 votes)
- so the smaller coins cost more digrees?(2 votes)
- Can you send me this lego?(1 vote)
- what version of adobe photoshop are you using to draw the diagrams?(1 vote)
- where could you get the programming software(1 vote)
- what program do you use cuz i can't seem to find it(1 vote)
- Hi Britt So far I have loved all of your cryptography and Lego robotics videos. My question is that can you wire the NXT so that it can detect many coins??
- Maybe you could elevate the motor and attach a light sensor on the bottom then the robot could detect the varying brightnesses and colors of the coins this would actually be rather easy to do with an ev3 as the light sensor is very precise and has many more options(2 votes)
So far, you have a beam attached to a motor in a simple program that generates a tone-- a high pitched tone if it's somewhere between 100 and 200 degrees. And if it's anywhere else, it generates a low pitched tone. So let's modify this to make an actual coin detector. Let's say you have a hard stop here, some piece of plastic or a beam, that doesn't move so that you can lie a coin-- let's say this is coin A-- on the surface. And as you rotate the motor, the beam will eventually hit coin A. And it will have rotated x degrees. Remember, we have our rotation sensor inside the motor. We'll say it's reading x at all times, where x is the position of this beam. And let's say, for example, coin A is that 91 degrees. Now, if we're thinking like a robot, we don't actually see the coin. The only thing we see is this number. So for the robot, 91 degrees is somehow representing coin A. And if we put in a smaller coin, this beam will rotate further down, and it might register 98. So the robot will know, oh, we're in 98. This is not the correct coin. So the problem here is to basically squeeze your range to be some tiny slice here that represents coin A. And it won't be one reading such as 91 degrees, because there'll be a tiny bit of variance here. It could be 91, 92, or 93 degrees, perhaps. And this all depends on your system. You have to figure out what this range is. So if it's inside this little slice, we'll call it range A. And if it's anywhere else, it's our reject region. So this'll be our accept region, think of it. And the rest is our reject region. And to make this work, you need to modify your program in three ways. We don't want to generate a tone in real time as before. We want to actually wait for the user to put in their coin and rotate the motor. And then the user will hit the orange Enter button. So that means you're going to introduce a wait block inside your infinite loop. So it will wait for the user before it goes and plays a tone. And after the user presses the orange button, you will either generate an accept or a reject sound file. So don't generate a tone. It needs to be meaningful, such as yes or no. And the third step and the main engineering problem here is to figure out what the range is for your system. Remember, this is zero, so you're going to have to pull your sensor and experiment a few times to figure out what is your range for, say, a five-cent coin, and change your range values inside your existing range block. And if you do these three things correctly, you should have the following working coin detector.