I agree with everything that Dick said; this is definitely rocket science code. And he didn't even get into the task-locking regimen that one must observe, or the heart-beat messages one must sent to avoid the controllers shutting things off, etc.

That said, we've used this approach since about the middle of last season on through St. Louis and over the summer, all with literally no observed issues suspected as being attributed to this cause, and so we feel pretty good about it. Admittedly we haven't stressed it in a huge number of bot configurations, but the bot it has run most on was a six-motor, 11-servo, four-controller beast, so we've done more than trivial testing, but undoubtedly not as much as Dick has done. We have been running the controllers successfully as sensorI2CCustomFast, so haven't had apparent speed issues, though we already do some (but not all) of the optimizations he mentioned. We learned much about how to successfully drive the I2C bus by examining the inner workings of Xander's driver library, which has to deal with many of the same things, though in a sensor context rather than a motor or servo one.

One of the nice things with this approach is, indeed, to be able to initialize and / or configure the motor controllers when we need or want to. We do this at every program start up; that avoids the motor-coast-instead-of-brake issue that we otherwise saw in our old #pragma code if we powered the 12V after the NXT instead of the other way around. We do it even more frequently in our drive-a-bot outreach code, as that allows us to power-cycle the 12V to disentangle bots without having to restart the software to re-establish motor configuration (such as which motors are reversed).

Another nice benefit of the design is that we can set all of the servo initial positions to reasonable values before any of the servos get powered instead of having the setting first servo on a given controller power all the servos thereon even though the remaining five haven't yet been positioned to a valid value, thus avoiding strain on the servos.

We generally are trying to make a large fraction of our code available as a Software Starter Kit, though no where near all of it is yet polished enough to be ready for prime time, and the rocket-science stuff probably comes later rather than sooner. That said, on the understanding you'd be getting alpha code, we'd be happy to send things out directly to those interested before we manage to get things more fully polished; drop us a line.

Why does robotc give me this to this code:
**Error**:Undefined variable 'joystickCopy'. 'short' assumed.

This compiles just fine for me in ROBOTC 3.04 in both virtual worlds and physical robots mode. Have you modified your joystickDriver.c file manually?

Well i have 3.03 but it could have just downloaded wrong, anyways ive adapted my code so that i don't need JoystickDriver.c but could have been that my computers operating system is outdated?

I was too busy with this FTC season so I didn't pay too close of attention to this thread and made the assumption that this issue is already fixed. But then we hit a strange problem in our code and led me to look at this thread closely and examine the joystick driver code very carefully. I think I found an issue with the current joystick driver.
First, let me explain what problem we hit. We have an elevator driven by a Tetrix motor with encoder so we know what height the elevator is at all time. We defined the tophat UP button to raise the elevator to the "next higher height" and the tophat DOWN button to lower the elevator to the "next lower height". Occassionally, we observed that the elevator will raise to the next height by itself without anybody pressing any buttons on the joystick. This can happen only if our button event handler detected a press of the tophat UP button (i.e. transition from -1 to 0). Since nobody was pressing any button, this is impossible. Then I remember this thread. There must be a "disconnect" that caused the joystick driver to zero the joystick settings. But re-reading the thread suggested that it was fixed and the tophat would be reset with -1 instead of 0. So how could this still happen? Then I examine the joystick driver code VERY carefully and I think I found the culprit. Here is the excerpt of the code:

I suspect after the memset(joystickCopy, 0, sizeof(joystickCopy)) line was executed, the task was preempted and getJoystickSettings was called so it copied the "zero'd" joystick packet before the task has a chance to "reinitialize" the TopHat values to -1. This triggered our button event handler that detected a "button change". The fix is to enclose this code in a critical section like the following:

I will try this fix tomorrow. I am pretty sure this will fix it.

Hmm, thinking about it some more, I think it's better to include bDisconnected into the critical section as well because the state of bDisconnected should be part of the atomic operation.

We've made the changes with the critical section/displaying diagnostics and also the mode/disable flags. This will be posted in 3.05, due out in a week or so.

Thanks Tim. Were you able to fix the 'off-screen' debugger windows as well? We spent hours last week debugging an issue where both the Joystick - Basic and Joystick -FTC debugger windows were enabled causing the joystick to provide 'jittering' behavior.

Once we disabled the off-screen 'Basic Joystick' debugger window, things worked fine. One could argue that it shouldn't be possible to have both Joystick windows selected, but at least if they were both visible, it would be more obvious something was wrong.



Nate

Thank you, Tim. Looking forward to downloading 3.05!

That was posted on Dec. 6, and it's now Christmas eve. Any update on when we should expect a new release? It's getting close to 'crunch' time, and if it's delayed much further, we won't be able to use it enough to be comfortable with it before we compete.

Thanks!


Nate

It's getting so close that even if it is released now, I may hesitate to upgrade because we may break things and we need to validate all the code again. That's too close to the competition. So unless you need a fix to unblock one of your features, I wouldn't go for it at this point.

GAAAH! RobotC frustrates me sometimes...

Now we need to see if this works and if not, we need to ditch/modify the menu chooser thing we made for the competition

They really need to work out the details of these bugs BEFORE a week before competition (grr....)

We have a menu chooser that works perfectly. You can take a look at it here:
http://proj.titanrobotics.net/hg/Ftc/20 ... lib/menu.h