Quote:
Originally Posted by ayeckley
Ideally we'd like to pass the [signed, 16 bit] tick count from the encoder to the roboRIO and do all related processing there. We're a LabVIEW team.
Edit: OK, I've spent a few hours rolling around in the source code and I think I've found an approach that will work. It looks likes the struct for the button data could be modified so that 16 bits could still be used for button status and the remaining 16 bits can be used for the encoder data. HID appears to offer 8x16bits for "user data" as well, but its not clear if the DS forwards that to the roboRIO or not so that won't be our primary approach. If we get it working then I'll provide an update.
|
It depends on how the HID descriptor is defined and how the software utilizes it. On the LaunchPad we are sending 8 16-bit joystick inputs coming from the ADC for the axes, and up to 32 bits for buttons (though the default options give 11 16 or 20). You could use any of these to send the data, though you have to be mindful of how Windows and the driver station use the data.
The easiest way forward would be to use half the button data as you suggested. Each button is just one bit, and fairly easy to decode on the robot.
When Windows gets the joystick data, it plays with it a little, and stores calibration data somewhere in the registry. This is why we include a section on the wiki for calibrating your inputs, and if you are using analog it is quite convenient.
The following description here is based on my experimentation with the calibration and with LabVIEW (and the driver station's) input dll.
In the Windows calibration tool you can view the exact output that you send from the LaunchPad, and during this calibration Windows asks for a minimum, center and maximum value. From here it seems to scale it for the rest of the system. So in LabVIEW if I probe the wires from the dll call, no matter what the actual data is that I send from the LaunchPad, I get a range from -32767 to +32767 based on the range I calibrated. Anything outside of the calibrated range just saturates.
Lastly, when the driver station gets this data, each axis is converted to 8-bit and sent to the robot, and is then normalized to the -1 to 1 range.
So you certainly could send data this way, you would just need 2 'axes' for the 16 bits and have the LaunchPad send it as 8 bits. Then you would need to make sure Windows recognizes the range for the 2 axis. Finally on the robot you would need to convert back to the 8-bit data and repack the 2 axes.
Quote:
Originally Posted by ayeckley
Is there a recommended approach for using the LaunchPad to interface with a quadrature encoder? We're trying to replicate the capability that the Cypress PSoC offered in previous years via the Enhanced I/O interface on the Driver Station, but we're still pretty low on the learning curve re: how we could use the HID protocol (is that even the right terminology?) to duplicate or at least mimic it.
|
I'm curious to learn a little more about your application from past years. I also was reading what you had posted in the Cypress thread. Do you have any pictures or examples of how you used this previously?
For your application, what encoder did you use? The LaunchPad is certainly capable of interfacing with an encoder, it just needs to be able to do that and send the USB packets out. An interrupt based solution would probably work well for you. We are happy to help support your team with this.
Also have you considered using an absolute encoder, something that maybe uses I2C or SPI?