The 2009 Control System Q&A Thread

[crake]

As the 2009 control system is finalized, the official FAQ posted at http://first.wpi.edu/2009_FRC_Controller_FAQ_FINAL.pdf will be routinely updated. We have gathered Q&A from the Mentor session in Atlanta as well as from some of the discussions in online forums such as those at CD. In addition I strongly encourage folks to routinely visit http://www.ni.com/community/first as new resources including training, web seminars, and documentation will be posted there as they become available.

This thread is intended to be another source of questions (and answers) that will be incorporated into the official FAQ, so if you have a question about the 2009 control system please post it. Answers posted here and elsewhere will be technically "unofficial" until added to the official FAQ.

Please keep in mind that some questions may go unanswered for now as the subject is either still being finalized or has not yet been announced by FIRST. For example, we can not yet discuss radio/camera specifics, safety protocols, field management, KOP, or pricing. Once FIRST makes this information available we will incorporate it into the FAQ. That said, feel free to still ask questions on these topics, as we will note them as a topic for future discussion.

Here is a summary of the Mentor's Q&A session in Atlanta:

Q: When can we get our hands on this? Can I buy one now?
A: The software libraries are in pre-Alpha right now. Training, including tutorials, web, and in-person training will be available throughout the off-season with focus on the fall. We don't recommend teams buy cRIO systems today as the SW experience will be different from what will be available for 2009.

Q: What about the software side of autonomous/driver?
A: There will be a lot of room for teams to design their autonomous programs. As a starting point the supplied framework will have a place to put your code, and the framework will sequence through the various modes of the competition.

Q: Will there be onboard recording for event logging? Additional memory slots?
A: The cRIO-FRC contains 128 MB of non-volatile memory (solid-state hard drive) and the majority is free for team use and there there are APIs for reading and writing. Also the wireless link will provide another method for logging to the driver station laptop in real time. While there is a C Series IO module for SD Card expansion, there are no plans to include it in the program at this time.

Q: Will we have capability of making LabVIEW APIs that are reusable?
A: Absolutely. WPI implementation is open-source and a great guide for a good library. We also hope teams and community will create additional APIs.

Q: What is the programming software aside from LabVIEW?
A: The new software is based on GCC and the development environment is Eclipse supplied by Wind River. You will be able to do real live debugging including examining variables all over wireless. WPI has this working today and are able to program their robot from home while looking at the wheels from a webcam!

Q: Can Macs or Linux be used?
A: When downloading to the cRIO, must be windows, and there has been success using Windows emulation on a Mac.

Q: Will there be limits to the number of programming seats/licenses?
A: There will be sufficient licenses for all members of the team who want to program in LabVIEW or C/C++.

Q: How many cRIO controllers will teams be able to get? Do we get a new controller every year?
A: The intent it to reuse the controller from year to year. In addition teams will be able to purchase an additional system at a significant discount on order of what teams are used to seeing and not list price of cRIO

Q: Can you write VHDL and download it to the cRIO-FRC?
A: In 2009, the FPGA image will be fixed though still flexible in functionality, and teams will not be allowed to create their own FPGA code.

Q: Can you explain a little about the sidecars/bumpers. What do they do? Do they replace hardware he has already like relays?
A: The Analog bumper is power and interconnect to your sensors. Digital sidecar does a little I/O expansion, shift register to control relays along with a 6V supply to run hobby servos. The 12V digital bumper allows for direct connectivity to drive pneumatic solenoids rather than having 4 spikes (a spike would still be used to controller the compressor). All sidecar/bumpers include cable retention so wires don't come lose.

Q: What goes in the empty slots on the cRIO-FRC?
A: The empty slots that could be used in future years. You will not be able to populate empty slots in 2009.

Q: What about Tech support?
A: There will be a large online community site for support monitored by NI application engineers. Teams will be able to ask programming-specific questions during build and competition time. Also the plan is to have the same level of on-site support at the regionals including spares and loaners.

Q: Will there be a solution database that groups can share?
A: That's one of the motivations behind a community site. Code and sharing. Open for everyone.

[crake]

Could you point me in the direction to find out more about what cameras can be used, frame size limitations and frame rate limitations?

A: The use of network cameras is part of the control system. For 2009 the plan is to have at least one camera supported though the brand and model is not yet finalized. Given the nature of having an open platform it is expected that teams will want to add support for new cameras. This involves the creation of a driver that resides on the cRIO-FRC controller and retrieves images from the camera. Of course FIRST has the final word of what, if any, restrictions may be placed on which camera models may be used.

Regarding frame size and rate limitations there are three components to consider. One is the camera itself, another is the ability of the camera/driver combination to move the images to the controller, and the third is the complexity of the image processing algorithm(s) in use on the controller. It is reasonable to expect the posting of benchmarks and other specifications as camera validation and selection is completed.

This answer will be revised as more information (such as benchmarks) becomes available.

[rfolea]

Originally Posted by crake

As the 2009 control system is finalized, the official FAQ posted at http://first.wpi.edu/2009_FRC_Controller_FAQ_FINAL.pdf will be ...

Can we request that a rev # and date be added to this FAQ so we know when it has been updated?

[Greg McKaskle]

Cameras:

Because the cRIO has 100Mb enet, no firewire or USB. This leaves us in the domain of security cameras and IP cameras. They range from quite cheap to quite expensive. Most can do 640x 480 color, but cannot quite do 30fps at that size. Dropping image size to 320x240, we can easily acquire 30fps. This doesn't mean that 30fps can necessarily be processed for content, though.

Other limits are likely to be imposed, such as a 1 or 2Mb limit of upload images per team.

Greg McKaskle

