The 2009 Control System Q&A Thread

[jhersh]

Q. As the FPGA code is finalized, will NI release a list of sensors that will be supported?

When the list of supported sensors is announced is up to FIRST. However, I’d like to know what you have in mind, as I asked here.

Thanks,
-Joe

[Alan_Anderson]

If FIRST switches to motor controllers that run on a bus (I2C, SPI), then none of this will matter. They even put bus terminals on the sidecar.

It wouldn’t matter for motor control, but it still matters for servos, as Kevin pointed out a few posts ago:

…this resolution issue is going to now be a permanent feature affecting the use of standard RC style servos, and that isn’t going to improved by any new motor controllers.

I don’t think a reduced servo resolution will end up being a problem, but it certainly looks like it will be a “feature” of the new system.

[jhersh]

Virtually all the IO in a cRIO passes through the FPGA chip in the chassis, so that’s where the PWM pulses are going to be generated. Given the fact that it’s probably going to be running a loop at tens of kilohertz or more and has a 40MHz clock, the precision and resolution of the FPGA aren’t a limiting factor. The sole difficulty is the update rate of the 9403 DIO card. Given that the other option is a 9401 with 100 ns update, but only 8 DIOs, I can understand the choice for the 9403. It bugs me, but I can understand it.

It is unfortunate that it happened to work out that the resolution of the PWM signal dropped from 5us to 6.625us. One thing to keep in mind is that the devices you are controlling have a resolution associated with them as well. I’m not sure of the actual resolution of the Hitec 322HD servos since I can’t find any specs in the Hitec Servo Manual about the resolution other than that the resolution is higher for digital servos (322HD is analog as stated here), so it is unlikely that the change in resolution will affect the current hobby servos that we use. As for the other device that we control with this signal, the Victor, I used a high resolution counter to sweep across the input range in 1us steps and measured the voltage to get a transfer function for the Victor. This is the profiling data that Chris Rake was referring to. It showed that the Victor generates 127 discrete voltages across its range. So in this case as well, there should be no discernible difference in performance. Clearly this only addresses the equipment available in the past that we have lots of investment in. The future of controllers in the kit and what the rules will allow is unknown. They may be new, but they also may not change. At least if they don’t change, we can expect the same performance that we’re used to.

Also, with these PWM signals, not just the resolution is important, but also the range. This also needs to be a good fit for the devices you are controlling. In a test I did with one 322HD, the servo responded outside of its spec’d 0.9us to 2.1us range, which means the new control system’s PWM signal can give you more range out of the servos than you could get previously.

Also important to remember is that any inputs need to stay below about 140kHz if you’re expecting to catch all the transitions. That’s assuming a 50% duty cycle. So for quad encoders, I think it’d be smart to stay below 50k cycles per second. So a 1024 cycle per rev encoder should stay below 6000 RPM. I know that’s going to be pretty hard to stay under given the 5,000 interrupts per second limit we’ve been operating under so far, but I’m sure you’ll all manage somehow.

The encoders, pwm generators, etc are running at just over 150kHz on the FPGA. This means that any signal you have going in to or out of the NI-9403 should not have 2 transitions in the signal closer together than 6.625us. It’s true that we would all like to be able to have faster transitions, but the trade-off for cost, space, and channel density seem like a good thing.

The key improvement here with the FPGA is that if you have 1 encoder or 8 encoders, you can run all of them at full rate without one affecting the other. Certainly not something that was possible previously. The NItro demo was using 3 quad encoders that were 1250 pulses per rev (5000 edges per rev) coupled to the output shafts of the ToughBox transmissions with one CIM each. This was excessive resolution since we determined that the transmissions themselves had between 400 and 500 ticks of slop in them. I think encoder support will no longer be a short pole in the tent.

[Kevin_Sevcik]

Also, with these PWM signals, not just the resolution is important, but also the range. This also needs to be a good fit for the devices you are controlling. In a test I did with one 322HD, the servo responded outside of its spec’d 0.9us to 2.1us range, which means the new control system’s PWM signal can give you more range out of the servos than you could get previously.

Just FYI, as shown in that IFI post I linked, even the standard IFI signals range from .9ms to 2.1ms. And the user controlled ones could, in fact, be configured for nearly whatever range and resolution we liked. So this isn’t actually an improvement, per se.

The encoders, pwm generators, etc are running at just over 150kHz on the FPGA. This means that any signal you have going in to or out of the NI-9403 should not have 2 transitions in the signal closer together than 6.625us. It’s true that we would all like to be able to have faster transitions, but the trade-off for cost, space, and channel density seem like a good thing.

Erm. That was sarcasm. I’m fairly confident we won’t actually be limited by the input frequency, especially given the current update rate of our motor controllers.

[Bomberofdoom]

Q: Which module is the PWM output one?

Q2: If we don’t have the new distribution block, can we use/ alternate the old electronic system and connect the CRio through it to the current motors?

[jhersh]

Q: Which module is the PWM output one?

