USB Joystick adapter is here!

[Mike Copioli]

Originally Posted by Greg Marra

Actually, thanks to a standard (USB human interface device class) most any controlling device should work with the USB Chicklet. The only problem would be how the chicklet chooses to map all of the possible channels in an HID device to it's limited number of channels, but the standard does exist. "Proprietary drivers" are often required for unusual functions that require an extension of the standard, and those 'extras' wouldn't work with the chicklet.

You are correct. The Chicklet will support ANY HID device. The only limitation is what we (CTRE) introduce. You are also correct in your statement about mapping the inputs. However we have solved this issue by implementing functionality that allows the USER to select the configuration of the game pad and x-box controller. The logitech game pad, for example. The user will be able to select from one of two modes.

Mode 1: 4 digital buttons selectable by the user and 4 analog axis(x,y & x,y)

Mode 2: 12 digital channels and 2 analog axis (y,y)

Also, any device that is not yet supported can be added.

[yongkimleng]

Originally Posted by Mike Copioli

You are correct. The Chicklet will support ANY HID device. The only limitation is what we (CTRE) introduce. You are also correct in your statement about mapping the inputs. However we have solved this issue by implementing functionality that allows the USER to select the configuration of the game pad and x-box controller. The logitech game pad, for example. The user will be able to select from one of two modes.

Mode 1: 4 digital buttons selectable by the user and 4 analog axis(x,y & x,y)

Mode 2: 12 digital channels and 2 analog axis (y,y)

Also, any device that is not yet supported can be added.

wow.. correct me if im wrong, you're the designer for all the products on the website?

[Mike Copioli]

Originally Posted by yongkimleng

wow.. correct me if im wrong, you're the designer for all the products on the website?

No. All of our products our designed by Omar and myself.

[yongkimleng]

Originally Posted by Mike Copioli

No. All of our products our designed by Omar and myself.

i see.. very impressed by the two products there

[Joe Johnson]

Originally Posted by mehul

well dont kow if we can use this..." usb to a 15 pin device" found it in ebay and came up with this eventhough its sold in uk im sure we can get it here in the US

http://cgi.ebay.com/USB-to-15-Pin-Joystick-Gameport-Converter-Adaptor-Cable_W0QQitemZ300023178789QQihZ020QQcategoryZ7494 3QQcmdZViewItem

they show the specs in the bottom and im sure u guys can figure out how to impiment it to use in the first controller. It also doesnt require any programing so it should work fine and no external power source.

Note* sorry for the bad grammer and as u see i was an animator and have no idea what to do with this electronic stuff

I think this is the compliment of what we want. If I understand this correctly this device allows folks to provide a 15 Pin gameport to a PC by plugging it into a USB port on their PC.

We want/need something that allows a USB gamepad to be plugged into a 15Pin gamepad port.

Joe J.

[Joe Johnson]

Originally Posted by Mike Copioli

You are correct. The Chicklet will support ANY HID device. The only limitation is what we (CTRE) introduce. You are also correct in your statement about mapping the inputs. However we have solved this issue by implementing functionality that allows the USER to select the configuration of the game pad and x-box controller. The logitech game pad, for example. The user will be able to select from one of two modes.

Mode 1: 4 digital buttons selectable by the user and 4 analog axis(x,y & x,y)

Mode 2: 12 digital channels and 2 analog axis (y,y)

Also, any device that is not yet supported can be added.

Very cool... ...very clever too.

My memory is a bit rusty, but I think that each joystick port on the OI only has 4 switches and 2 analog channels. How do you get 4 analog channels (in mode 1) or 12 digital channels (in mode 2) plumbed to the OI? You must have an adaptor/harness???

Joe J.

[yongkimleng]

Originally Posted by Joe Johnson

Very cool... ...very clever too.

My memory is a bit rusty, but I think that each joystick port on the OI only has 4 switches and 2 analog channels. How do you get 4 analog channels (in mode 1) or 12 digital channels (in mode 2) plumbed to the OI? You must have an adaptor/harness???

Joe J.

I'm not sure about the OI (never used full size RC before, only miniRC), but the joystick port supports a max of 4 analogs and 4 digitals, mode 1 should be possible.
Maybe mode 2 turns the 4 analogs into 8 digital inputs via multiplexing each digital input into 4 respective analog levels?

[Mike Copioli]

Originally Posted by Joe Johnson

My memory is a bit rusty, but I think that each joystick port on the OI only has 4 switches and 2 analog channels. How do you get 4 analog channels (in mode 1) or 12 digital channels (in mode 2) plumbed to the OI? You must have an adaptor/harness???

Joe J.

The O/I has 4 analog channels/port. We use the extra two analog channels as digital when they are not used for analog.

BTW

Congrats on your recent TV appearance.

[yongkimleng]

Originally Posted by Mike Copioli

The O/I has 4 analog channels/port. We use the extra two analog channels as digital when they are not used for analog.

