If you’re using my 2008 code and are in need of a new solution for IR remote control, I’ve created add on code that will do all the waveform processing on your robot controller. The only external component needed is a $2 Vishay IR sensor, which can be purchased at many distributors like Digikey, Newark, etc. As always, please post here if you find a bug in the code or documentation, or just find a fun use for the code outside of the 2008 game. Here’s the link: http://kevin.org/frc/ifi_ir_sensor.zip.
This is an example of what Kevin’s IR code can do. This code was originally written for Kevin’s 2008 IFI alternative code. With a little reading and understanding of how it was written, I have munched it into my Vex code. If I can munch this into Vex code, you can easily munch it into the default IFI code. As you can see from the picture I am using a Sony DVD controller. If you look closely at the laptop screen, you can see that the address and command number are those for the number four key when using the Sony SIRC protocol.
The process of munching this code into Vex took me approximately one half hour. Therefore I’m assuming that the process of munching this code into the IFI default code would take approximately the same time. If you attempt to put this code into cabins 2008 code, it should only take you about 10 minutes. Please look at the picture below for a visual representation of how the code works. As you can see, it is a complete replacement for the IR board, and thus, is way more stable. Basically this becomes a single component replacement for the entire IR board. The component is a simple Vishay IR receiver, similar to those in the 2004 kit of parts.
Ok thank you for putting this out there.
Now a quick yet important question, I see that in your documentation you are refering to teleop.c and other files that are in the new code for the 3.0 compiler. I know where those locations translate to, but do you know or anyone know if this works with the code for the 2.4 compiler?
I believe I can answer this. The Vex uses the 2.4 compiler and MPLAB version 7.4, exactly the same as the code versions in the kit of parts.
To get this to work properly, you will also need to integrate Kevin’s “encoder” code from his website. This will allow the IR sensor to be sampled properly. If you are already using encoders on your robot you may have done this.
The next thing you’ll have to do is to slightly modify Kevin’s instructions as to how to integrate the IR code. When his instructions tell you to modify the line in encoder.c where it calls the IR’s interrupt channel ISR, you will have to do this in user_routines_fast.c. You will also have to comment out the call to “#include ifi_frc.c” and add in the “#include ifi.aliases.h” and “#include ifi_default.h”.
I’m certain I have forgotten one or two minor points, but I think the most essential parts have been covered.
Kevin if you have any additional comments, please add them.
I can not post my code because it tightly integrates Kevin’s ADC, ENCODER, GYRO and IR functions. I do not have permission to repost Kevin’s work. If I strip out Kevin’s files, the code would not make any sense. If Kevin releases me to post it, I will get it up as quickly as possible.
As for the elimination of jamming, no. Some form of shielding may help. The best thing you can do to prevent that is to work with your Alliance partners to come up with a strategy that will prevent it.
Yes, I realize it may seem strange to give away software, but ask people to not make it available publicly on the 'net. My reasoning is that I want one public source of my code so that I don’t end up burning up a lot of time helping teams fix bugs intoduced by third parties. It would also weaken my copyright if I allowed others to publicly post my code elsewhere. With that said, I have no problems with people occasionally e-mailing code to one another as long as it’s done for educational purposes.
Apparently I cannot access kevin.org as it is a “personal” site.
Can anyone tell me what this code is doing in terms of processor tax (interrupts, timers, heavy code)? It seems like something that I would like to integrate to take out the IR middle man, but we are already pushing the RC pretty far. (I chose readability and re-usability over a clean stack… oh well)
The tax is pretty light. The ISR uses a timer to calculate the pulse width then uses a simple algorithm to build the 12-bit command word. Send me an e-mail and I’ll reply with the code.
Jesus,
If I understand your question, then yes, you can use Kevin’s IR code without using Kevin’s new C18 3.0 compatible IFI replacement code.
I was able to implement Kevin’s IR code on my Vex robot which uses the same MPLAB 7.4 and C18 2.4 that came with the KOP this year.
If you would like, send me an IM with your e-mail address and I can send you a zip copy of my Vex code so you can see how I was able to do this. It will require that you use another piece of code from Kevin, namely, his Encoder code. It is also available on his web site.
correct me if I am wrong, but isnt that IR receiver the same kind that is locating in any computer mouse?
I know that if you are using a mouse with a ball in it, when the ball turns and moves it spins a shaft. On the end of the shaft there is a disk with usually 36 slits so that an IR beam can be picked up by an IR receiver to determine the movement of the mouse.
I have a rough understanding…
yea
Honestly Neel, I haven’t looked closely enough at the inside of a mouse to answer that question. I think your concept is correct. As for the details, I can not say.
(This would be true for a “ball” mouse, not an “optical” mouse.)
There are different versions of the Vishay sensors in Identical packages.
The TSOP48xx family is one that works as documented with Gnd on Pin 2.
However, the TSOP322 family, which is arguably better because of its 2.7 - 5.5V power supply range, has ground on pin 3 and power on pin two. This is
reversed from TSPO48xx family.
IF YOU USE A TSOP322XX FAMILY SENSOR AND FOLLOW KEVIN’S DIAGRAM
YOU WILL INSTANTLY FRY THE SENSOR.
Good practice is to always make sure you have a datasheet for the actual
device you are using and double check the connections.
Short answer is yes. The output is a transistor with a 30K pullup. It should
remain well within spec with 3 additional identical devices plus the current
sourced from the Robot Controller. So you should be able to have a total
of 4 sensors on one input. (You could probably have several more but then
you will be outside the 250mV max output low voltage specification.
Beware, however, that you be subject to interference from any sensor
which may prevent your desired signal from getting through. An interfering
signal on the same carrier frequency being received from any of the sensors
will interface will all sensors.
A more robust approach would be to use separate interrupts for multiple sensors
f you have the available interrupts (from 3 to 6). This way, an interfering signal being received from one sensor will not mess up the signal
being received at the other sensor. You will need to modify the code to
share a timer.
IIRC a mouse uses a fairly simple interrupter. The Vishay IR receiver modules have a more complex integrated receiver that handles pulse bursts of a specified frequency and use AGC, a bandpass filer, and a demodulator to produce a very stable output pulse train. Interference is not an issue inside a (mechanical) mouse. It’s a big issue for remote controls.
