How to use FTC hi-tech motor controllor on FRC

Technical Programming
1

Hi-tech motor controllor is use i2c port to connect with NXT robot brain, but there are a i2c port on FRC contro system. How to set it up?

2

The new RoboRio for FIRST (the new control system) will have an I2C port.

3

The sidecar has a i2c port.

http://robotics.francisparker.org/javadoc/edu/wpi/first/wpilibj/I2C.html

4

!st have to check if the FTC controller is 3.3 or 5 volt. May need a level shift. Then find the command structure. I have seen a document on it before . Don’t remember where. The controller is probably maxed out at 10 amps.

5

Start with the HiTechnic FIRST Motor Controller Specification Rev1.3 May 30, 2008.

FTC 4251 - Cougar Robotics has a copy posted on their home page.
http://www.cougarrobot.com/

6

FRC motors are constrained to be controlled by a specific port. I am too lazy to look at the 2015 rules, but I don’t think the I2C port is on that list.

7

You could probably make it work for experimentation or maintaining a demo robot, but you couldn’t compete with it. Never been legal.

8

5V I2C but also works at 3.3V although check the master end too just in case it’s not 5V tolerant.
Current output is limited by thermal constraints and connectors/PCB traces. Yes you can suck out 10A but not all day long!

9

I’m also trying to connect the FTC HiTechnic motor controller to a cRIO/digital sidecar. Our intention is to use it purely as a programming training platform. I’m planning on implementing a standard motor controller wrapper class that mimics a Jaguar CAN controller. (the HiTechnic controller supports PID, encoders, etc)

I’ve been able to connect and control it using an arduino (just so I could verify it was possible).

When I use java on the cRio, it fails. Here are some traces of the i2c bus from the arduino and the crio (the request is to read the vendor name from the controller):

Arduino -

cRIO -

For some reason the crio sends the device address (0x02) and then a NAK with none of the rest of the data (i.e. Register # 0x08)

Here is the cRIO code that I used to generate the capture:


        I2C i2c = m_module.getI2C( 0x02 );     
        
        while (true)
        {
            byte] deviceData = new byte[4];

            i2c.read( 0x08, 4, deviceData);

            System.out.print( (char)deviceData[0] );
        
            try
            {
            Thread.sleep( 250 );
            }
            catch( InterruptedException e )
            {}
        }

Thanks for any insights you can provide

David Blain
Rosie Robotics #839

10

Best guess is your I2C clock is too fast and perhaps other timing issues. At a guess I’d say the I2C implementation on the HiTechnic controllers may well be software based and perhaps less able to handle higher clock frequencies or shorter setup times.

In the Arduino trace you can see the SDA change state right around the time SCL goes low. cRIO has SCL low before SDA changes state and then SCL high pretty soon afterwards. Granted it should be clocked on SCL going high so shouldn’t make any difference but worth pointing out.

The NAK is because the I2C slave didn’t respond. Arduino gets an ACK, cRIO gets a NAK (i.e. slave didn’t hear you).

If the cRIO has some way to change I2C clock to 9600 which the NXT uses then perhaps it might work better however the asymetric clock and slightly delayed SDA setup might be fatal to HiTechnic controllers.

11

The captures show that both clocks are between ~21khz & ~32khz, so I don’t think that’s the issue (I should of included more timing information in screen prints).

I decided to hook both up to the controller at the same time (expected collisions). What I found was that the arduino worked as expected, but the crio also produced additional data (although not 100% correct).

What I found was that although the DSC says it’s a LEGO compatible port, it doesn’t provide the 5v 10k pull-up on the analog port (white wire) that the NXT brick does.

The HiTechnic controller uses the voltage to determine what I2C address it will listen on (not sure of the details, but it allows the controllers to be daisy changed without address jumpers). Since the DSC left it floating, the controller didn’t assign itself the 0x02 address that I was expecting.

All is not solved yet… When I added the pull-up and removed the arduino, I now see the expected NUMBER of requests, but no matter what registers I request data from, it always returns 0x03.

I’m going to double check the electrical characteristics of DSC LEGO port and see what else might be different.

Although I was hoping for a plug and play solution, I can live with having to make a custom cable to account for electrical differences.

Now to just get rid of those 3’s!!! :slight_smile:

12

It looks like the cRIO/fpga is not keeping the SCL line low long enough during reads and the slave isn’t stretching the clock.

The clock problem is fairly clear to see if you look at the capture in the prior post.

Anyone know if the specs/API to the FPGA is available or the VHDL (or other source) for it?

I’d like to fix the library if possible before I move on to a hardware solution.

13

Make sure you are enabling “Compatibility Mode” on the cRIO’s I2C API. This enables clock stretching. Also, note that the addresses that the cRIO I2C API takes is an 8-bit address, not a 7-bit address. That means if you use address “3” on your arduio, you will need to use address “6” on the cRIO.