BTW

Congrats on your recent TV appearance.

How about mode 2?

[Joe Johnson]

Originally Posted by Mike Copioli

The O/I has 4 analog channels/port. We use the extra two analog channels as digital when they are not used for analog.

BTW

Congrats on your recent TV appearance.

Yes, you are correct. I have really been out of things too long.

As to Mode2, where you send the 12 buttons. Do you send them via the analog channels, where different ranges imply different button combinations for example
0-15: 0000 0000 0000
16-31: 0000 0000 0001
32-47: 0000 0000 0010
48-63: 0000 0000 0011
etc.

If this is true then you don't use the switch inputs or the LED outputs.

If this is correct, can I propose 2 more modes?

mode 3:
LED outputs used by the RC to multiplex between mode1 and mode2

mode 4:
every other data packet switch between mode1 data & mode2 data with the switch inputs used to tell the RC which type of data to expect*

Finally, you don't discuss the POV data. The POV button is a very nice way to drive robots in many cases. From a Windows application, the data is returned as 0, 45, 90, 135, 180, 225, 270, 315 but as a practical matter, the POV data is really just 4 more switch inputs that are mapped to these 8 pionts of the compass. Any chance you can map these 4 switches to give access to that data too**?

Think about it.

Joe J.

*This may run into problems with aliasing since you can't sync with the IO packet sending. perhaps it would be better to send 2 packets in mode1 and 2 in mode2 or maybe even randomly switching, within limits. Also, there is another possible problem with this if the OI does not synchronize the reading of the OI switches with the reading of the analog ports, but the ability to have all the switches and both X-Y data on the thumb would be great.

**note that if you can use 16 bits per range on the analog inputs, then you have room for 16 swithches with a 255 bit resolution on the ADC on the OI -- I am not sure but I think that the ADC on the OI is still just 8 bits. It seems feasible.

[Alan Anderson]

Originally Posted by Joe Johnson

Finally, you don't discuss the POV data...

The POV "hat" switch on the white A/B joysticks is connected to the "wheel" input. It's just a few resistors wired to the switches to give testable values on the analog input.

It sounds to me like the Chicklet's Mode 2 turns four digital inputs into an analog value on the "wheel" input -- perfect for a POV switch -- and another four digital inputs into an analog value on the "aux" input.

[ozrien]

Dr. Joe,

The joystick interface does consist of 4 analog and 4 digital channels. We had intended to have 4 possible modes for gamepads with two analog sticks,

mode 0 - axis 1 XY, axis 2 XY - 4 channels used
mode 1 - axis 1 XY only - 2 channels used
mode 2 - axis 2 XY only - 2 channels used
mode 3 - axis 1 Y, axis 2 Y - 2 channels used

And you are correct in saying we can use the unused channels for digital values! In fact we intended to use the upper nibble of unused analog channels precisly to send digital button info. We're only using the upper nibble (MSb 4 bits) due to possible jitter in the analog transmission, 4 bits is overkill we know and we may change that to support more digital support.

So lets say a,b,x,y (XBOX controller) are decoded in one of the analog channels. And lets say a and x are pressed and b and y are not.
The data transmitted would be binary : 1010 1000 or 168(decimal).
the 1010 would be a-press,b-not,x-press,y-not.
the lower 1000 is ignored by the application. Since we can't ensure that a value of n won't be read as n-1 or n+1 on the OI side the lower nibble is set to the middle of the value range. This uncertainty is do to the jitter in the OI side.

The POV will be decoded as 4 buttons. I grew up on SEGA, there's no way we're not supporting this. The only trick would to implement application code to recognize up and left pressed together as up/left, which shouldn't be hard for most teams.

So the intended use we designed for was so that through a simple calibration mode you can set the number of analog channels and which axises to use (mode 0-3). This selection would determine the number of digital slots available, in which case the next step of calibration would be to pick which buttons you want to be included in the digital transmission, we were thinking of having an led blink the number of digital slots available(4 or 12). And to select a POV button you can simply press one of the POV buttons.

So somehow the user would enable calibration mode, i.e. jumper and power recycle perhaps

1) Choose which axis profile, either using lcd outputs from controller (which is a FANTASTIC idea) or maybe number of button presses.

2) Observe led blinks to see how many digital buttons you can have.

3) press the buttons you want decoded (max 4 or 12 depending on axis selection).

4) leave calibration mode and PLAY.

Settings are saved in EEPROM so you never have to do this again.

Now this IS NOT SET IN STONE. We could use the lcd outputs to select axis mode during runtime or better yet allow us to transmit 4 times the data through indexing. My only concern is that we don't make this so complicated that only veteran teams use this.

Omar Zrien
Cross The Road Electronics

Originally Posted by Joe Johnson

Yes, you are correct. I have really been out of things too long.

