Will the CMUcam2 work on the EDU-RC controller?
If so, is it the same code?
and Do I use the TTL port (I just want to make sure its the same and I don’t burn anything out) on the EDU controller?
Will the CMUcam2 work on the EDU-RC controller?
If so, is it the same code?
and Do I use the TTL port (I just want to make sure its the same and I don’t burn anything out) on the EDU controller?
yes, yes, and (checks own edu controller) yes.
as kevin said, the cam code was designed witht the edu controller in mind.
I haven’t seen our EDU controller in a while, does the TTL port have 3 pins or 4 pins? I wanna say 3 and if so do we need all 4? I assume not since only 3 go to the camera, but the TTL adapter still has four pins, so which 3 do we have to align?
This should answer your question. The picture is take from page 11 of the 2005 RC reference guide (http://robotics.dyndns.org/DATASHEETS/2005_RC_GUIDE.pdf), and the EDU diagram is taken from page 11 of the 2004 EDU reference guide (http://robotics.dyndns.org/DATASHEETS/2004_EDU_GUIDE.pdf).
Obviously, the +5V pin on the full-size RC is not needed.
Thanks.
You’ll need to hack a cable and pull 5V from one of the PWM or digital input pin sets to power the TTL converter.
Or just use the programming port.
-Kevin
We had to make some minor changes to the default ‘bells and whistles’ code to make it work with the EDU-RC controller, but it seems to work. If you want a copy of this let me know, and I can supply them. Another one of our programming team made the mods, or I’d post exactly what we had to change in this thread.
One issue I didn’t see in this forum involves using the Labview application with the CMUCam2. Bear with me while I describe the problem before replying, because in general it DOES work.
After a few (more than 2, less than 10) frame grabs, the application shows the progress bar going from 0 to 100%, pausing momentarily at 100%, not displaying the frame that was grabbed in the window, then after some amount of time (more than 30 seconds, less than 5 minutes) it re-tries getting the image and the progress bar goes from 0 to 100% as before. Once the application is in this state, the only solution is to close LabView, open the project and run it again. This typically fixes it, and we can grab a few more frames before it crops up again. As one could guess, this makes camera calibration/focusing a very trying task.
Relevant information:
EduRC from 2005
Freshly charged backup battery providing prime power for EduRC and cam
Laptop with REAL serial port (none of that USB nonsense)
Original CMUCam2 code (not the EduRC version, we started this before seeing it was available) with minor mods to build cleanly for EduRC2005 instead of FRC2006.
At this point, we only need to do some minor tweaking of camera values to consider it fully ‘calibrated’ so it’s quickly becoming a moot point, but I’m hoping this info might help to make the Labview app more stable. It’s certainly a grand improvement over the original Java version from last year.
Cheers,
-Eric
We had to make some minor changes to the default ‘bells and whistles’ code to make it work with the EDU-RC controller, but it seems to work. If you want a copy of this let me know, and I can supply them. Another one of our programming team made the mods, or I’d post exactly what we had to change in this thread.
It would be great if you can post it!
And thank you everyone for the quick response!
Probably the best bet is for you to PM me your email address, I can just zip the whole directory vs. trying to DIFF the original & our code.
The programmer who made the actual changes isn’t at our meeting tonight, so the soonest I could get you a reply would be late tonight/early tomorrow morning.
It’s also possible the code changes we made have contributed to our Labview woes so caveat emptor…
Eric,
There was a bug in the first version of the application that would cause this problem. There have been several updates since then… it was fixed in the first update. You can find the updates here.
Also remember that you can’t have more than one device plugged into the CMUcam at a time (Laptop or RC).
If you continue to have problems, please post in the LabVIEW forum and I’ll continue to help you there.
Good luck!
-Joe
I am a newbie :ahh: . What do you mean by “hack a cable” and how would this cable look/work? do you need to “hack a cable” for the edu bot and the frc bot? or just one. do you use a pwm cable to go from ttl to ttl port? I could not find anywhere what cables you use where? When do you use the ttl chip that came with it? Is that only for testing? One person said “obviously you don’t need the +5v” and the other said to “hack a cable” so I am very confused. I have been tring to get the camera to work for a few days. The only led that comes on is green, and I think it is the power one. I have gotten the camera to center itself, that’s it. grrr, I feel like everyone has figured this out but me. :ahh:
I know this might be a lot to ask but could someone make a quick schematic on paint of all the conections you need to get the camera to work? I have not found any good solid and simple info or diagrams in any documentation, so I think that would be REALLY HELPFUL to alot of people!
I know that is alot of questions so thanks for all your help in advance!
I should probably create a new thread for this but I know people don’t like that.
-David Mazza
-Team 564
-564.first@gmail.com
Just verifying something, are you trying to run the camera on the full-size RC (the one used in competition this year) or on the EDU controller from 2004?
This thread is for “hacking” the CMUCam to run on the EDU controller.
Both! The EDU to test, and FRC to use. I would like to know how to hook it up to the EDU. I am mainly wondering how the TTL thing gets setup. After I know how to run it on the edu I will go from there, but some of my questions pertain to the FRC as well. The schematic I want would be of the FRC. You might be right, I think I will be better off posting that in a new thread. Moderators: please don’t kill me for posting kind-of the same thing in two threads.
The DB9 port? And do we then need to change the serial port used in the code?
Jon Mittelman
This is from my personal experience with the code and camera on the mini-RC. There are other (and probably better) ways to do this, but I know it works. The code worked perfectly out of the box once I got the camera set up. The TTL convert has four inputs, but the mini-RC only has three pins on the TTL port. The fourth pin, which is missing, is for +5V to power the TTL converter board. I had to cut one end off of a PWM cable, solder a header pin to the red wire, and plug that into the open slot on the TTL board. Cut about 1" off of the black and white wires to give yourself some room to work. You could also use a piece of resister lead for the pin if you don’t have any header pins. Heat shrink the solder joint so that no exposed metal pokes out when you plug it into the TTL converter board.
Connect a PWM cable from the TTL port on the mini-RC to the inputs on the TTL converter board so that the black lead matches B on the board.
Connect your hacked cable with the power pin to a PWM output or digital/analog input. The red pin will pull +5V from the port.
Connect the pin on the red cable to TTL converter board. It will be the open slot opposite the one marked B.
Connect a PWM cable from the TTL converter to the camera’s RS232 input.
Thanks! That’s exactly what I needed to know. Now I can pass that on to my electronics guy!
Can’t you just get rid of the converter chip altogether when using the edu-rc and just run a pwm cable from the ttl on the camera board to the ttl on the edu-rc since it has the 3 pin ttl on it and the camera board has 3 as well?
I’m not sure, but I think I read somewhere that this limits the data transfer rate to 9600 baud. I have no idea why, though…
Just to be clear, there are three serial ports on the CMUCam2 that can be used.
You cannot hook the CMUCam2 3-pin RS232 port directly to the RC TTL port without the TTL-Converter chip so don’t try it. The TTL Converter changes the signals from RS232 to TTL.
The TTL port on the CMUCam2 has 4-pins and two of the pins are in a different order than the RC expects. If you hook them up without making a special cable you can destroy something and they won’t be able to talk anyway.
In general, the TTL port will be more susceptible to noise than either of the two RS232 ports as the cable to reach the RC gets longer.