View unanswered posts | View active topics It is currently Thu Oct 30, 2014 3:14 pm






Reply to topic  [ 44 posts ]  Go to page 1, 2, 3  Next
Joystick command in RobotC v3.0 
Author Message
Rookie

Joined: Sun Sep 04, 2011 10:51 pm
Posts: 2
Post Joystick command in RobotC v3.0
I downloaded the new RobotC V3.0 and cannot get the Joystick to work with code that worked in 2.26. I also looked at some sample code for the joystick and the sample does not work. I tried this on multiple computers and got the same results. Does anyone know of an issue with this?

Here is the code.

#pragma config(Hubs, S1, HTMotor, none, none, none)
#pragma config(Motor, mtr_S1_C1_1, Left, tmotorNormal, openLoop)
#pragma config(Motor, mtr_S1_C1_2, Right, tmotorNormal, openLoop, reversed)
//*!!Code automatically generated by 'ROBOTC' configuration wizard !!*//

#include "JoystickDriver.c"

//TJoystick joystick;

task main()
{
while (true)
{
getJoystickSettings(joystick);
motor[Left] = joystick.joy1_y1;;
motor[Right] = joystick.joy1_y2;;
}
}


Sun Sep 04, 2011 10:56 pm
Profile
Rookie
User avatar

Joined: Sat Sep 03, 2011 10:03 am
Posts: 32
Post Re: Joystick command in RobotC v3.0
I have the same problem. I have a very simple robot that I use for software development and testing and I cannot get the joystick to work. Everything else seems to be fine. This software is patterned after the FTC model in that it uses autonomous and tel-op modes. I did open a support ticket and sent them a file or two to reproduce it.

Have you had other compile problems? I have had a couple and one is still outstanding: Servo names come up as undefined variable.

Also some new warnings from the compiler but Xander is aware and said how to fix them.


Mon Sep 05, 2011 11:02 am
Profile
Rookie

Joined: Sun Sep 04, 2011 10:51 pm
Posts: 2
Post Re: Joystick command in RobotC v3.0
I have heard about the servo issue. it seems that you must define the varialble as an integer and then it works. I have not tried that yet since I got hung up on the joy stick.


Mon Sep 05, 2011 12:01 pm
Profile
Rookie
User avatar

Joined: Sat Sep 03, 2011 10:03 am
Posts: 32
Post Re: Joystick command in RobotC v3.0
The Variable is already defined in the #pragma statement for the servo itself. Here are the #pragma statements in my code:

#pragma config(Hubs, S1, HTMotor, HTMotor, HTServo, HTMotor)
#pragma config(Sensor, S2, HTGYRO, sensorAnalogInactive)
#pragma config(Sensor, S3, Acceleration, sensorI2CCustom)
#pragma config(Sensor, S4, HTSMUX, sensorI2CCustom)
#pragma config(Motor, motorC, Alert_Light, tmotorNormal, openLoop, encoder)
#pragma config(Motor, mtr_S1_C1_1, Leds, tmotorNormal, openLoop)
#pragma config(Motor, mtr_S1_C1_2, Trough, tmotorNormal, openLoop)
#pragma config(Motor, mtr_S1_C2_1, Elevator, tmotorNormal, openLoop)
#pragma config(Motor, mtr_S1_C2_2, RightDrive, tmotorNormal, openLoop)
#pragma config(Motor, mtr_S1_C4_1, FloorArm, tmotorNormal, openLoop)
#pragma config(Motor, mtr_S1_C4_2, LeftDrive, tmotorNormal, openLoop)
#pragma config(Servo, srvo_S1_C3_1, ClawLeft, tServoStandard)
#pragma config(Servo, srvo_S1_C3_2, ClawRight, tServoStandard)
#pragma config(Servo, srvo_S1_C3_3, Dispense, tServoContinuousRotation)
#pragma config(Servo, srvo_S1_C3_4, Expell, tServoStandard)
#pragma config(Servo, srvo_S1_C3_5, Finger, tServoStandard)
#pragma config(Servo, srvo_S1_C3_6, Fence, tServoStandard)

Here are the error messages:
**Error**:Undefined variable 'Fence'. 'short' assumed.
**Error**:Undefined variable 'Dispense'. 'short' assumed.
**Error**:Undefined variable 'Expell'. 'short' assumed.
Plus Others

Do you think that the variable needs to have another define? That would be new. The motor definitions work fine. I submitted a support ticket and Dick Swan has responded that he has reproduced the problem and is working on a fix.


Mon Sep 05, 2011 4:47 pm
Profile
Rookie

Joined: Tue Sep 06, 2011 2:03 pm
Posts: 1
Post Re: Joystick command in RobotC v3.0
I am having the same issue. Downloaded and installed RobotC 3.0. The sample program "NXT Joystick Optimized" does not work anymore. The joystick program claims that it is connected to the robot (I tried BT and USB) but nothing seems to be sent to the robot. I have opened a trouble ticket with RobotC.


Tue Sep 06, 2011 2:26 pm
Profile
Rookie

