Cypress Enhanced IO

[Skyehawk]

Is Cypress Enhanced I/O no longer supported? We received the new board in the kit, but I would really like to use the old one due to familiarity, besides we already have a set-up for it.
I cannot find the palette for the enhanced I/O in the WPI library. Is it still there? If it is where could I find it? I did have a minor issue while installing the updates and utilities, this could be the problem. Thanks in advance for any help.

[wt200999]

Yes, support for the cypress board was removed from the driver station.

See DS IO, Enhanced IO, and Kinect: http://wpilib.screenstepslive.com/s/...e-2014-to-2015

[Skyehawk]

Yeah I just found it...
http://wpilib.screenstepslive.com/s/...e-2014-to-2015manner?

I am assuming I can use the SDReadValue.vi to accomplish this stuff in a similar manner?

[Greg McKaskle]

The direct DS I/O is now based on USB HID standard. This allows for a larger number of devices to be supported and even allows for teams to make their own provided the device can be programmed to enumerate as an HID device.

This is different than what we did previously, and some features are no longer supported. We are eager to hear feedback and willing to answer questions.

Greg McKaskle

[ayeckley]

I don't have access to an FRC-flavored-LabVIEW-installed PC at the moment, so I can't answer the question for myself: With the loss Enhanced I/O has quadrature encoder input to the DS been completely lost also? If so, that is a massive step backwards from my perspective. Especially in a game in which it might be useful to orient the robot via a large, multi-turn knob, for example.

Unless the performance of the DS-to-roboRio protocol has increased significantly relative to previous years, interpreting quadrature via DIO inputs (Cypress or otherwise) is not a viable option. I'm happy to be proven wrong by anybody that has successfully pulled it off. Use of a multiturn pot and analog input has some significant disadvantages in comparison (apparent to those of use that have used that approach in the past), but at this point it may represent the least-bad alternative [shudder].

[Mark McLeod]

The limitation is really in the custom hardware before the laptop, e.g., Cypress, Launchpad, etc. for processing the A/B transitions.

Why not use an Arduino or similar to handle your quad inputs and send the results to the laptop via USB?
You can write your own Dashboard code to take the input and optionally do additional processing or just send the results to the robot.

It requires more work, but it should be possible to implement your own interface to the old Cypress board if you desire.

[billbo911]

Originally Posted by ayeckley

I don't have access to an FRC-flavored-LabVIEW-installed PC at the moment, so I can't answer the question for myself: With the loss Enhanced I/O has quadrature encoder input to the DS been completely lost also? If so, that is a massive step backwards from my perspective. Especially in a game in which it might be useful to orient the robot via a large, multi-turn knob, for example.

Unless the performance of the DS-to-roboRio protocol has increased significantly relative to previous years, interpreting quadrature via DIO inputs (Cypress or otherwise) is not a viable option. I'm happy to be proven wrong by anybody that has successfully pulled it off. Use of a multiturn pot and analog input has some significant disadvantages in comparison (apparent to those of use that have used that approach in the past), but at this point it may represent the least-bad alternative [shudder].

Originally Posted by Mark McLeod

The limitation is really in the custom hardware before the laptop, e.g., Cypress, Launchpad, etc. for processing the A/B transitions.

Why not use an Arduino or similar to handle your quad inputs and send the results to the laptop via USB?
You can write your own Dashboard code to take the input and optionally do additional processing or just send the results to the robot.

It requires more work, but it should be possible to implement your own interface to the old Cypress board if you desire.

An excellent example of this is available with the Teensy 3.1.

It can act as a HID device. In the code running on it, it is simple to add an encoder, or encoders, read and process function(s). You then just return the processed value as an "axis" value. The resolution of that value will depend on your processing algorithm.
It can also be set up as just a straight joystick with up to 32 buttons, although 16 is a more practice limit, 6 Axis and one Hat.

[ayeckley]

Originally Posted by Mark McLeod

Why not use an Arduino or similar to handle your quad inputs and send the results to the laptop via USB?

That's certainly a better option than an analog approach, but our team was not expecting to have to learn a new skill-set during the build season. I guess my frustration is over the loss of a feature that we weren't expecting to lose. Was it common knowledge? If so then shame on us, certainly. We expected a lot of change resulting from the roboRIO adoption, but we weren't expecting the DS to change significantly in parallel. If anything, we had good reason to believe that it would gain functionality rather than lose features.

An excellent example of this is available with the Teensy 3.1.

It looks like a good example of basic I/O, but I think we'd need to use an interrupt-driven input for an encoder application. Our tick rates will be on the order of 10-100 Hz. We'd also want to represent the tick count in an equivalent way to the Enhanced I/O processed it (signed 32-bit integer, IIRC). Time to start reading, I guess...

[Joe Ross]

Originally Posted by ayeckley

Use of a multiturn pot and analog input has some significant disadvantages in comparison (apparent to those of use that have used that approach in the past), but at this point it may represent the least-bad alternative [shudder].

Can you expand on those disadvantages?

[Alan Anderson]

Originally Posted by ayeckley

I guess my frustration is over the loss of a feature that we weren't expecting to lose. Was it common knowledge?

The loss of support for the Cypress I/O was mentioned in pretty much every presentation I saw from Beta Test teams.

...I think we'd need to use an interrupt-driven input for an encoder application. Our tick rates will be on the order of 10-100 Hz. We'd also want to represent the tick count in an equivalent way to the Enhanced I/O processed it (signed 32-bit integer, IIRC). Time to start reading, I guess...

I believe a Teensy's (or Arduino's) main loop would be plenty fast enough to read a quadrature-encoded knob. You can easily represent its count as a joystick axis with 16 bits of precision, and while I doubt you'd need more than that for a few minutes of a competition match, it isn't hard at all to handle over/underflow on the robot and track its rotations indefinitely.

[ayeckley]

Originally Posted by Joe Ross

Can you expand on those disadvantages?

The most painful one in my memory is dealing (in software) with the rollover of the pot at low rotational speeds. Rather than a nice transition from, say 0V to 5V (corresponding to an ideal sawtooth waveform), in practice the signal becomes pretty indeterminate during the transition -- even with high quality, full-360-degree-wiper pots. At "high" rotational speeds only one or two samples might land during this time, but at low speeds the number of samples taken in this nebulous state kills the effectiveness of the various forms of software filtering and other algorithms we tried. This was back in 2008, but it's not an issue that would be specific to any particular FRC control system. Our lesson-learned was to use encoders (of various flavors and forms) in applications where this could potentially be a problem.

The loss of support for the Cypress I/O was mentioned in pretty much every presentation I saw from Beta Test teams.

Rats, I didn't pick up on it. Looks like there is an issue with the Forums page at the moment so I can't even go looking to see where I went wrong. I did talk to several Beta teams at various off-season events but the topic didn't come up.