View Full Version : The 2009 Control System Q&A Thread
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.
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.
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
27-04-2008, 09:23
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
Can we request that a rev # and date be added to this FAQ so we know when it has been updated?
Yes - absolutely.
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
27-04-2008, 11:23
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
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?
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
27-04-2008, 13:22
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
27-04-2008, 13:25
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
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.
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?
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
27-04-2008, 20:43
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.
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
First, some quick background. I love NI hardware, but really don't like LabView. At my Co-Op we used a whole bunch of your hardware (M-Card, 8-port serial card, 4 axis motion control card, can bus module, VBAI) to build a testing robot and ran it from Visual Basic in Windows XP.
I really like the ease of using calls to the CVI libraries... will the same CVI calls be available in the Wind River C environment?
Also, I don't know how much of your (awesome) vision system you're including, but do you know if we'll be getting vision assistant or VBAI?
If you can pick... I find VBAI much easier to use and more powerful, and it's very easy to load up an inspection with a CVI call.
How much resolution do the PWM outputs have? What frequency do they output at?
One last question on the 150lb weight limit: If this is true, why are batteries and bumpers not included in the weight limit? FIRST robots currently weigh a good deal more than 150lb with a full complement of bumpers and batteries. Sorry, I was thinking 120lb not, 150. :o
Thanks,
-q
I'll focus on the HW answers (Greg can snag the SW):
How much resolution do the PWM outputs have? What frequency do they output at?
A: The PWM periods are configurable and the 9403 DIO module has an update rate of 6.625us. The period would depend on the type of motor controller that is used. While I can not speculate on future motor controllers, I can say that the IO module was selected with this update rate (and the resulting resolution/period ratio) in mind.
One last question on the 150lb weight limit: If this is true, why are batteries and bumpers not included in the weight limit? FIRST robots currently weigh a good deal more than 150lb with a full complement of bumpers and batteries.
I don't know that answer for 2009 - that will be completely up to FIRST.
Russ Beavis
28-04-2008, 09:57
Regarding the 150lb weight limit, I certainly hope that a 120 lb robot + 15 lb bumpers + 13ish lb battery doesn't "weigh a good deal more than 150 pounds".
A few years back, we learned that not all SLA batteries are created equal. There are mass differences between samples and we found out that robot weight changed substantially depending on which battery was installed during inspection. So... for consistency, we now weigh robots without the 12V SLA battery installed.
Russ Beavis
Chief Inspector
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
I'm not sure I understand the answer. I'm not looking for the toolchain or C tools, but rather just the documentation of the API for what currently ships with cRIO in terms of cRIO's version of VxWorks and the special FPGA interface. Since the C programming interface is not currently customer visible, my interpretation of the above is "Not currently available, will be created and shipped with the H/W"?
Greg McKaskle
28-04-2008, 22:40
Your interpretation is correct. The C interface for the FPGA are not released yet.
Greg McKaskle
Greg McKaskle
28-04-2008, 23:06
I really like the ease of using calls to the CVI libraries... will the same CVI calls be available in the Wind River C environment?
Also, I don't know how much of your (awesome) vision system you're including, but do you know if we'll be getting vision assistant or VBAI?
CVI is not released for cRIO, or for other RT targets. The WPILib libraries will be included with the ANSI, and posix libraries provided by WindRiver.
I'm not positive about the licensing of the visions stuff. I think that Vision Assistant will be in the kit.
Greg McKaskle
Your interpretation is correct. The C interface for the FPGA are not released yet.
Greg McKaskle
I'm still confused as this is (may be) an answer to only half the original question? The other half had to do with the VxWorks API as supported on cRIO. RTPs, for example, are not available in the VxWorks port on cRIO. It would be very useful to know which set of components of the VxWorks API that are NOT in the cRIO. I think the answer is the same, "information not currently available, will ship with h/w"?
Thanks for the clarification.
Danny Diaz
30-04-2008, 16:01
It would be very useful to know which set of components of the VxWorks API that are NOT in the cRIO. I think the answer is the same, "information not currently available, will ship with h/w"?
I'm afraid that's correct; LabVIEW customers are completely unaware of these nuances, and that's the way it should be - an end user application shouldn't care what happens in the OS, so long as everything works like it's supposed to. And, in fact, we work hard to make the end user experience the same no matter what OS they're working with; of course there will always be subtle (and sometimes not-so-subtle) nuances, but that's par for the course.
I would expect such OS documentation will ship with the final product, and hopefully you won't be subject to working directly with the OS but through heavily tested interfaces such as the WPILib.
-Danny
I would expect such OS documentation will ship with the final product, and hopefully you won't be subject to working directly with the OS but through heavily tested interfaces such as the WPILib.
-Danny
This is only true for the the LabView environment.
If working in the C/C++ environment, I'm not sure how you wouldn't end up working with the OS since you need to at least create tasks and schedule them... I seriously doubt the WPILIB will package up the necessary routines to create/schedule/prioritize kernel tasks, do data stream logging i/o, etc. which is already available within the OS API. The duplication effort would not seem to add value -- but anything is possible.
Danny Diaz
30-04-2008, 18:12
If working in the C/C++ environment, I'm not sure how you wouldn't end up working with the OS since you need to at least create tasks and schedule them... I seriously doubt the WPILIB will package up the necessary routines to create/schedule/prioritize kernel tasks, do data stream logging i/o, etc. which is already available within the OS API. The duplication effort would not seem to add value -- but anything is possible.
I think it would add extreme value - even Microsoft finally "saw the light" with its new driver architecture framework in Windows Vista. In order to perform "standard operations", there was a "list of things every driver had to do." Finally someone said, "Hey, if we always have to do this, why not give us an interface so that we give you the information for the specific thing we're doing, and you do all that boiler plate code FOR US." I would hope the WPILib will handle the boiler plate code for you, and not force you to become entangled with OS specific drudgery.
But then again, anything is possible. ;)
-Danny
I think it would add extreme value - even Microsoft finally "saw the light" with its new driver architecture framework in Windows Vista. In order to perform "standard operations", there was a "list of things every driver had to do." Finally someone said, "Hey, if we always have to do this, why not give us an interface so that we give you the information for the specific thing we're doing, and you do all that boiler plate code FOR US."
-Danny
A standard i/o & driver framework definition exists within VxWorks, its pretty orthagonal to the driver framework in linux/unix, but NI chose not to use this standard. Instead the cRIO driver is implemented in a different/custom fashion. So your statement may in general be true, but even NI finds instances where it isn't.
Currently there are between 250-300 different component libraries within VxWorks kernel each with a average of 8-10 interface calls... device drivers as being supplied by WPILIB represent 5% or less of that total API call interface. I just don't see the WPILIB providing all the templates needed to hide the other 95% of the operating system interface so C/C++ programmers don't have to call any OS functionality.
For example, I doubt that the WPILIB will provide a callable inertial navigation system (INS) whereby you can customize at the call interface specifying how many sonar, IR, quad encorders, gyros, accelerometers, GTS, and other specific sensors exist on your particular robot. To implement your own INS, you will need to use various services of the operating system plus the drivers supplied by WPILIB.
from "VxWorks, KERNEL API REFERENCE Volume 1: Libraries"; some of these are undoubtedly not implemented in the cRIO port of VxWorks, but most should be there.
Kevin Sevcik
01-05-2008, 13:32
How much resolution do the PWM outputs have? What frequency do they output at?
Well if FIRST is planning on using the IFI Victors and doesn't find an alternative speed controller, we know the maximum effective resolution achievable on the Victors is 97 counts on either side 0. This despite the IFI RC's actual resolution of 127 counts on either side of 0.
Now, the 9403 has an update rate of 7us. Given that we have to vary our pulse by 1ms for a "full" range of control, that gives us about 143 counts of resolution over the full range. As opposed to the 255 counts on the IFI RC. (Presuming the IFI pulse work out to exactly 255 for 1-2ms variation) When you add in the Victor's deadband and only 97 output steps, you end up with an effective resolution of 54 output steps with the cRIO/9403/Victor combination.
I realize that we're not doing rocketry control systems here, for the most part anyways, but effectively halving our output resolution annoys me, as one or two counts can definitely affect how straight your robot's driving. Especially considering this is the Control System of Tomorrow and the motor control system now seems to be less capable than the Control System of Yesterday. I think following in NASCAR's Car of Tomorrow footsteps is taking the Overdrive theme just a bit too far.
Kevin Sevcik
01-05-2008, 23:56
A: The PWM periods are configurable and the 9403 DIO module has an update rate of 7us. The period would depend on the type of motor controller that is used. While I can not speculate on future motor controllers, I can say that the IO module was selected with this update rate (and the resulting resolution/period ratio) in mind.
*chokes* umm. If you're implying that they selected the 9403 because of the 7us update as opposed to in spite of it then that's disappointing. Considering they were obviously planning from the start to use the IFI Victor speed controllers, and that a 7us update rate combined with the 1ms variation for the Victors yields an astounding 143 counts of resolution.... Well if they were planning on purposefully making the Victors annoying to use and less reliable, then mission accomplished, I suppose. I was assuming that the trade-off was to gain 32 DIOs in a compact form at the price of poor resolution with the Victor controllers.
If you're implying that they selected the 9403 because of the 7us update as opposed to in spite of it then that's disappointing....
That's not quite what I was saying. The 9403's update rate (which really is 6.625us if you want to be precise) was well known and understood when the module was selected. Also the selection process included detailed performance profiling of various motor controllers when used with the 9403.
I realize that we're not doing rocketry control systems here, for the most part anyways, but effectively halving our output resolution annoys me, as one or two counts can definitely affect how straight your robot's driving. Especially considering this is the Control System of Tomorrow and the motor control system now seems to be less capable than the Control System of Yesterday. I think following in NASCAR's Car of Tomorrow footsteps is taking the Overdrive theme just a bit too far.
Well, I can say that with the amount of resolution on the speed controllers as it sits right now, our 'rocketry control system :) (http://www.youtube.com/watch?v=RjGyQPax5Vo)' wouldn't have worked with any higher of a minimum ouotput power. You can (even with the 3% throttle and resolution available now) still see our 2008 robot shimmy as it's dynamic braking to enter an interpolated arc motion (just check out any videos on TBA of our autonomous, especially Midwest and Archemedes).
You know, if they try hard enough, I bet they can get this new control system to be just as good as the old one (that cost way less than half of the new one)!
*whimpers* Why, oh why couldn't we have just upgraded to the PIC32 (80MIPS) or even the Querk controller... :(
-q :yikes:
Alan Anderson
02-05-2008, 09:19
...the selection process included detailed performance profiling of various motor controllers when used with the 9403.
Would it be possible to see what this detailed performance profiling showed?
I'm wondering whether the control system rules next year will require us to use only Victors as motor speed controllers, or if there will be a new device with a different control input available to us.
Kevin Sevcik
02-05-2008, 10:59
Not to belabor the point, but in case anyone hasn't thought it out fully yet, 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. Granted, such resolution was primarily useful for tracking with the CMUCam and we'll be getting much better vision equipment and processing at some point, but still.
Also, I just had a brainstorm. I can't get my hands on our robot right now to test this theory, but could you calibrate the Victor to work with a pulse longer than 2 ms or shorter than 1ms? If anyone in this thread is using Kevin Watson's precision PWM code, you should be able to create a 1-3ms pulse width with your GAIN constant set to 79 and your CENTER constant set to 20000. I'm curious if the Victor can successfully calibrate to this range, or possibly .5-2.5ms. Doubling the pulse width difference should get us back to a comparable resolution to what we currently have.
The Lucas
02-05-2008, 15:03
Doubling the pulse width difference should get us back to a comparable resolution to what we currently have.
Along the same lines, if you had a circuit that took an input pulse then output a pulse of half the length you could double the resolution (kinda like a one-shot with the output length is half the trigger length). Just send it 2ms-4ms (same frequency) pulses and get 1ms-2ms out to the Victor. The couple ms of jitter induced by changing signals between 2ms & 4ms shouldn't affect the servos or the Victors since they just require a minimum length gap between pulses (8ms for the Victors). This circuit could be installed in the place of the current buffer IC on a future rev of the digital sidecar. Just a thought.
Kevin Sevcik
02-05-2008, 18:05
Along the same lines, if you had a circuit that took an input pulse then output a pulse of half the length you could double the resolution (kinda like a one-shot with the output length is half the trigger length). Just send it 2ms-4ms (same frequency) pulses and get 1ms-2ms out to the Victor. The couple ms of jitter induced by changing signals between 2ms & 4ms shouldn't affect the servos or the Victors since they just require a minimum length gap between pulses (8ms for the Victors). This circuit could be installed in the place of the current buffer IC on a future rev of the digital sidecar. Just a thought.
... Sorry, I'm having difficulties envisioning any sort of simple pulse width halving circuit. At least one that doesn't involve something like one 555 timer, some logic, and a slew of passives per PWM channel. Or possibly two constant current sources, one cap, a FET or transistor, a Schmitt Trigger, a NOT and an AND... per PWM channel.
Or I suppose you could use a FIFO and clock the unloads twice as fast as the loads and just make sure you're not outputting a high signal for a ridiculously long time...
But on the whole, it seems like a pretty major design undertaking for the digital sidecar. Especially considering it's been prototyped and probably headed for mass production shortly. Making such a modification at this stage of the game would only put it very behind schedule.
Kevin Sevcik
03-05-2008, 00:41
I hate to follow up my own post, but after some further research, I noticed a slight miscalculation on my part. Looking at this IFI FAQ (http://www.ifirobotics.com/forum/viewtopic.php?t=317), the victor speed controllers are obviously going full range at 1-2ms, more or less. The IFI RC is changing the PWM width in 5 us steps, so it's varying the pulse width by 1.275 ms, and we're not using .275 of that range. So the output on the IFI RC has an full range resolution of 200 counts, compared to the cRIO's resolution of 143 counts. So the resolution will probably end up with about 75% the resolution, not the 50% I stated earlier. My curiousity about calibrating the victors to wider pulse widths remains, however.
For reference, when the 883 and 884 were profiled they were found to have a step resolution of 6.44us (with some steps actually 12.85us) with the ability to generate 127 discrete voltages.
But as no announcement has been made with regards to motor controllers and their operational specifications, any further discussion is pure speculation.
One closing note with regards to PWM generation - the cRIO is not limited to 256 steps, thus allowing for far longer PWM periods while still maintaining the 6.625us resolution.
Would it be possible to see what this detailed performance profiling showed?
I'm also interested in a datasheet for the microchip (on the CompactRio) that is generating the PWM pulses?
Kevin Sevcik
03-05-2008, 12:40
I'm also interested in a datasheet for the microchip (on the CompactRio) that is generating the PWM pulses?Andrew,
There isn't going to be a datasheet past the data sheet for the cRIO chassis we're using. 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.
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.
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.
Q. As the FPGA code is finalized, will NI release a list of sensors that will be supported?
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 (http://www.chiefdelphi.com/forums/showthread.php?t=67304).
Thanks,
-Joe
Alan Anderson
04-05-2008, 14:47
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.
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 (http://www.hitecrcd.com/product_file/file/16/Servomanual.pdf) about the resolution other than that the resolution is higher for digital servos (322HD is analog as stated here (http://www.hitecrcd.com/product_file/file/17/HS322HD.pdf)), 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
04-05-2008, 20:24
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
11-06-2008, 16:00
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?
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
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?
__________________
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
great
i am reading this
it will help my team to start
Mike Copioli
14-12-2008, 09:47
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
14-12-2008, 09:50
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
14-12-2008, 11:47
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.
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.
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.
30-12-2008, 03:03
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 frcteams@usfirst.org, 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
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
09-01-2009, 16:24
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
09-01-2009, 16:58
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.
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 frcteams@usfirst.org, 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
11-01-2009, 10:43
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?
vBulletin® v3.6.4, Copyright ©2000-2017, Jelsoft Enterprises Ltd.