I agree with the general idea of communicating back the loss of communication, but seeing that we cannot agree on how long is too long, could you consider returning an elapsed time (number of seconds since last good packet) rather than a boolean so that the higher level code can interpret it as needed and take any action desired?

Wed Sep 07, 2011 11:30 am

tfriez

Site Admin

Joined: Wed Jan 24, 2007 10:42 amPosts: 618

Re: Joystick command in RobotC v3.0

The ultimate problem here is this was a feature requested by FIRST and Pitsco (TETRIX Manufacturer). I personally agree that giving the user the option to handle the joystick "disconnected" case themselves via a notification is ideal, the problem is that 80-90% of the teams that just "plug and chug" code will not modify the flag themselves.

There is a variable that you can read right now to see how many "loops" have occurred where it has looked for a message. Because this is on a 4ms interval, you can convert the number of "missed messages" to a time. We look for 750 "missed messages", which works out to 3 seconds (4ms * 750 = 3000ms).

What I would be willing to do is modify the driver to have a "turn this feature off" flag for the "zeroing" and leave it up to the end user to read from the "missed messages" counter. I can still create a new Boolean flag when the 3 second time has elapsed, but I feel like you guys want a more precise notification, so I'm leaning towards leaving it as just reading the counter.

bobatk wrote:

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.

l0jec wrote:

I agree with the general idea of communicating back the loss of communication, but seeing that we cannot agree on how long is too long, could you consider returning an elapsed time (number of seconds since last good packet) rather than a boolean so that the higher level code can interpret it as needed and take any action desired?

I assume the zeroing of the joystick packet is to stop the robot from running away when communication is lost. If so, can't you do something similar to the FRC code where it has a watchdog timer, if the communication is lost, nobody is resetting the watchdog timer and it will time out. When that happens, the code will shut down all motors (zeroing the motor[] array). Zeroing the joystick packet whole sale has a lot of side effects as bobatk said. In fact, that will break our library code as well. We have a joystick button library where it detects edge events (i.e. the press and the release of a button). By blindly zeroing the buttons, you will trigger a "release button" event for every button that was held down.

Wed Sep 07, 2011 2:01 pm

tfriez

Site Admin

Joined: Wed Jan 24, 2007 10:42 amPosts: 618

Re: Joystick command in RobotC v3.0

Tophat's will now return -1 when there's no message (this logic was already in there for when no joystick was available by default).