[crake]

Originally Posted by rfolea

Can we request that a rev # and date be added to this FAQ so we know when it has been updated?

Yes - absolutely.

[Leav]

Originally Posted by Greg McKaskle

Cameras:
Other limits are likely to be imposed, such as a 1 or 2Mb limit of upload images per team.

Are you talking about uploading to the driver station?

The idea is new to me, and sounds exciting... but why would you limit the size of the image?
If bandwidth is the problem wouldn't it make more sense to just throttle the bandwidth?

with such an amazing array of possibilities I would hate to see rules crippling the control system. give us the control system and let us push it to the max!
(obviously stuff like bandwidth would need to be kept in check so that everyone has a fair chance on the field and no one team is eating up the bandwidth for everyone else...)

-Leav

-----------------------------------------
Edit:
since the timeframe is set (let's say 2:15 minutes) It could be argued that a size limit IS a bandwidth limit... but obviously it isn't because if that size can max out the bandwidth for more than a few seconds than the size limitation is useless.

In other words if it takes 3 minutes (or even 1 minute) to transfer a 2mb file then setting the limit to 2mb as a way of controlling bandwidth is futile.
if it takes 3 seconds to transfer that file than obviously the system can handle a large enough bandwidth to support unlimited file size, providing that the the bandwidth be throttled down to a setting where it takes say 6 seconds to transfer a 2mb file.

[Greg McKaskle]

Sorry, I meant 1 or 2 Mb mega-bits per second. In other words, a QOS limited by the network. In Atlanta, we were uploading moderately compressed jpgs at 15fps at 320x240.

All of this is of course dependent upon the actual throughput of a wifi network tuned for the field. 54 Mb is the theoretical limit, but it is likely to wind up being more like 1/4 of that depending on protocol, encryption, interference, etc.

Greg McKaskle

[Jon236]

Greg,

This question reflects a response to Danny Diaz on another thread.

Can the final software version allow the capacity to model the mechanical system? That is, will there be VI's that represent virtual motor controllers, gear ratios and motors so that power consumption, as well as programming, can be tested before we (the programming team) yield the system to the build team?

[tdlrali]

This is more about Labview than the control system:

Will teams have access to Labview addons such as the Control Design Module or the PID toolkit? If so, will these be available through the C libraries as well?

[Greg McKaskle]

Can the final software version allow the capacity to model the mechanical system?

This is a common approach. It can also very involved depending on the complexity of the mechanical system.

At the initial release, this will not be a built-in capability of the libraries. But my hope is that by supporting a depot for code sharing, various teams can pretty quickly develop and share the modeling SW needed.

Greg McKaskle

[Greg McKaskle]

Will teams have access to Labview addons such as the Control Design Module or the PID toolkit?

That is the current plan. I'm not certain if it will be the complete package, or a subset. Honestly, I'm not very familiar with the toolkits.

Greg McKaskle

[dcbrown]

Q. The WPILIB functionality will include both LV and C libraries, but will exisiting NI LV libraries be converted into C libraries for team use also (such as aforementioned PID) or remain available in LV only? If C library form will eventually be available, is NI, FIRST, or WPI responsible for the conversion?

Q. When will the VxWorks C/C++ API as it currently exists (without FIRST/WPILIB add ons) on cRIO be released to FIRST teams from NI? For example, RPTs are not supported and there is a special driver/interface to the FPGA as an add on to VxWorks for the cRIO.

[dcbrown]

Q. In the past you could convert some Analog inputs to digital I/O increasing the available input/outputs available by up to an addional 16 lines - will the same functionality exist in cRIO are are we limited to just 14 DIO on the sidecar?

[crake]

Originally Posted by dcbrown

Q. In the past you could convert some Analog inputs to digital I/O increasing the available input/outputs available by up to an addional 16 lines - will the same functionality exist in cRIO are are we limited to just 14 DIO on the sidecar?

A: The Analog Input and Digital I/O lines are fixed and defined by the module. However you have two 9201 AI modules and two 9403 DIO modules in the system with bumpers and sidecars, so you have:

16 channels, 12-bit, +/-10V, Analog Input
each bank of 8 channels has a scanned sampling rate of 500kHz

20 PWM outputs with 6V selectable power (jumpers) for servos
28 GPIO, TTL
16 forward/reverse relay outputs
2 SPI interfaces

In addition you have 8 channels of 12V DO for solenoid and pnuematics.

[Greg McKaskle]

Originally Posted by dcbrown

Q. The WPILIB functionality will include both LV and C libraries, but will exisiting NI LV libraries be converted into C libraries for team use also (such as aforementioned PID) or remain available in LV only? If C library form will eventually be available, is NI, FIRST, or WPI responsible for the conversion?

I'm not sure about across the board. From the beginning, we intended to have WPILIB and vision in both languages. For other libraries that are made available in LV, NI may be able to provide C versions if they exist, or wrappers to any underlying C code. But the word converted implies an automatic process, and in case it isn't clear, LV doesn't convert to C, so that isn't an option. Since the goal is really to have a nice parity and symmetry between C and LV, I think between NI, WPI, and the rest of the community, we will have a really nice set of libraries for both languages.

Originally Posted by dcbrown

Q. When will the VxWorks C/C++ API as it currently exists (without FIRST/WPILIB add ons) on cRIO be released to FIRST teams from NI? For example, RPTs are not supported and there is a special driver/interface to the FPGA as an add on to VxWorks for the cRIO.

The toolchain can already be downloaded from WindRiver, as can a demo of LV from NI. C tools targetted for cRIO aren't currently a standard product, so I'm afraid that the first availability will be nearer to when the HW is available.

Greg McKaskle