loading
 
Conversion error when acquiring Joystick values using RR_API
AM_ZEN from United States  [6 posts]
6 years
As the title conveys, I am trying to transmit joystick values using RR's API.  The API is up and running and I am currently able to display the joystick values inside my windows form.  My problem is trying to convert the string associated with the joystick value to it's actual integer value.  Here is a short code snippet that frames the context of my dilemma.  

RR_API rr;
rr.open("c:\\Program Files\\RoboRealm\\RoboRealm.exe", PORTNUM);
char getBufferDammit[64];
  //my angry buffer
rr.getVariable("Left_Joystick_X", getBufferDammit, 64);
  //Request RR 4 data
RR_Temp_String = gcnew String(getBufferDammit);    
  // RR_Temp_String is  a middleman who moves the string from RR to here

txtbox_LeftJoy_X->Text = RR_Temp_String;  
  // This will sucessfully print the each of the 30 or so different joystick values to my form....however........

String^rrTmp = gcnew String(RR_Temp_String);
  //dummy string placeholder for different conversion attempts

Now at this point no conventional methods are able to convert "rrTmp" into its equivalent integer value without freezing up the RR_API and crashing everything....I am only having this problem with the joystick module.  The code compiles with no errors for each of the below methods....In fact, I use these same methods to get values such as COG_X without a problem.
Failed methods:

_int64 Bad64 = Convert::ToInt64(rrTmp);

_int32 Bad32 = Convert::ToInt32(rrTmp);

_int16 Bad16 = int::Parse(txt_LeftJoy_X->Text );//Ironic this won't work

int Left_Joy_X = int::Parse(txt_LeftJoy_X->Text );

int Left_Joy_X= (int)rrTmp;

All attempts have failed when using std:: string conversion methods I am familiar with as well.

The irony here is that if I use one the above methods but use an 'unsigned int'  then I'm in business.....well that is with positive values only... :(  

Any suggestions?  
AM_ZEN from United States  [6 posts] 6 years
I managed to solve this problem.  
        std::string   HoolaGirl(getBufferDammit);          //Move the Roborealm buffer into the string HoolaGirl

        std::stringstream str(HoolaGirl);     // Start Streaming HoolaGirl --->(into)--->str //

        int LeftJoy_X;        // The actual integer value for the Joystick

        str >> LeftJoy_X;     // Start Converting and Streaming str ---> (int) Left_Joy_X//

        int dummy = LeftJoy_X;  //dummy value used for debug only

        Debug_TextBox->Text = Convert::ToString(bigdummy); // Converts bigdummy from int to a string that's shown in the debug box
Anonymous 6 years
Maybe this is a little late but how about just using atoi or atol?

I'm assuming you are using C++?

int LeftJoy_X = atol(getBufferDammit);

Debug_TextBox->Text = Convert::ToString(LeftJoy_X);
AM_ZEN from United States  [6 posts] 6 years
Both 'atol' and 'atoi' were able to work as well.  Thank you....

I though it was odd  that the Visual Studio Convert:: routines were not able to convert values when they were negative.  The MSDN documentation says that they should and advocates their use.  

I've been impressed with the joystick module so far.  I am using a hacked original XBOX controller ported through a HID gamepad driver and the module has picked up every button on the controller and associated it correctly with its intended function.  I was fully expecting  to have to port this driver into my bot program until I stumbled on this gem of a module.  That would have made the third USB driver in my program thus far. Good work!!!
Because of the Joystick API program I am able to send all of the controller data over the RR API that I have already integrated into my code.  

There are a few odd things I have noticed with the joystick driver module that I have encountered that may be worth noting.  The first is that if I disconnect my controller and then try to launch the RR program that uses it, RR will not even open and I get a dialog box on the screen from RR referencing some missing memory address that it wants.  This was fixed by plugging the controller back in.  
Second is that all of the X/Y Joystick quadrants are rotated 90 degrees clockwise from how one might expect them to be.  I overlooked this and it caused me several hours of troubleshooting my program before catching this.
A weird fact about xbox controllers is that all of the buttons on them are analog instead of digital.   My guess is that this feature was intended to be used to set a sensitivity threshold for what validates a pressing a button intentionally or unintentionally.  I'm surprised that RR doesn't report the actual (0-255)value...It only shows a bool value.  

For those of you guys looking looking to find a cheap solution for a controller I would recommend trying your xbox controller.  If your not comfortable programming there is a site out there that host a driver made that may work with RR.  If your familiar with with USB drivers/ Win DDK,  this controller is about as easy as it gets once you get the device enumerated correctly.   In our project we have replaced a pair of 400$, completely un-hackable/proprietary, spektrum DX9 airplane controllers for my dust ridden bottom of my closet xbox controller that was free. Not to mention RR does half the work for you once you get it connected.

AM_ZEN from United States  [6 posts] 6 years
The controller interface in action

 
Anonymous 6 years
AM_ZEN,

Thanks for the synopsis. I wasn't aware of the analog capability of the XBox controller. Seems to make sense, if over time the sensor gets a little worn you can still detect a click by altering the threshold in software ... nice thinking!

STeven.

This forum thread has been closed due to inactivity (more than 4 months) or number of replies (more than 50 messages). Please start a New Post and enter a new forum thread with the appropriate title.

 New Post   Forum Index