I have a question regarding the wiring on non-VEX analog sensors to the Cortex.
I’m the programmer/ throw anything that isn’t metal/mechanical in nature to me on my VEX U team, and for our 2nd year we’ve decided to expand our use of sensors and to use different ones.
While wiring other sensors to the Cortex such as the NXTCam, I’ve used resources such as [this blog.
I know the NXTCam can be wired as a digital sensor, but for the gyro I’ve mentioned above, as an analog sensor the previously stated blog post wouldn’t work for it.
So how specifically would I be able to wire this sensor for use with the VEX Cortex?
I’m going to guess that the sensor is an I2C device, so the 4 wire Cortex cable should work for it. You will need the addresses to read/write. Check with the company, they should be able to tell you. Or rip apart the NXT library on the site to figure the codes out, it’s pretty clean C it should port to RobotC
Unfortunately ROBOTC on the cortex does not support any I2C sensors other than the IMEs, it does on NXT and that is what Xander’s library uses. The only way to access third party I2C sensors (unless ROBOTC V4.0 adds this functionality) would be using either the Purdue or my own alternative firmware, neither of which has been released yet.
Luckily when I asked about using 3rd Party sensors with Cortex, the RobotC team supplied me with the one they used for the NXTCam on the VEX Cortex. I will have to rework the driver for the AbsoluteIMU device to be compatible with the VEX Cortex.
I suppose my only thing now is to try to plug the IMU device into my analog port, mess around with the driver and see the values (if any) are returned.
I went back and had a look at the blog post you referenced, Xander was using two “normal” digital ports for the clock and data of the I2C interface and (presumably) bit banging the data from the sensor. This works but is extremely inefficient and the update rate may not be that high. You could use the same cable and technique for any NXT I2C based sensor as long as you knew the protocol being used.
Good point there, and I didn’t realize that. It may work similarly for the Gyro I’m using. Now is there anyway to make this more efficient or am I stuck with the limitations here?
I suppose another question I have is with the inefficiency of the current method of wiring, would using the CMUCam V4 and using one of the UART ports on the Cortex offer a more efficienct way rather than the NXTCam I’m currently using?
The question to ask is how often do you want new data. For image processing and detecting a “blob” in an image you may be ok with 10 or 15 times per second. A gyro, unless it has onboard processing for the integration, may need to be polled at 1KHz. The “bit bang” approach to communication, where the cpu has to handle the timing of every bit, ties up the cpu for the duration of the message (you also need to be aware of background interrupts that can screw things up) so if the update rate is fast there is no time to do anything else.
Using a UART for communication will probably be more efficient than bit bang I2C, however, most of the 3 axis gyro/accelerometer/compass devices I’ve seen are I2C. I have used this one which does have an asynchronous port but it is more expensive.
How much C and programming experience do you have? Even if I do not publicly release, I will provide the code developed in this thread for college teams and also help with drivers if needed.
Yes I have C programming experience. I suppose I’ll test the gyro and mess around with the driver. Maybe running it in the analog port will work. If not then the digital ports.
The best way to interface CMUCam (actually the only practical way) is using the serial (UART) port on the cortex. The arduino is not really needed at all, the CMUCam4 communicates using the same style TTL level serial pins as the cortex, if you use the arduino as an intermediate processor you would be reading information from the CMUcam only to then send it on to the cortex. If you interface it directly you would need to implement the CMUcam serial protocol, there is example code for other processors available and it would not be that hard to port over to ROBOTC (or EasyC I guess).
Not as such. Several client devices could listen to the same transmission from one host device, and there are standards like RS-485 where the transmit line of each device can be disabled, but in general the UART is used for point to point communications.