New Info on 2009 control system, maybe
 

Just got out a training seminar at NI HQ a little while ago, and I thought I'd note the interesting bits I saw. I don't think I've seen this in any of the online documentation, though much of it seems to be in the docs on the install DVDs. Much of the detailed info seems to be in the C/C++ programming guide, so this might be more benefit to those not getting an early kit. Also, keep in mind that all this is without considering the Rules. Just because it's possible doesn't make it legal. Also, just because the GDC declares something legal doesn't make it possible. Rambling commences:

Ribbon cables work well as the digital sidecar cables. It's possible to use ribbon cables to move the analog breakouts off the top of the cRIO, though they're obviously unshielded and more noise prone.

There are currently no provisions to power the Driver Station off the robot, though it's being investigated. I think it's pretty certain there won't be any power over the ethernet tether cable, so any power solution will be a separate cable.

Some joysticks Just Don't Work with the DS. Joysticks that actually need custom drivers (not configuration software) to work just in Windows are highly unlikely to work on the DS.

DS digital inputs require active termination. You can't simply close a switch to ground or 5V and assume the internals will pull it the other way when the switch is open. You need your own pull-up/down or need to connect it to 5V or ground.

We were warned not to try powering the Power Distribution board from a bench power supply (in lieu of a battery). Given the switching power supplies on the PD board, it could cause entrainment and subsequent power supplies meltdowns.

They're rapidly researching the effects of running the practice field wireless on the 2.4GHz band to make practicing safer. They need to determine the effects on any FTC competitions.

E-Stops now latch in the robot controller. This means after E-Stopping, you MUST reset your robot for it to function again. This would be to increase safety so an E-Stop robot can only be dangerous again after the robot was power cycled, not after the field is cycled.

Random: Jaguar powered CIMs are quiet. To my "mosquito" ringer deaf ears, anyways.

All the cRIO modules are technically optional. Removing unused ones won't affect the operation of others. We were told the analog module in slot 1 would be required by rule, as it will be used to monitor battery voltage for field troubleshooting.

There currently isn't any method for displaying custom text on the DS LCD. Chances are, you're going to want a dashboard PC. Also, in non-competition mode, the dashboard pc can receive camera images and communicate directly with the cRIO for debugging. Neither will be the case in competition mode. The former for bandwidth concerns, the latter for safety.

The image processing in Labview looks pretty powerful for machine-vision tasks. Also, there's a Labview Vision Wizard program to help you develop your image processing algorithms on a PC, so you can parallel vision development with control code development. Also, you can probe images on wires while the program is running. Let me repeat that. You can probe the results of your image filtering and processing algorithms at any point you choose in the process. With a simple right click of a mouse. In near real time.

Finally, a list of the FPGA/WPILib supported special peripherals, as best I can recall them. And all of this is without costing any processing power:
four, 4x quadrature encoders, with pulse width measuring
eight, 1x or 2x quadrature encoders or counters, with pulse width measuring
two, analog signal accumulators, which means two analog gyros
two, I2C buses (with two sidecars)
two, SPI buses (with two sidecars) plus chip selects (on Dig I/Os)
serial communications through the cRIO serial port

And that's all the rambling I think I can manage tonight...

Re: New Info on 2009 control system, maybe
 

I'm not one of the team mechanics/programmers, but I thoroughly enjoyed this rambling*. Good read!

* It could also be attributed to my wanting to play with our new system soon....

Re: New Info on 2009 control system, maybe
 

Using ribbon cables would lower the maximum height of the cRIO. Replacing the provided digital cable with a ribbon cable would save some weight.

Or you can roll your own simple, unprotected, non-robust pseudo-Power-Over-Ethernet scheme with a pair of breakout adapters at the ends of the ethernet tether. I am definitely planning to do this.

Where did you get this warning? I don't remember hearing it in the main sessions, and Erik didn't mention anything about it during our somewhat lengthy discussion of the board.