Joined: Sat Nov 27, 2010 1:44 am
Posts: 34
Post Re: Joystick command in RobotC v3.0
Some sleuthing indicates that this appears to be due to some internal change in the size of joystick messages, or at least in the buffer sizes required by the cCmdMessageRead API by which joystick messages are retrieved. If you change the value of kMaxSizeOfMessage on line 123 of joystickDriver.c from it's old value of 18 to instead be 19, cCmdMessageRead no longer returns an ERR_INVALID_SIZE error, and the joystick (in my experience) appears to function again as it did in RobotC 2.26.

Alternatively, check out www.ftc417.org/ssk for an alternate joystick driver with additional bug fixes and enhancements, a real time telemetry utility, a game configuration UI, and more.


Tue Sep 06, 2011 3:13 pm
Profile
Site Admin
Site Admin

Joined: Wed Jan 24, 2007 10:42 am
Posts: 613
Post Re: Joystick command in RobotC v3.0
This is a bug that will be fixed in the 3.01 release by the end of the week.

To fix in the mean time, change the following line in the JoystickDriver.c file (line #123)

Code:
const int kMaxSizeOfMessage = 19;  //Was 18, change to 19 to fix.


This will fix the issue. This fix will be applied in the next update.

Thanks!

_________________
Timothy Friez
ROBOTC Developer - SW Engineer
tfriez@robotc.net


Tue Sep 06, 2011 3:40 pm
Profile
Site Admin
Site Admin

Joined: Wed Jan 24, 2007 10:42 am
Posts: 613
Post Re: Joystick command in RobotC v3.0
ROBOTC and FTC Competitions only support the included JoystickDriver.c file that ships with ROBOTC. Change/Modify this file at your own risk. There have been reports from previous years that teams who have modified the driver have been disqualified as their robot did not respond to the field management system correctly.

This year's joystick driver has an improvement for zeroing out data after 3 seconds of communication loss. If there's any other improvements and fixes you would like, please send the requests to support@robotc.net

Thanks.

bobatk wrote:
Alternatively, check out http://www.ftc417.org/ssk for an alternate joystick driver with additional bug fixes and enhancements, a real time telemetry utility, a game configuration UI, and more.

_________________
Timothy Friez
ROBOTC Developer - SW Engineer
tfriez@robotc.net


Tue Sep 06, 2011 3:47 pm
Profile
Rookie

Joined: Sat Nov 27, 2010 1:44 am
Posts: 34
Post Re: Joystick command in RobotC v3.0
Timothy, I understand that your organization of course does not provide technical support for code that it does not itself produce; no one is suggesting here that it does. However, I think you speak a little too strongly about what teams on their own can successfully choose to do in their own software. The FTC Field Control System sends out it's joystick/program-control messages in a certain particular format; so long as those messages are processed correctly and appropriately by a bot's program, it need not matter how the code that processes said messages came to be.

Regarding the features and enhancements I alluded to, these are documented in the link I provided and in the headers and samples therein.


Last edited by bobatk on Tue Sep 06, 2011 5:42 pm, edited 2 times in total.



Tue Sep 06, 2011 5:17 pm
Profile
Rookie

Joined: Sat Nov 27, 2010 1:44 am
Posts: 34
Post Re: Joystick command in RobotC v3.0
P.S.: I do see the code you mentioned for "zeroing out data after 3 seconds of communication loss"; it was nice that RobotC 3.0 took a look at dealing with this condition. Unfortunately, as written, the literal zeroing that is done will cause the up position on the hat / dpad to appear pressed when communication is lost, since the quiescent state of the hat is -1, not zero; this is almost certainly not what programmers will expect or desire in their code.

Moreover, when communication is in fact lost, in practical terms the overwhelmingly most important thing that needs to be done is that the (potentially) runaway bot be stopped. This is something that can only be correctly carried out by the higher level application code (since, for example, only that code knows which motors are the drive motors for the wheels, etc.). Thus some means of signalling the disconnected condition to the programmer is called for. Unfortunately, the disconnection-detection logic added in RobotC 3.0 doesn't provide such a mechanism.


Tue Sep 06, 2011 5:34 pm
Profile
Site Admin
Site Admin

Joined: Wed Jan 24, 2007 10:42 am
Posts: 613
Post Re: Joystick command in RobotC v3.0
bobatk wrote:
Unfortunately, as written, the literal zeroing that is done will cause the up position on the hat / dpad to appear pressed when communication is lost, since the quiescent state of the hat is -1, not zero; this is almost certainly not what programmers will expect or desire in their code.


Good call. I will add in an exception for this. Thanks for pointing this out. This will be in 3.01 coming out at the end of the week.

bobatk wrote:
Moreover, when communication is in fact lost, in practical terms the overwhelmingly most important thing that needs to be done is that the (potentially) runaway bot be stopped. This is something that can only be correctly carried out by the higher level application code (since, for example, only that code knows which motors are the drive motors for the wheels, etc.). Thus some means of signalling the disconnected condition to the programmer is called for. Unfortunately, the disconnection-detection logic added in RobotC 3.0 doesn't provide such a mechanism.


I could add a Boolean flag "bJoystickDisconnected" that could be set when the zeroing out condition is set. This could allow you to set a sub-task to monitor this variable to modify your own individual control systems based on the no joystick data is left.

What about 3 seconds? Too much time? Too little? Joystick packets come every 25ms (or they should), but this time could be adjusted to prevent lockouts.

My intention was not to "bash" your custom developed drivers... we left the joystick control stuff as a .h file to allow innovation from the community as they would have a better idea of how to meet the needs vs. us developers. I will however point out that the JoystickDriver.c functionality now serves multiple purposes (to allow virtual joysticks to be used in a similar fashion to FTC control) to support our Robot Virtual Worlds. Replacing the JoystickDriver.c file will break this functionality.

We already have this year's FTC game modeled and it will be released on Saturday for those individuals using Robot Virtual Worlds to play around with the field on day one with a base "ranger" robot.

_________________
Timothy Friez
ROBOTC Developer - SW Engineer
tfriez@robotc.net


Wed Sep 07, 2011 9:36 am
Profile
Rookie
User avatar

Joined: Sat Sep 03, 2011 10:03 am
Posts: 32
Post Re: Joystick command in RobotC v3.0
I think that the additional joystick field (eg, joystick.valid = true/false) would be very helpful. If desired, people could add the code to check the valid flag after getjoysticksettings(joystick) and if false, shutdown critical motors/servos.

I like the zeroing/-1 setting as well. If people did not check the valid flag, it would still help prevent runaways.

IMHO a 5-10 second limit on com loss is in the right ballpark.

Thanks for listening.


Wed Sep 07, 2011 10:10 am
Profile
Rookie

Joined: Sat Nov 27, 2010 1:44 am
Posts: 34
Post Re: Joystick command in RobotC v3.0
Cool.

FWIW, the 'hat' problem also exists when no joystick is in fact physically connected, and that's a PC problem: it sends out all zeros in that case. One solution to that issue looks something like the following:

Code:
        // If control is started with *no* joysticks attached (or at least none logically connected
        // to RobotC) then the message that arrives from the PC has *entirely* zero values for all joysticks.
        // Unfortunately, and annoyingly, in that condition, the hat is logically JOYHAT_UP, which
        // will be interpreted by many programs as the hat being actively pushed, which will cause
        // some action to be taken by the program, almost certainly in error. As a work around, we
        // refuse to process any received messages until we see at least one with the first joystick's
        // hat not seemingly in the 'up' position. So: hands off the hat at the start of your program!
        if ((_joystickInternal.serialNumber != 0) || (_joystickInternal.rgcnt[0].hat != 0))
            {
            _joystickInternal.serialNumber++;
            _joystickInternal.msReceived = nSysTime;
            }


Wed Sep 07, 2011 10:41 am
Profile
Rookie

Joined: Sat Nov 27, 2010 1:44 am
Posts: 34
Post Re: Joystick command in RobotC v3.0
Regarding disconnection, we chose to (a) make getJoystickSettings() return a boolean indicating whether a new message has arrived, and (b) add APIs to figure out how long it's been since that's happened, leading to a usage pattern something like the following:
Code:
    while (true)
        {
        if (getJoystickSettings(joystick))
            {
            // Examine the button and hat state to determine if there's something
            // useful to do. Here, as a demonstration, we play a tune if the left
            // upper trigger is pressed. You, of course, would instead do your own
            // thing, presumably a more useful one.
            //
            if (joyBtnOnce(jyc, JOYBTN_LEFTTRIGGER_UPPER))
                {
                PlayHappy();
                }

            // Use the joysticks to manually drive the robot
            DoManualDrivingControl(jyc);
            }
        else if (joyMessageCount() > 0 && nSysTime - joyMessageTime() > MS_JOYSTICK_FCS_DISCONNECTED_THRESHOLD)
            {
            /* We haven't received a new message from the FCS in WAY too long  */
            /* So we have to consider ourselves disconnected. We take steps to */
            /* reign in a possibly runaway robot.                              */
            motor[motorLeft]  = 0;
            motor[motorRight] = 0;

            /* Play an alarm */
            Beep(NOTE_E);
            }
        }


Myself, I think three seconds is a long time to be missing a message, as they normally come at 30 per second or something. Think about a bot running at full power careening across the field when connection is lost: you really do want to stop it soon! Last year, we ran very successfully with this disconnection threshold at one second.


Wed Sep 07, 2011 10:46 am
Profile
Rookie

Joined: Sat Nov 27, 2010 1:44 am
Posts: 34
Post Re: Joystick command in RobotC v3.0
Finally: I do quite disagree on the idea of zeroing when disconnected, as this inappropriately connects concerns which are only otherwise indirectly related through the higher level code. The low level joystick code actually has no idea how the user interface is written, so it really has no actual idea as to what the effect of introducing spurious joystick state might do.

It is much better, I believe, to model the actual problem explicitly: that communication has been tardy for a long while, and that some appropriate action should be taken in the context of the rest of the high level code.


Wed Sep 07, 2011 10:51 am
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 44 posts ]  Go to page 1, 2, 3  Next

Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  



Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by ST Software for PTF.