Wiring of non-VEX analog sensors to Cortex


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.

One sensor in particular we’ve looked at is a combined Gyro, Accelerometer, and Compass. Namely this one: http://www.mindsensors.com/index.php?module=pagemaster&PAGE_user_op=view_page&PAGE_id=158

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?

Thank you in advance!](“http://botbench.com/blog/2011/03/20/vex-cortex-i2c-nxt-cable-howto/”)

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.


I should add that the NXT one that you linked was probably a packaged version of something like this, they all use the same ICs more or less.


This also uses I2C and is 5V compatible.

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.

I’m back with another question actually.

So I’ve changed my plans and decided to purchase an arduino, and focus on my vision processing right now. I have a CMUCam4 that is an arduino shield.

My plan behind this is to use the arduino to handle my vision processing, and then transmit the relevant data over to the Cortex.

My questions are:

Would I need to connect the CMUCam + Arduino via UART to the UART port, or could I use a 3 wire PWM and treat the Arduino as a digital sensor?

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).

I have posted some serial example code here.

I will also be posting a much more complex serial communications example that implements a different protocol over the weekend.

I guess it’s time to buy myself a new toy and see (or should I say “let it see”) what it can do.

Ok, that makes a lot of my plans easier. Thanks.

Does daisy-chaining work in the same way for the UART ports as it does for the I2C sensors?

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.