The counter for missed joystick packets is now a long variable to prevent overflow issues (not reported, but accounting for it now before it's an issue)

There are now three variables that users can access from their program as well:

*bDisconnected = A flag that is triggered as soon as the nNoMessageCounterLimit is reached (remember messages check on a 4ms interval) to indicate that it has been longer than the specified time since a message has arrived.

*bOverrideJoystickDisabling = A user-settable flag that will still cause the "bDisconnected" flag to be triggered, but will not call the "zero-ing" code to clear out the last joystick packet. This flag can be modified at any time.

*nNoMessageCounterLimit = A long integer to specify the threshold for "bDisconnected" to be triggered. By default this is set to 750 counts (3 seconds), but you can modify it as you see fit.

The difficulty is that the HiTechnic Motor Controllers have a watchdog already... but it proved to be difficult to manage, so neither LabVIEW or ROBOTC watch it.

Also, since we don't know how many motor controllers the robot will have, it's difficult to just have it "zero" the motors.

I believe with the new user controllable flags, you'll be able to work around this new functionality so it will not damage your existing codebase.

MHTS wrote:

I assume the zeroing of the joystick packet is to stop the robot from running away when communication is lost. If so, can't you do something similar to the FRC code where it has a watchdog timer, if the communication is lost, nobody is resetting the watchdog timer and it will time out. When that happens, the code will shut down all motors (zeroing the motor[] array). Zeroing the joystick packet whole sale has a lot of side effects as bobatk said. In fact, that will break our library code as well. We have a joystick button library where it detects edge events (i.e. the press and the release of a button). By blindly zeroing the buttons, you will trigger a "release button" event for every button that was held down.

Tim, Thanks for the quick turnaround on this change and for really listening to and working with the teams.

MHTS, now that we have solid options in the JoystickDriver, I think we can tweak the FTC template rather than overloading/wrapping the driver. I'm thinking about adding a function call to the main loop which can check for the bDisconnected flag and call a new template function to properly disable the robot. We could either leave it empty for teams to implement or provide a default implementation which attempts to walk the motor array and zero all motors? I think servos may be more interesting as there is no way to generically know what a safe target is & the current target may be the best bet outside of requiring the students to define a safe value. We may also want to consider setting motors to coast/float rather than break for extra safety?I think playing a tone on the NXT to signal that connectivity is lost/re-acquired on the bDisconnected flag changing state would also be a great idea and potentially helpful to the FTAs.

Thu Sep 08, 2011 1:28 pm

bobatk

Rookie

Joined: Sat Nov 27, 2010 1:44 amPosts: 34

Re: Joystick command in RobotC v3.0

Timothy, thanks for the changes. They're definitely improvements.

I did want to mention one thing that teams now will seem to need to be aware of: if a disconnection occurs while a driver is holding a button down, it will appear to the software that they have released the button and re-pressed it when connection recurs. As a common way of dealing with buttons in the driving UI is doing something once-per-press, this behavior could be of significance and surprise (it's an example of the edge-events that MHTS mentioned), causing two actions to be taken by the bot where only one was intended.

The root problem here is that given the system hw & sw architecture there's actually no way to reliably accomplish what FIRST and Pitsco are looking for, which (I am assuming) is to stop runaway bots. That's unfortunate, but true. RobotC simply doesn't in general know what's connected, let alone how it's used. For example, in our team's code last year we did the I2C communication ourselves (we had zero #pragmas: it's a long story but well motivated), so RobotC didn't know *anything* about our motor controllers, servo controllers, or sensors; thus, there's no way for RobotC to automatically stop the motors.

For naive teams, zeroing the joysticks to neutral will in commonly written UIs cause their code to stop the motors, and with the addition here of the bOverrideJoystickDisabling flag, this won't be of impedance to sophisticated teams, so it's arguably the right tradeoff and what should be done. But amongst ourselves let's not lose sight of the fact that it's a definitely a hack .

Thu Sep 08, 2011 1:43 pm

l0jec

Expert

Joined: Mon Oct 27, 2008 9:59 pmPosts: 139

Re: Joystick command in RobotC v3.0

bobatk, I think having an onCommunicationLoss function in the template is the right way to bridge the gap for the less sophisticated teams as you say. It would not be auto-magic (as FIRST & Pitsco appear to be looking for), but at least the intention and proper use would be more obvious for all teams using ROBOTC to correctly stop their robot from running away.

Thu Sep 08, 2011 1:52 pm

bobatk

Rookie

Joined: Sat Nov 27, 2010 1:44 amPosts: 34

Re: Joystick command in RobotC v3.0

Regarding servos: while putting them in a safe mode on disconnect is a theoretically laudable goal, I don't think it is achievable or practical.

For example, the team's bot last year had a rotatable shoulder-elbow-write articulated arm with a total of 11 servos. Putting this arm into it's safe, packed position was incredibly difficult to do automatically even for our own code which knew all about it (largely driven by the lack of sensors reporting the servos' positions). In the end, we actually gave up even trying to do that at the start of teleop (ie: just after autonomous ended and the arm might be anywhere); rather, we had the driver signal by pressing a button that the bot was in a safe position where an algorithm (one that still needed to sequence the joints in a particular order of moves) had enough space to operate, possibly moving the bot to get clear if needed before so indicating. As an aside, working through this whole thorny issue with the team was a wonderful educational opportunity.

I think the joystick hack that stops the drive motors is probably the right tradeoff to make here, and we should leave it at that.

Thu Sep 08, 2011 2:01 pm

bobatk

Rookie

Joined: Sat Nov 27, 2010 1:44 amPosts: 34

Re: Joystick command in RobotC v3.0

l0jec, I do agree that the template/sample code that rookie teams first start with ought to be written in such a way as to bring the disconnection issue to their as something that needs to be considered in software. An onCommunicationLoss function might be one way to do that; the code sample I posted yesterday is another. There might be more.

Thu Sep 08, 2011 2:06 pm

bobatk

Rookie

Joined: Sat Nov 27, 2010 1:44 amPosts: 34

Re: Joystick command in RobotC v3.0

tfriez wrote:

Tophat's will now return -1 when there's no message (this logic was already in there for when no joystick was available by default).

Timothy, thanks for making the change.

I do see the existing logic to which you refer (at the top of readMsgFromPC()) but in version 2.26 at least, this didn't suffice. When there was no joystick physically attached, RobotC v2.26 on the PC still sent joystick messages (which the readMsgFromPC code will see as perfectly valid), it just happened to send them all as zero, causing the up-hat problem. I suspect that the issue persists in 3.0, though I admit to not having yet tested that. So I don't think the existing logic to which you refer here addresses the problem.

FWIW, IMHO this is pragmatically an issue most important in team debugging sessions rather than competition, as it's in such situations that a lack of joysticks is more likely to occur.

Thu Sep 08, 2011 2:38 pm

tfriez

Site Admin

Joined: Wed Jan 24, 2007 10:42 amPosts: 618

Re: Joystick command in RobotC v3.0

bobatk wrote:

When there was no joystick physically attached, RobotC v2.26 on the PC still sent joystick messages (which the readMsgFromPC code will see as perfectly valid), it just happened to send them all as zero, causing the up-hat problem. I suspect that the issue persists in 3.0, though I admit to not having yet tested that. So I don't think the existing logic to which you refer here addresses the problem.

I didn't quite understand the root issue here... but now that I do, I'll see what I can do.

I make no promises for 3.01 (coming soon with Samantha support), but in the near future I think we could probably mitigate the "no joystick connected" issue.

The "OnCommunicationLoss" thing is an interesting idea, but still requires user input to be "fail safe". I'm not worried about you guys - what I'm worried about is the rookie team who waits until the day of the competition to program as they are the ones who are most likely to not have something configured properly. They're also the same ones who will probably direct map their joystick values to their motors as well. Like you said, there's no "magical fix" to make everything better other than education of the users.

Just for gratification. I'll throw my debugging code for the joysticks on the forums for anyone who wants to use it.

I've made a few more additions testing with the latest version of the Samantha firmware (2.02) and FMS (2113). It now remembers the last state of the Stop Program/UserControl boolean flags and preserves these. The previous method would cause your autonomous code to start on its own after 3 seconds.

in our team's code last year we did the I2C communication ourselves (we had zero #pragmas: it's a long story but well motivated), so RobotC didn't know *anything* about our motor controllers, servo controllers, or sensors; thus, there's no way for RobotC to automatically stop the motors.

I know that I personally would be very interested in the above code, if for nothing else it would give me an opportunity to dig a little bit more into the low-level details of what's going. Also, a description of your well-motivated long-story would be educational as well.

Would it be possible to get a copy of the code low-level code? I'm mostly interested in the code that communicates with the Tetrix motors and sensors, but would love to take a look at whatever you'd be willing to make available!

Thanks in advance!

Nate

Sun Sep 11, 2011 10:50 am

Dick Swan

Creator

Joined: Fri Feb 09, 2007 9:21 amPosts: 615

Re: Joystick command in RobotC v3.0

nateww wrote:

bobatk wrote:

in our team's code last year we did the I2C communication ourselves (we had zero #pragmas: it's a long story but well motivated), so RobotC didn't know *anything* about our motor controllers, servo controllers, or sensors; thus, there's no way for RobotC to automatically stop the motors.

I know that I personally would be very interested in the above code, if for nothing else it would give me an opportunity to dig a little bit more into the low-level details of what's going. Also, a description of your well-motivated long-story would be educational as well.

Would it be possible to get a copy of the code low-level code? I'm mostly interested in the code that communicates with the Tetrix motors and sensors, but would love to take a look at whatever you'd be willing to make available!

Thanks in advance!

Nate

Doing this well / reliably is a complicated task. You have to deal with lots of funny issues like:

The motor controllers can only accept one "command" every 25 milliseconds (or maybe it's 50, I forget). If you send updates too fast then commands (e.g. reset encoder) will be lost.

You'll have multiple HiTehcnic controllers on the bus. You need to make sure they all get serviced. "Round robin" may be too simple an approach; you might want to send a motor speed update immediately instead of waiting for its turn.

The I2C speed is slow -- 10Kbps. So you want to avoid messaging where possible. E.G. don't send a motor update if no speeds have changed. Only update the servos that changed value instead of all six.

You want to deal with messaging errors and potentially reset the Controllers when this occurs.

Who is online

Users browsing this forum: No registered users and 2 guests

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