The intent is to run the competition fields on the 5 GHz channels only.

They sounded just like Victor-controlled CIMs with a good gearbox to me, but I didn't intentionally try to give them too little power to get turning.

I think the digital module in slot 4 will be required too. Its associated sidecar provides the drive signal for the large amber signal light.

Re: New Info on 2009 control system, maybe
 

Alan,

Thanks for the corrections/extra info I missed. Also:
I was considering this as well, though the FRC legality of it is obviously unknown at this point. I hadn't brought it up because I hadn't looked up the ampacity of 24 AWG as would be in Cat5. Since it's 2.1A enclosed, and we have two pairs to work with, I think it'll be relatively sane. Provided you make certain to keep it the 12V away from the actual ethernet ports....
At the risk of digressing into a personal conversation, I swear I heard Chris (Jennings?) mention this early in the meeting. I can recall a fair amount of the details. Someone brought up the point that the early kits hadn't shipped with any batteries, and any rookies wouldn't have any way to power up their new controller. It was asked if they could use a bench power supply in lieu of a battery, and Chris mentioned that they'd done their testing with batteries to avoid any possible interactions between the power supplies, plus it was more realistic. (Warning is perhaps a bit strong for this) It was then noted that they assumed any rookie teams actually motivated enough to grab an early kit would be capable of buying or bumming a battery.

Now, I'll grant you that Chris isn't the expert on the PD board that Eric Van Wyk is, so he could have been extremely overcautious. I personally think the actual likelihood of a good modern bench supply generating entrainment with the PD board is very low, but I felt I should recount what I'd heard. If someone more knowledgable would like to allay any doubts about powering the system with a bench supply, I'd certainly welcome it.

Re: New Info on 2009 control system, maybe
 

15 KHz doesn't hurt. :) Should make for some quiet low power drive, which has always been a huge annoyance.

Re: New Info on 2009 control system, maybe
 

I have a 10AMP 13.8VDC power supply (an older Radio Shack model). When I hook it up to the new PD board, I get nothing. This supply worked fine with the IFI controller and the old power distribution system (for driving only the low amp motors - e.g. Globes - of course).

Does the new PD have a minimum amperage it needs to see before it will even power up, possibly because of the needs of the additional power supplies on the new board?

Re: New Info on 2009 control system, maybe
 

100, 254, and 668 have been using ribbon cables successfully on our beta unit since nearly the start of the test. We also moved the bumper boards off the top of the cRIO-they seem far too liable to being broken if they remain there.

Re: New Info on 2009 control system, maybe
 

One inaccuracy here. The SPI engine is routable to any DIO pins on either module... there is only one of them. The hardware supports streaming with 512 word buffers on both the send and receive side and buffer status interrupts (such as half full), but that is not implemented in the library yet. WPILib for LabVIEW supports single sample SPI transfers and WPILib for C++ has no support. This is a low priority system. Right now it seems there is little demand for it.

Re: New Info on 2009 control system, maybe
 

Kevin -

You are correct, using a benchtop power supply is not recommended. However, it is safe. Some revisions that never saw the light of day would become unhappy when fed with a wimpy power supply. The revs that are shipping can survive with any input supply with a nominal voltage between -20 and 20V with any supply impedence, and can survive any load impedence that does not generate power. Don't expect it to work over this range: the range of ~3V to -20V is guaranteed not to work.

It is a "feel free to do it, it just might not work" situation. The reason for this is that the switching power supplies effectively have a "negative resistance". For a given power out, lower voltage in requires higher amperage in. This can interact with the power supply's internal protection, creating two stable points:
1) The good one, in which you are getting 12V and low current from the bench.
2) The bad one, in which you have hit the current limit of the supply, and have constant current at a low voltage. If the power out of this isn't beefy enough, it will latch in this state and won't work. Nothing will be damaged.

