Would The use of Sensors be better for autonomous mode or should we use a logical of at this speed our robot should be here can you help me with any suggestions thanx in advance
really, this is a decision your team has to make. Sensors provide information only, if you think you need that info, use the sensors. If you don’t need that info, leave the sensors in the box!
If you have the time to do it, I would suggest trying the sensors out on a basic chassis. Just see how they work and see if you can get it do what you want it to do.
The problem with trying to calculate how far your robot is going is how you’re measuring it. If you’re counting rotations of your wheels, then it’s very possible to get major errors. If your robot strikes something, and continues to go, the wheel that’s being measured may spin, causing you to get innacurate information.
However, if you had an extra wheel that was not attached to any drive system, you could use that to gather your distance info. SO if you had two rear wheels for drive, using one of the front wheels, or a fifth wheel if you had four wheel drive. That way, you would know that when the drive motors are going, but that wheel isn’t, you’re not only not moving, but you could put code in to make the robot react appropriately.
On the other side of the coin, the sensors have their own share of problems. If you space them too close together, the robot can get jumpy as it follows it’s path. And if another robot knocks you off the path, your robot could become completely useless for the first 15 seconds.
Ultimately, the choice is up to your team. It all depends on what you’re going to do in autonomous mode, and which method would have the least cons.
We’re using 4 shaft encoder “sensors” to sense the rotation of our motors before and after the transmission, as well as a sensor for direction. We’ll probably add some basic bump sensors into that list.
This is all for the 15 second autonomous mode, with the exception of 2 of the shaft encoders, which we need for our transmission to work properly.
All these sensors are going to be multiplexed into an external PIC or microcontroller that will feed the data on-demand to the Robot Controller. We’re using 2 PWM lines as an address bus from the RC to the external PIC.
It all depends on what you’re trying to do with the 15 seconds you’re given. We’re trying to do a lot, so as a result our program needs to “know” a lot about it’s surroundings and environment.
Just remember, robotics isn’t a horribly new field. There’s probably a sensor out there for what you’re trying to do, and there’s probably a way to interface it to the Robot Controller. It’s just a matter of if it’s worth the time.
Cheers,
Jeff McCune
*Originally posted by Jeff McCune *
**It all depends on what you’re trying to do with the 15 seconds you’re given. We’re trying to do a lot, so as a result our program needs to “know” a lot about it’s surroundings and environment.Just remember, robotics isn’t a horribly new field. There’s probably a sensor out there for what you’re trying to do, and there’s probably a way to interface it to the Robot Controller. It’s just a matter of if it’s worth the time.
Cheers,
Jeff McCune **
The other day, an advisor for our team pointed out to me that she noticed in the digikey catalog some proximity sensors. We thought about it and realized (if we were doing it) they would be much better for finding boxes than using the IR and hoping we found the little piece of reflective tape. To me, that would be a great example of finding a suitable sensor to do the job you need.
As Jeff McCune said, there’s probably a sensor out there. All you need to do is identify what you want done, then look for the equipment to get it done. If you can’t find equipment to do it, then try to refine it a bit so that it can be done.
Our team is trying to decide whether sensors are really necessary.
If we decided that all we wanted to do was bring the robot up the ramp in the 15 seconds, are sensors really necessary? Would it be possible/reliable to do it entirely with programming, eg. have a counter than increments to a certain number and use if statements? Since the curve is 4-ft radius/diameter (I forget which), it makes sense to make it constant rather than fool around with sensors.
If we do decide to use sensors, how do they actually work? What kind of input do they give? The optical sensor MSC will be shipping (correct me if I am wrong) later, what kind of input will it give, will it be a range from 0-255? Are the sensors plug n play like the touch sensors from the EDU-BOT?
One of the problems I have is that so much seems to follow the “black-box” mentality. I have no idea how any sensors work, just that they plug in and give some sort of value. If someone could provide some useful links to read up on, would be appreciated. (Links on basic/intermediate electronics would also be appreciated, the more specific to sensors and simpler the better).
907
Brian Lim
If you use the sensors in the kit you plug them into a digital input and it will return 1 if it sees reflective tape and 0 if it doesn’t. (At least, if electrical does a good job thats what should happen… of course, on my team electrical never does a good job… Guess who’s electrical? hehe… hi guys!
“Wow I hope that wasn’t important”
“I thought the wires were supposed to touch! Somehting about a ‘complete circuit’ or something…”
“That’s ok! I can fix it in the software!”
–Noah Said all this…
I’m good at programming, so I get to be electrical! whee!
*Originally posted by Brian_Lim *
If we decided that all we wanted to do was bring the robot up the ramp in the 15 seconds, are sensors really necessary? Would it be possible/reliable to do it entirely with programming, eg. have a counter than increments to a certain number and use if statements?
Well, as anyone who has been involved with FIRST Lego League probably knows, doing an autonomous program based purely on timing has issues. Specifically, motors run at different speeds depending on how well the battery is charged. Also if anything gets in your way and slows you down then your program can’t account for that. That doesn’t mean that this method won’t work. You should try it on your robot with a fully charged and a well depleted battery to verify that it will do what you expect in both situations.
The optical sensor MSC will be shipping (correct me if I am wrong) later, what kind of input will it give, will it be a range from 0-255?
The optical sensors in the kit are a digital device, so you just get a 1 or 0 depending on whether the sensor is seeing “light” or “dark”. The sensitivity of the sensor is adjustable with a little screw on the back.
could you be so kind as to post the asm code for the PICs that interface w/the encoders? im not very good with asm. I havn’t had the time to learn it.
*Originally posted by Rickertsen2 *
**could you be so kind as to post the asm code for the PICs that interface w/the encoders? im not very good with asm. I havn’t had the time to learn it. **
We have decided not to use a PIC because it would not be something that our highschool students could program or understand completely within the 6 weeks. Instead, we purchased a basic stamp 2p, which has software (polled) interrupts.
The encoder hardware consists of an IR break-beam sensor (digikey: OR518-ND) connected to a ripple-carry counter. The purpose of the counter is to offload the actual counting from the microcontroller because the microcontroller can only poll the pins and has the potential to miss counts. With the hardware counters, we can feed them a signal up to a few megahertz with no problems. So, the encoders on the wheel will be very precise, along the lines of 100 counts/revolution (before actually working the numbers). All while the basic stamp gets a nicely formed digital signal from the counters. Only one of the output lines from the counters will be hooked up to the microcontroller. Each consecutive output on the counter will toggle at half the speed of the last with twice the period, so we can choose which of those pins gives the processor enough time to count without compromising resolution.
So, the code we will be using will setup the polled interrupts on the counter input pins of the basic stamp. Then whenever a rising edge occurs, the stamp will run the interrupt page of code that polls the pins to see which encoder caused the interrupt, then add 1 to the corresponding variable location (in scratchpad ram).
good luck.
-Craig
I’m on a roll this morning. I can’t pass this one up. If you connect your BS2p to the RC’s programming port, you can send the data in via serial. Same with the PIC. I intend to use at least one, probably more, PIC chips on our robot. After all, a good copy of PicBasic and you might as well be using a Stamp 1 
Can’t hook up to the programming port. Sorry dude. Gotta figure out another way to do it.
(I’m 90% sure the rules prohibit this)
*Originally posted by Jeff McCune *
Can’t hook up to the programming port. Sorry dude. Gotta figure out another way to do it.
It was illegal…until last night. Team update 6 makes it legal to hook into the programming port (which can be used as a normal serial port). 
Fascinating. That opens to possibility for a lot of cool stuff then.
:mad: In the usual FIRST elegance, that rule change would have been useful to know 3 weeks ago… it would have saved much development time, as well as lots of money…
I love FIRST.
-Craig