I am able to get 2 sonar sensors working, but for some odd reason vex doesnt allow sonars to be hooked up to anything but interrupts 1 and 2. Why is this? I need one to be allowed in interrupt 3…see attachment.
Sorry for the Delay… You did not specify that you were using RobotC.
Even RobotC 1.97b seems limited to Interrupts #1 and #2. I suspect that this is a “Hold Over” from the NXT version of RobotC.
I would post at the RobotC IFI PRogramming, Help Forum, and see if they can help you out…
EasyC and MPLAB (MCC18) support at least 4 Interrupts and I believe all 6 can be enabled with a little additional programming.
In the past, using software that is probably older than what you are using right now, and trying to use three ultrasonic transceivers; I had to turn each transceiver on and then back off in order to get all three to work. I was using EasyC.
Each time I wanted to use one I would turn it on, use it, then turn it off (I forget the command names, but if you are using EasyC you will know what I mean).
You might need to do something similar to get your system to work.
Blake
Yes I know of this technique for easy C. However in robot C (for whatever retarded reason) the program will not read sonar input from any interrupt save for int 1 and int 2. I cannot see the reasoning behind this.
You might want to post your concerns in the RobotC support forum: https://vexforum.com/forumdisplay.php?f=286
Good luck.
You don’t need interrupts to use an ultrasonic sensor! For example I was able to successfully follow this tutorial and hook up a vex ultrasonic sensor to an arduino. Now all it has to do is toggle a pin high to send a “ping”, then start a really fast timer (microseconds) and then wait for the receiver pin to toggle high. The time between the sending and receiving of the ping is sent through this formula which converts the time into a distance by using the speed of sound. No interrupts were used only digital I/O pins, if you google arduino interrupts there would be something like attachinterrupt(); in the code so again this used NO INTERRUPTS!
To inches
microseconds / 74 / 2;
To centimeters
microseconds / 29 / 2;
http://arduino.cc/en/Tutorial/Ping?from=Tutorial.UltrasoundSensor
HOW THE SENSOR WORKS!!
To better understand what I am trying to say you have to know how the sensor works. The vex sensor has two cables one for input and another for output. First the input cable signal pin is switched high for a few milliseconds which causes the sensor to output a “ping”. The sensor then waits to “hear” the ping, when it finally hears the ping it toggles the signal pin on the output cable high. By timing the delay between sending and receiving the ping (in microseconds) you can then find the distance by passing it through a formula which uses the speed of sound to get the distance.
Now in the tutorial above the writer had a 1 cable interface which is basically the same thing as the vex except for the fact that the input and output pin are on the same wire. So you would toggle the pin high to start the ping then change that pin to a digital input instead of an output and wait for the pulse (while timing the delay). (I really don’t know why vex didn’t do this wouldn’t it be some much easier to have 1 cable instead of 2?)
The pulseIn part of the arduino code is a function that waits for a pin to toggle and while doing this records the amount of time in microseconds then when the pin finally toggles high it reports the time. There is also a timeout feature so that if no pulse/toggle happens within a certain time say 50ms if will abort.
So a subroutine could be written in robotC or mplab that does the exact same thing when called it starts a timer and waits for a pin to toggle high, when it does toggle high it will return the duration, and if it takes to long the subroutine will abort/timeout.
It might be a little more complicated to do this method but you won’t be limited to interrupts only as any digital I/O pin can perform these simple tasks input and output!
I hope this helps!
While were on the subject, what does an interrupt do that an I/O pin can’t? What is the difference between the two?
An interrupt can cause the processor to stop what it is doing and immediately jump to a subroutine (an interrupt handler). This means that you can be sure that a very small time has passed between the triggering event and the handler running (microseconds).
The alternative with an I/O pin is to “poll”, or check its state periodically. If you poll a thousand times a second, then the triggering event could be ignored for up to a millisecond (the time between polls).
Human-time-scale operations like checking for button presses are very slow, and you can usually get by with polled operation. For anything that requires very precise timing (like sonar echo timing) you really want an interrupt.
Even better, you would want to use something called “input capture” where a timer on the microprocessor directly times the event of interest. The software just checks to see if the timer has fired, and if so, it reads the result and resets the sonar for another ping.
Cheers,
- Dean
Thanks Quazar! I was always thinking that something like interrupts would be necessary, but I didn’t know what they were called.