A kit battery doesn't really have a state 2, because it can push *way* more current that the power supplies could ever want or use.

Also, the momentary loads of starting a CIM or other big motor can easily brownout most bench top supplies. You will (briefly) take 10-100 amps from the supply. A supply that can handle that is impressive. I'm willing to bet that most supplies available to teams won't handle it. You will trip the brownout protection in the PD and DSC, which will disable the drive motors momentarily (in order to protect the cRIO and Wireless). When they are disabled, the gargantu-load of the motors will go away, which will allow the voltage to rise, which will enable the motors, which will repeat the cycle. Again, nothing is damaged, but it isn't working.

Neither of these situations occur with charged a kit battery. However, a battery in its death throes will exhibit the limit-cycle behavior described in the preceding paragraph. Don't worry, this happens after the battery has been drained beyond usability. In my testing, this occurred after the battery was unable to provide enough power to move a kitbot.

Long story short:
Don't use a bench top supply.
If you do use a bench top supply, don't complain that it doesn't work.


On the other hand, the cables that connect the sensor to the breakout aren't shielded either. Yes, adding a ribbon cable adds more opportunity for noise to get in. However, it might also reduce the length of the 3 pin connectors.

6 of one, half dozen of the other. For some teams, keeping it attached the cRIO makes more sense. For other teams, remoting it with a cable will make more sense. Some teams might even want to use a shielded cable. You (generic You meaning each team) won't know until you are designing the specifics of your robot. I won't pretend to know what a team needs better than they do, so I'm happy that these connectors provide more options.

However, you probably don't want to use a ribbon cable (unless you do).

Lastly, please review the rules before selecting an alternative cable. I am expecting that the connection to the Side Cars will be required to have all 37 pins connected straight thru. We'll find out soon!

Re: New Info on 2009 control system, maybe
 

Ridiculous.

We used the 1 byte display on the IFI controller for quick pot calibration in the pits and at our practice field and for feedback about our autonomous programs. Now our drivers will have to hook up a laptop instead? Bad move FIRST.

Re: New Info on 2009 control system, maybe
 

I'm not satisfied either - I hope it changes soon.

However, I'd like to point out that for doing pot calibration, you will already have your programming laptop connected - it will be easier to probe the variable on the same computer that you will then use to modify your code.

Re: New Info on 2009 control system, maybe
 

He is probably referring to using it to calibrate the pot by mechanically moving it, or having a button reset a value stored in the eeprom. Many teams have done things like this in the past for the very reason of not wanting to download code or hook up a computer.

Re: New Info on 2009 control system, maybe
 

Got it. Good point.

Re: New Info on 2009 control system, maybe
 

Sounds like the driver's station is a real mess. Check out the thread that Joe Ross posted on the FIRST forums. When a joystick is unplugged, the controller keeps sending the old value! Clearly, they were more concerned with whiz-bang features on this system than basic safety. As a counter-example, IFI design IN HARDWARE a mechanism that if a joystick was unplugged, the output went to a safe value (so you know they were thinking about it from the outset). I grow increasingly concerned that safety seems to be an afterthought with the new system. We're dealing with such dangerous machines here - many people trust the control system to keep them safe. Joe mentioned a 2-second lag that sometimes occurs. Does this affect the robot disable signal as well?

Scary stuff. I once again suggest that everyone keep their bodies well clear of any robot powered by the new system whenever it is turned on. No more trusting the disable switch until the new system proves it is safe (which it clearly isn't right now).

To say I'm disappointed that they'd ship a system with these types of safety defects is an understatement.

Re: New Info on 2009 control system, maybe
 

I agree wholeheartedly. I fear people will assume that because the safety and disable features of the IFI system were so robust and worked so well, that this new system must work the same way (I mean, all control systems must be the same, right? ;) ).

I for one won't be trusting the robot nearly as much as before.

Re: New Info on 2009 control system, maybe
 

