cmucam2 on MPLAB and VEX

Hello VEX fans,
Posted this on Chief Delphi and heard nada. I’d really like to get this cmucam working on VEX. The younger students in our program tend to think of VEX more as a toy. Its not, but we can use that natural curiosity to get them to learn the fundamentals of the robotics which makes them a lot smarter as the years go by. Any assistance you could provide would be greatly appreciated. We’re not particularly strong with camera tracking in general and I really hoped to spark some interest in our younger students this year so that we can get better at using this kind of sensor.

Regards,
KHall

During this build season I came across a cmucam2 revA which I believe to be from the 2007 season. Now that build season is over I thought it would be an interesting home project to see if we can get it working on a VEX controller so we can use it to teach the basics of cameras to our younger students.

That was about a week ago… I’ve collected a lot of information and software since then including several example programs for Brad Miller’s WPILIB and Kevin Watson’s cmucam code.

I know the camera works just fine since using the Java applet CMUcamGUI2_fe I can track colors reliably. Further I know that both Brad & Kevin’s code sucessfully initializes and starts the camera tracking (from LEDs and Brad’s easy to use SetCameraDebugMode(1) function).

But after that the results are completely consistant. The T-type packets appear to be sent but when you do printfs for the tracking variables you always get zeros.

Its interesting that with Kevin’s code (at startup) the first output is ‘no camera data’. It always happens once at startup, and from then on it just outputs 'Searching…". If you unplug the serial connection, Kevin’s code just streams ‘no camera data’. That makes me think that the camera is sending the data, but the VEX has something just a little different that causes the data to be ‘lost’. ( And I double checked my pointer logic many times. The variables are really empty. )

So after reading and trying everything that I can think of, and must admit I’m stumped. I’ve been using MPLAB and WPILIB for programming these VEX machines for quite a while now and it is, generally speaking, rock-solid.

So if you have any suggestions, or know something about the how the VEX CPU might be different, please pass it along. It would sure be nice to make use of this camera with the younger students – rather than just have this equipment and code sitting on a shelf collecting dust.

Thank-you,
KHall, Mentor
Team 2171
Crown Point RoboDogs

The Vex Controller has the same PIC Micro-Processor (e.g. 18F8520) as the 2004 & 2005 FRC Controller. The FRC Controller has more PWM Outputs, I/O than the Vex Controller, and adds Relay Outputs, but the MPLAB ‘C’ code is just about identical. So start with Kevin Watson’s CMUCAM2 code that will work on the 18F8520.

Sounds like you have done your Homework…

The CMUCAM2 has an on-board processor, and sends information like a GPS does. The CMUCAM2 needs an RS-232 to TTL converter board at the FRC Controller to establish communication. Both the RX ports on the Vex are also TTL, so you will need to start with the correct Voltage Levels, and proceed from there. Since the Vex Controller and the 2004-2005 FRC Controllers are both made by IFI, they are very similar…

The 2006-2008 FRC Controllers are basically identical to the 2004-2005 Controllers, but use the PIC 18F8722, which has 128K Words of Flash, verses the 32K Words of Flash on the PIC 18F8520.

I think that MARKO has asked the right question.

If you are connecting through the 9-pin connector on the camera you need to use a level shifter to convert the TTL level signals coming from the Vex serial port. For an FRC robot where the length of the cable run from the cpu to the camera could be 5 or more feet with lots of big “noisy” (electrical noise) motors all arround, this would be the preferred solution.

However, the TTL level signals are also available on the camera board. So, you could cable from the TTL pins on the vex processor to the TTL pins on the camera without needing to use a converter.

Thanks for the feedback.

I never did get the WPILIB to read the camera’s data. It does still send commands and the debug mode still works.

So what I ended up doing is just reading the data directly from the second serial port. That works just fine, but it does take some effort to parse the data. As long as I was doing a deep dive into the CMUcam, I decided to do a couple other things too.

The FRC code sets the camera to continuously send Tpackets. Since I had to sort through all that, it just made it a lot easier to put the camera into polling mode. The command is “PM 1”. After that it only sends a single Tpacket every time you give it the “TC” command. Much easier to deal with.

The other thing I did was to use the OM command. This allows you to set a bitwise mask on the data being sent. The default Tpacket returns 8 data points. Using the command “OM 195”, it only sends the first two and the last two data points (b 1100 0011 = d 195). That means I only have to parse the data points I want. That is: meanX meanY regionSize and Confidence.

Once that was all done, testing proved that you really need to keep a running average of your numbers or the reactions are just too sudden and jerky.

One final set of tests to measure and compensate for the expected differences in motors and we have a squarebot that will follow a specific color.

Thanks,

KHall

easyC Pro supports this out of the box, you just have to configure the camera colors settings and you will have what you need.

Fun with the cmucam and VEX

Squarebot:
Photo and code.

Tracker:
Photo and code.

Code in MPLB with WPILib.

Never could get the WPILib code to read the camera output. Finally just set the camera to send ASCII data and parced it.

Enjoy!
KHall


cmucam_squarebot10C.zip (1.53 KB)

cmucam_VEX_tracker.zip (1.97 KB)