In the years past we have tried to use very pricey and complex controllers with our robot, however since they have > 6 axis and > 12 buttons, it was hit or miss whether the button actually worked. Is there a way to read the buttons, which I would assume is button “13”, and use that to control the robot. Would it be possible to read that information off the controller in the driver station and then send it via a separate TCP/UDP packet? And then us it in reverse to access lights and such on the controller?
The Driver Station application sends only six axes and twelve buttons worth of “joystick” data to the robot. You might be able to use another application running at the same time – a Dashboard app, for example – to do more extensive communication with the controller via a specialized driver and with the robot over a different TCP connection that you establish.
Ok, so i found under the communication panel LabView’s functions for reading controllers (mine is a Space Navigator). However, it outputs an accumulation instead of a velocity. I think that I want the derivative of the data that it is outputing, however I cannot seem to get the derivative tool to work.
Any suggestions or examples?
No, I also tried the same function with an xbox controller. When I pushed forward on the stick, the number went from 0 to 1. However on the Space Navigator it went from zero and then continued rising (accumulating). I would assume that I want to find the rate at which the numbers are raising. I tried the express derivative function to determine the rate of change, but I could only get an output of zero. On the regular and the point by point derivative functions there is an input called “initial condition”, is anyone familiar with this. Finally, would running 6 derivations in real time max out the cRIO. If so, would there be a way to write a custom firmware to read the USB info, because im sure that the actual sensors measure how far the controller is moved with a defined range and not this useless accumulator junk.
Seeing as how the cRIO can decode a jpeg with 80,000 pixels in a 20ms control period, it can certainly do a few derivatives. But directly to the issue. Try just plotting the axis value and determine if it is a line, a curve, or other. Also, do you have any documentation on the controller? It isn’t uncommon for a supplier to have developer level documents on their site that describe the SW interface or the configurations available.
The initialize value on analysis blocks should receive one True, and then Falses. It is often wired with either a (first run) block or the i==0 expression based on a loop in the program. Depending on the joystick graph, you can probably just use discrete math – subtract the previous value to get the delta, and then normalize the delta between -1 and 1. I’d assume that the joystick simply adds a scaled value to an accumulated value. Note that this will glitch when/if the DS packet to the robot is dropped.
If you want to post some VIs and screenshots showing how the controller behaves, someone may have other ideas.
The Space Navigator might serve you better as a positional control than a joystick replacement. Since it’s a 3D mouse intended to control a point in space you might use it to control the absolute position of the robot on the field, or of a multi-degree-of-freedom manipulator.
Output is really a measure of torque translated to a moving point in 3D space. Twist/pull/lean harder and the point translates or moves faster.
Have you used the 3Dconnexion control panel to reduce the speed of each axis as much as possible?