Now I am completely oblivious to the function of any and all electronics with the new DS, but I know there are several output pins on the side. Could these or even one of the USB ports be used to set up a second LCD screen for custom input?

Re: New Info on 2009 control system, maybe
 

Ahem. I wouldn't be so quick to condemn the safety features of the current control system, really. In particular, the new control system uses a much better philosophy for the disable switch. On the IFI hardware, the disable system was normally open, so you could run the robot without a dongle. This means that you couldn't be certain your disable switch would work when you hit it. You could be fairly sure, since it'd worked the last several times, but if a wire had silently broken, the contacts corroded, a bad solder joint worked loose, or the thing just plain wasn't plugged in... Well you were in for a surprise. The only actual secure option for disabling last year's robot was to pull the tether or radio cables.

The new DS's disable system works on a normally closed principle. Which means that your robot won't run at all unless you have a valid disable switch in place. Or unless you're foolhardy enough to just short the contacts together with a paper clip or something. Broken wires and bad soldering will annoy you with a non-running robot instead of betray you with a robot running amok. And while it's possible for contacts to freeze shorted or be bridged somehow, it's must less likely. If you're really safety minded, you'll get an E-Stop style switch with two physically separated NC contact blocks and wire them in series. So, I think the new system's safety and disable function are as or more robust than IFI's. That's definitely something I'm not going to be worried about.

For the joystick related issues in Joe's post... I think that has to do with the decision to based the DS on a micro Linux platform. What we try to do with joysticks and such presents a unique challenge to the control system, compared to what OS's usually do with USB devices. On a Windows machine, the OS uniquely identifies each USB device and tags settings and functionality to follow it around based on its ID, as opposed to what port it's plugged into. You wouldn't want to have to reconfigure your mouse if you plugged into the top port instead of the bottom port, after all. For the DS we expect it to identify the joystick based on what port it's plugged into. If arm control functionality always followed our steering wheel around after we accidentally plugged it into port #2 the first day, I think we'd all be a bit miffed. Even my limited knowledge of USB driver programming informs me that pinning things to an exact physical port is pretty darn difficult. And it doesn't strike me as at all likely to be amenable to hot-swapping. If it takes the controller 15 seconds for each port to identify the joysticks on boot-up, I don't think you want the process constantly occurring while you're trying to drive.

The problems with old and uninitialized values being sent are slightly more worrisome, but aren't likely to be life-threatening if you're following commonsense operating rules. Also, if the 127 default startup and unplugged joystick values from the IFI OI made you feel safe enough to put yourself in harm's way, then you weren't operating under particularly safe rules in the first place. I mean, 127 isn't a guaranteed safe value for every system on a robot. Pots controlling shooter wheels or telescoping slides are likely safest at 0, not 127. Pots controlling arm positions are likely to be safest at heaven knows what value. To be blunt, if you were trusting your previous robots not to try to kill you just because you were only starting them up or didn't have anything plugged into the joystick ports... You were putting entirely too much faith in Murphy looking the other way. If the new DS makes you more cautious around operating robots, it's probably a good thing.

Finally, I'm confident that a large amount of thought went into making the new system safer than the IFI system. In fact, much of what I heard at the recent training at NI was pointing out the focus on safety as well as features in the new control system. Insinuating it was an afterthought is uncalled for. In addition to the NC disable system, the designers are looking at running practice fields on the 2.4GHz band (the field will run at 5GHz) to eliminate students racing about with tether cables, attempting to both not tangle the cords AND not be run over. The new Jaguar speed controllers have NC limit switches to make devices safer for teams that use them, as well as actual barriers between the positive and negative terminals to reducing shorting. E-Stops will now latch inside the robot instead of the field, so an E-Stopped robot will need to be power cycled before it can become dangerous again. Instead of waiting for someone to plug in a tether cable to do so. I'm certain there's some other features that I haven't recalled at the moment, but this post is probably long enough at is it.