The PWM signals come out of the 9403. There is a break-out board that attaches to it that will provide the needed buffering.

Q2: If we don’t have the new distribution block, can we use/ alternate the old electronic system and connect the CRio through it to the current motors?

The cRIO controller needs 24V to run. The new power board has a power supply on it to provide that 24V even when the battery voltage droops. With the exception of needing 24V, the rest of the old electrical system can be used to power motors. If for instance you were doing a bench test and powered the cRIO with a 24V power supply plugged into the wall and the motors were powered through the old breaker panel, it would work just fine.

Cheers!
-Joe

[Jon236]

Joe,

On The FIRST Community website, the tutorial: “NI CompactRIO Project and Building Source Distributions” refers to adding Targets. As I read it, this requires LabView Real-Time or one its sister programs. Will we be able to download a module to our existing LV 8.5 to enable us to do this?

---

[jhersh]

Joe,

On The FIRST Community website, the tutorial: “NI CompactRIO Project and Building Source Distributions” refers to adding Targets. As I read it, this requires LabView Real-Time or one its sister programs. Will we be able to download a module to our existing LV 8.5 to enable us to do this?

---

You are correct. You will need LabVIEW RT if you choose to program the controller in LabVIEW. I believe the LabVIEW RT module will come on a DVD with the rest of the software needed. I don’t know that it will be available as a download.

-Joe

[Jwxie]

great
i am reading this
it will help my team to start

[Mike_Copioli]

Does anyone know if it is possible to display data using the onboard LCD on the drivers station? I could not find anything in the C++ libs or docs. Is it possible using the NI interface? It would be nice if we could use the LCD to provide feedback.

[Joe_Ross]

Does anyone know if it is possible to display data using the onboard LCD on the drivers station? I could not find anything in the C++ libs or docs. Is it possible using the NI interface? It would be nice if we could use the LCD to provide feedback.

See section 3.1.8 of the manual.

[Mike_Copioli]

Thanks. Question about these issues listed below. Have they happened during any of your testing?

• Occasionally, communication will lag by about 2 seconds. The workaround is to unplug any Ethernet cable for a second, then plug it back in.

I assume this could also happen during a match.

• Occasionally, communication will stop between the DS and the cRIO. One way to notice this the robot will stay disabled when you enable. The battery voltage on the DS display will also not update. The workaround is to unplug power to the DS and then let it reboot.

Same statement as above. With the documented 55 second max boot time this would pretty much disable the robot for the majority of the match.

[tdlrali]

I’m pretty sure they are going to take care of those issues before competition season comes around. If it doesn’t get fixed, FIRST will quarter whoever is responsible.

[codes02]

Q: As stated in the 2009 Control System Manual section 3.1.1, the Driver Station runs ‘Linux’. As Linux (probably in addition to other software on the driver station) is governed by at least the GPL v2 (particularly section 3), and as US FIRST is distributing the software, where may I download the source code for the GPL’d products utilized by and distributed for the Driver Station?

[Samuel_H]

Hello codes02,

Thank you for asking, unfortunately, this site might not be the best place to bring this (possible) omission up. I would recommend emailing [email protected], FIRST’s contact email for matters relating to the FIRST Robotics Competition, to get a response from those who are better able to fix any oversight.

Thanks,
Sam

[mike75]

Any ideas on what connector(s) to use on the 3x20 User I/O pin set on the driver station? I’ve been looking for days and can’t find any good options. Thanks!

[Magnechu]

1. When we try and update the CompactRIO Imaging Tool, it comes up with a message saying:

“Unable to assign an IP address for the CompactRIO device. Ensure the IP Reset switch on the CompactRIO device is turned off.”

Tried with both configurations.

2. Also, what are the purposes of all the switches next to the IP Reset Switch?

Thank you!

[Alan_Anderson]

Any ideas on what connector(s) to use on the 3x20 User I/O pin set on the driver station?

Standard RC servo connectors work great. I’ve bought them from http://www.hansenhobbies.com/ in the past.

[codes02]

Hello codes02,

Thank you for asking, unfortunately, this site might not be the best place to bring this (possible) omission up. I would recommend emailing [email protected], FIRST’s contact email for matters relating to the FIRST Robotics Competition, to get a response from those who are better able to fix any oversight.

Thanks,
Sam

In case anyone was wondering, I sent an email to FIRST as soon as I read Samuel’s post (thank you for the prompt response).

As it has been 11 days, and I have received no reply, I sent resent the same message to them a few minutes ago.

[professorX]

1. When we try and update the CompactRIO Imaging Tool, it comes up with a message saying:

“Unable to assign an IP address for the CompactRIO device. Ensure the IP Reset switch on the CompactRIO device is turned off.”

Tried with both configurations.

2. Also, what are the purposes of all the switches next to the IP Reset Switch?

Thank you!

I’m having the same problem.
Before it asked you “Ensure the IP Reset switch on the CompactRIO device is turned off” did it say to turn safe mode on?