As to Mode2, where you send the 12 buttons. Do you send them via the analog channels, where different ranges imply different button combinations for example
0-15: 0000 0000 0000
16-31: 0000 0000 0001
32-47: 0000 0000 0010
48-63: 0000 0000 0011
etc.

If this is true then you don't use the switch inputs or the LED outputs.

If this is correct, can I propose 2 more modes?

mode 3:
LED outputs used by the RC to multiplex between mode1 and mode2

mode 4:
every other data packet switch between mode1 data & mode2 data with the switch inputs used to tell the RC which type of data to expect*

Finally, you don't discuss the POV data. The POV button is a very nice way to drive robots in many cases. From a Windows application, the data is returned as 0, 45, 90, 135, 180, 225, 270, 315 but as a practical matter, the POV data is really just 4 more switch inputs that are mapped to these 8 pionts of the compass. Any chance you can map these 4 switches to give access to that data too**?

Think about it.

Joe J.

*This may run into problems with aliasing since you can't sync with the IO packet sending. perhaps it would be better to send 2 packets in mode1 and 2 in mode2 or maybe even randomly switching, within limits. Also, there is another possible problem with this if the OI does not synchronize the reading of the OI switches with the reading of the analog ports, but the ability to have all the switches and both X-Y data on the thumb would be great.

**note that if you can use 16 bits per range on the analog inputs, then you have room for 16 swithches with a 255 bit resolution on the ADC on the OI -- I am not sure but I think that the ADC on the OI is still just 8 bits. It seems feasible.

[Joe Johnson]

Originally Posted by ozrien

Dr. Joe,

The joystick interface does consist of 4 analog and 4 digital channels. We had intended to have 4 possible modes for gamepads with two analog sticks,

mode 0 - axis 1 XY, axis 2 XY - 4 channels used
mode 1 - axis 1 XY only - 2 channels used
mode 2 - axis 2 XY only - 2 channels used
mode 3 - axis 1 Y, axis 2 Y - 2 channels used

And you are correct in saying we can use the unused channels for digital values! In fact we intended to use the upper nibble of unused analog channels precisly to send digital button info. We're only using the upper nibble (MSb 4 bits) due to possible jitter in the analog transmission, 4 bits is overkill we know and we may change that to support more digital support.

So lets say a,b,x,y (XBOX controller) are decoded in one of the analog channels. And lets say a and x are pressed and b and y are not.
The data transmitted would be binary : 1010 1000 or 168(decimal).
the 1010 would be a-press,b-not,x-press,y-not.
the lower 1000 is ignored by the application. Since we can't ensure that a value of n won't be read as n-1 or n+1 on the OI side the lower nibble is set to the middle of the value range. This uncertainty is do to the jitter in the OI side.

The POV will be decoded as 4 buttons. I grew up on SEGA, there's no way we're not supporting this. The only trick would to implement application code to recognize up and left pressed together as up/left, which shouldn't be hard for most teams.

So the intended use we designed for was so that through a simple calibration mode you can set the number of analog channels and which axises to use (mode 0-3). This selection would determine the number of digital slots available, in which case the next step of calibration would be to pick which buttons you want to be included in the digital transmission, we were thinking of having an led blink the number of digital slots available(4 or 12). And to select a POV button you can simply press one of the POV buttons.

So somehow the user would enable calibration mode, i.e. jumper and power recycle perhaps

1) Choose which axis profile, either using lcd outputs from controller (which is a FANTASTIC idea) or maybe number of button presses.

2) Observe led blinks to see how many digital buttons you can have.

3) press the buttons you want decoded (max 4 or 12 depending on axis selection).

4) leave calibration mode and PLAY.

Settings are saved in EEPROM so you never have to do this again.

Now this IS NOT SET IN STONE. We could use the lcd outputs to select axis mode during runtime or better yet allow us to transmit 4 times the data through indexing. My only concern is that we don't make this so complicated that only veteran teams use this.

Omar Zrien
Cross The Road Electronics

I know it would be more work for you guys, but you may want to consider the option of hooking the thing up to a PC to set up the parameters. I suppose you have a serial port that you could use (though perhaps not RS-232 voltage levels?). If so, it would be pretty easy to make a set of menus folks could navigate using hyperterminal (or whatever your favorite terminal program is). Just a thought.

As to keeping the thing easy so rookies can use it, almost every team modifies the default code somewhat. I think you could pretty easily have them cut and paste code snippets without loosing too many of them.

Just one man's opinion.

Joe J.

[Don Wright]

Sorry to get off the great technical discussion going on, but is there any chance any crosstheroadelectronics products will be at the Ford First Invitational to take a look at?

[Mike Copioli]

Originally Posted by Don Wright

Sorry to get off the great technical discussion going on, but is there any chance any crosstheroadelectronics products will be at the Ford First Invitational to take a look at?

You can count on it. They may not be fully functional, as we are still fine tuning. But they will be there.