Re: New Info on 2009 control system, maybe
 

As Adam pointed out, I'm interested in calibrating a pot without changing code, either by reading the value and physically realigning or by saving the center value in eeprom as we've done in the past. It's not an option to have a software member around all the time so pit crew needs to be able to swap a pot without downloading new software. I found myself with much more free time after we added the eeprom code a few years ago.

I haven't seen the spec sheet on the DS, but I'm assuming this is possible. If not, then I'll give FIRST another 'Ridiculous' comment. Assuming the DS and rules allow it, our team is certainly capable of creating a secondary display, but many other teams aren't. Even though we can make one, it doesn't mean we want to spend our time on something that should already be provided out of the box.

Re: New Info on 2009 control system, maybe
 

Kevin, I agree that the normally-open setup of the IFI system was a deficiency (though here was a feedback LED on the OI as I'm sure there will be on the new DS so you could verify it was disabled). However, the switch position is not the only problem. If the new DS can take up to 2 seconds to get the disable command to the robot, that is a problem. A lot of damage (to people or robots) can be done in 2 seconds. I realize this is a problem that they will have to solve before competition (no one will tolerate 2 seconds of lag), but the fact that the bug exists while teams are actively working with it on their robots means that the dangerous situation is already a reality.
This is not always true - it is up to the device's driver how to treat it. There are many Windows devices that end up being identified by which port they are plugged into. In some cases, the USB devices have no unique serial number and therefore cannot be identified at all other than by which port they are plugged into.
This is built-in functionality of the USB spec. A USB host will only talk to one device at a time. When a computer boots up, it goes through a process called enumeration, which it individually identifies each device one at a time on each port. It inherently knows which device is plugged into which port because of the way the system operates. If you plug in two identical USB devices to a hub at the exact same time, it doesn't matter. The hub indicates to the host that a new device was detected, the host instructs the hub to establish a connection to the new device (in this case the lower port number), and the host sets up the new device. This process is then repeated for the other new device on a different port on the hub.
For a USB driver, not hard at all. As previously indicated, it's required. If Linux is used on the DS, then it would be fairly straightforward to implement the necessary means to identify USB devices based on the port they're plugged into.
The USB bus generates the equivalent of an interrupt when a new device is connected. The host does not have poll. I have no idea why the DS would take 15 seconds to initialize a device, but I've used plenty of Linux boxes (including small, embedded ones with tiny, slow processors) and none of them took 15 seconds to identify a device.
I would not feel safe intentionally sticking my hand in an enabled robot based on the IFI 127 default value, but I can tell you that I've seen plenty of demos and such where a joystick was accidentally unplugged, and I'm really glad that the robot didn't take off full-reverse when that happened (by reading a 0 instead of 127). It's not hard to imagine a situation where a controller falls off a shelf, gets bumped full-forward or full-reverse, and then gets unplugged (leaving the robot moving that speed under the new DS). Then, in a quick instinct, you hit the disable button only to find out that it is experiencing a 2-second lag... well you get the picture.

There are demonstrated safety deficiencies in the system that FIRST shipped to beta teams. It is not uncalled for. Someone had to prioritize the things that got developed on the DS, and obviously whatever functionality it has right now was either prioritized over the safety features that it currently lacks such as safe values when a stick is unplugged or was overlooked. Either way I don't think questioning the safety decisions is uncalled for.

FIRST robots are just as dangerous as many machines found in a shop, which typically have mechanical lockout switches and all sorts of other safety implements. Yet, with our robots our safety will depend almost entirely on the firmware in the DS and robot controller. Sure, we have a breaker that we can turn off, but how do you do that if the robot has gone nuts and is spinning dangerously fast in a circle? Being critical of the safety of the new system is in everybody's best interest. This is no time to simply drink the kool-aid. You probably think I'm overreacting, and I honestly hope you're right. If, however, I saw potential flaws in the system and didn't do something to call attention to them and someone got hurt, I would feel awful.

Re: New Info on 2009 control system, maybe
 

Doubtful. You have 8 outputs, and the data is transmitted at 50Hz at best, so bit-banging the outputs isn't likely to work well. The USB ports are thus far only for joysticks and a USB key for firmware upgrades. The Linux OS might recognize anything something else plugged into them, but you won't have any way to interact with it from the cRIO. The only real option is a dashboard laptop/netbook/PDA/whatever. I recall them saying the specification of the dashboard packets were open or would be. If so, you could really use almost anything with a LAN port on it to display things. I mean, most dashboard programs are going to be pretty lightweight. Ebay is currently listing 1,800 <$100 laptops with 1GHz or better processor and at least 512MB of RAM. I know it's not going to be as easy as just dumping a variable or two to the user byte, but an actual dashboard laptop is likely to be a lot more useful.

Re: New Info on 2009 control system, maybe
 

I agree that the difference in the physical implementation of the disable switch is better, but what happens after that I still won't trust anytime soon.

I *know* when I hit the disable switch on an IFI system, the robot is stopping.

I don't know that about this new system, especially after some of the things that have been happening. I don't care one bit about what it is designed to do, or what should happen when this switch is hit. I care what actually does happen, and if what happens is a 2 second delay after disabling, that can be a very big deal.

Yes, unsafe situations can and should be avoided and relying on the disable isn't the best idea. But in my years of FIRST I know of several times when code was downloaded or a trim was mis-set and the robot just started going/moving a joint and someone had to lunge for the switch and it had to work. Or sometimes even tuning a PID loop on a joint where someone made a programming error and it took off the wrong way; that two seconds could mean great damage tot he robot, or less likely, to a person.

I'm not really criticizing the new system, I'm just hoping people won't be so trusting of it until it has proven it's reliability; I don't think that is one bit uncalled for.

Re: New Info on 2009 control system, maybe
 

I'd just like to point out that as far as I can tell from what's been said here and on the beta forums, there's no information one way or another on whether this communications lag actually affects the function of the disable switch. That question's been asked on the beta forum, but hasn't been answered yet.

Second, I have to disagree that the joysticks holding the last sample is a safety deficiency. In most situations, this implementation is equivalent to the IFI default value system. If the USB device is controlling something like a PID positioned joint, the holding value implementation is arguably safer than suddenly jumping to any default value. As pointed out, the default value implementation is safer for most drive systems. So I think the new control system's functionality is just as safe or unsafe as IFI's. It's just different. If we want to argue them into changing it, I think it'd make a lot more sense to ask for the functionality that we actually need. As opposed to the functionality that we've grown used to dealing with. What we need is for the API to throw an error and/or return an invalid value when we try to address a joystick or axis that doesn't exist. Returning NaN would be perfect for this, as any operation on NaN returns NaN or false. I'm half certain that the PWM functions will already shutdown an output if they're commanded to output NaN. There's probably a few situations where this wouldn't completely safe things or would adversely affect things long after the joystick is replaced... But overall I think this should be preferred over switch from one less than satisfactory solution to another.

Re: New Info on 2009 control system, maybe
 

I think the best implementation would be to simply disable the robot if a joystick is disconnected, and to also require a power cycle to re-enable the robot. This would make sure that no bad data/timing error caused by the disable would make the robot behave erratically.

Re: New Info on 2009 control system, maybe
 

Problematic and probably overkill. How do you implement default code that doesn't need to be changed to run a robot if missing a joystick means the robot won't run? Plus, disabling the whole robot when a joystick read fails probably takes more work.

Re: New Info on 2009 control system, maybe
 

It would only disable the robot if a joystick, which would have been enumerated at the beginning, produces multiple bad reads in a row. This way it would only disable if a joystick went missing while it was running, it wouldn't check at boot. Or you could have it check for joysticks at boot, and simply have four boolean values that need setting.