View Full Version : 2009 Control System Feature Wishlist
As requested by Greg McKaskle (http://www.chiefdelphi.com/forums/showpost.php?p=743023&postcount=260), let's start a wishlist of features that we'd like to see in the new controller.
I'll start:
-encoder counting in the FPGA for a fixed/flexible number of encoders
Guy Davidson
26-04-2008, 12:53
To add to that:
-Built in gyro support, with oversampling, noice reduction, integration, and all that jazz done on the FPGA level.
-Similarly, the ability to use similar tools (oversampling and other noise reduction techniques) on sensors that don't require intgration (such as pots, absolute magnetic encoders, and analog rangefinders).
-Again, I'm not sure if this is FPGA level stuff, but the ability to write out some PWMs faster than others (just like we were able to do with pwms 13-16 on the IFI control system). This could be useful to run tight and powerful control loops, particularly on the drive train.
Kevin Sevcik
26-04-2008, 13:34
On thing I think is likely is that this control system will be running a faster loop than the IFI one. So I don't think multirate PWMs will be as necessary. My additions to the wishlist (assuming FPGA lockout):
- Provisions for interrupt-on-change like functionality on a subset of the digital inputs.
- something similar to the Capture functionality on a CCP port to easily measure pulse widths.
I just copied over my post from another thread.
Greg,
Thank you for you help and insights with this new control system. Here is my wish list:
1.) could someone please give us the name of the Project Head at both FIRST and NI. I am a member of the Colorado FIRST planning committee, president of Colorado School of Mines Robotics Club and a long time FRC mentor. We have a great relationship with our Regional NI sales office and have all the resources to do a mentor workshop on the new control system, but we need to know more about certain things (like access to the Digital Sidecar) so we are able to do such a workshop. Myself and many other are more than willing to sign a NDA. It is frustrating to say the least of the politics inside of NI and FIRST are cutting good people off at the knees. BTW I called FIRST on Monday (4/21) and they told me NI had nothing to do with the new control system, even after the announcement. go figure
2.) Encoder interfaces galore - I would love to see 8-10 encoder interfaces. It would be really nice if some of the encoder interfaces had upper and lower limit switch support. In our lab we setup 9403 channels as follows:
8 x RC-PWM outputs
8 x quadture encoder inputs (channels 0-7)
4 x upper and lower limit switches (mapped to channels 4-7)
Currently in our 2008 bot we used 6 encoders (4 channels had upper/lower limit switches), but that could of easily been 8 if we chose to use a Mecanum drive.
3.) More powerful sensors like gyros, accelerometer, ultra-sonics, laser range finders moved onto a communications bus (I2C, SPI or CAN). This will reduce pin count and if implemented correctly will allow for self diagnostics.
Now Moving on to the long term wish list:
4.) Make a Radio modem cRIO module. - if implemented correctly inside of VxWorks it could be used to provide the supervisory control that FIRST needs while still granting us access full access to the FPGA
5.) Migrate to using a cRIO module for motor control (NI 9505?)
6.) let us use the NI 1742 - I love this thing!
7.) Larger cRIO Chassis maybe 12/16 Slot
AustinSchuh
27-04-2008, 17:52
I'm not sure exactly how to word this, but I'll give it a try
1) Have the FPGA interface for the encoders that provides the position and the velocity that the sensor is spinning at.
One of the things I'm curious about is what sensors teams are interested in using. Specifically part numbers / data sheets / etc. Don't limit your wishes based on the interface to the sensor... this is a wish-list, right?
I know there are several I2C sensors our team is interested in. Magnetometers are interesting. Some of the gyros and accelerometers have pulse-width or I2C interfaces, instead of analog. Some temperature sensors are 1-wire (Dallas Semi) interfaced. I'm sure you guys have many.
Thanks,
-Joe
The more that I think about various sensors, I would really like to see more rs-232/485 ports on the controller
dtengineering
05-05-2008, 01:48
Well, I'd really like to have a DWIM programming interface (Do What I Mean) as opposed to our current "Do What I Say" system. That would really make life easier, and allow our programming team to make full use of that half-hour period they get to work on the "finished" robot before it goes in the crate! :)
As far as sensors... the Banebots Encoders are nice... so I echo the requst for multiple quadrature encoder support in hardware. We've run up to four encoders at a time... although we used Banebots decoder board to simplify the inputs, it would still be nice to just have a plug'n'play hookup for multiple encoders. The maxbotix (http://www.sparkfun.com/commerce/product_info.php?products_id=8502) sonars are great, and while they work great with their easy-to-use analog interface they have a couple other modes as well that could be supported.
But my biggest request is that the whole system be tested on a very large scale (perhaps an off-season event) in the early autumn so that there is time to work out any bugs that show up when multiple systems run conncurrently in a public environment. We typically compete in Portland (a first weekend regional) and really hope we aren't serving as one of the first large-scale public testbeds for the new system.
Jason
Now that the controller can do I2C similar to the NXT, I would like to see drivers on the cRio for all Lego NXT sensor products.
Mindsensors - http://www.mindsensors.com/
Hitechnic - http://www.hitechnic.com/
In terms of interfaces, here is my priority list,
1. I2C
2. Serial Ports
3. Quadrature Encoders
4. Analog
5. SPI
Eventually having more interfaces for SparkFun's huge product line would be nice as well,
http://www.sparkfun.com/commerce/categories.php?cPath=23_85 an IMU would make life so much easier
Kevin Sevcik
05-05-2008, 09:46
The more that I think about various sensors, I would really like to see more rs-232/485 ports on the controllerYour wish is granted! (http://www.ni.com/pdf/products/us/cat_crio907x.pdf)
Well for one RS-232 port, at any rate. Certainly better than none, and there are RS-232 and RS-485 expansion modules available that we might get to use in the future.
This is probably more a function of the master control routines, rather than a user function, but I'd like to see more comprehensive diagnostics indications on the robot and OI. For example, on the robot: a status display indicating go/no-go status of the robot control hardware, digital sidecar, battery charge level and wireless connectivity. On the driver control OI: display the OI & robot status, field control state (enabled/disabled, autonomous/teleoperation, e-stop), plus wireless status and packet loss, etc. for diagnosing robot communications issues.
AustinSchuh
05-05-2008, 12:17
I would like to be able to interface one of these to the bot.
http://www.acroname.com/robotics/parts/R93-SRF04.html
gryo w/drift compensation and programmable op-amp gain (similar to those used on model helicopters like ICG400).
sensorless motor feedback using back emf measurement sync'd with pwm cycle (i.e. automatically interrupt pwm setting, substituting neutral for a couple of cycles, but sync'd with start of pulse train). programmable op-amp gain would be a bonus. Should be available on any pwm output, but would require A/D channel to get the measurement. Would need sync signal on when to acquire analog sample.
I would like to see the LabView PID toolkit included in the KOP.
Design the entire system so it is easy (and inexpensive) for off season events and individual teams to build their own field controller system, using nothing more than a laptop, a wireless router and an NI USB 6008 or 6009 multifunction IO module or two (ie COTS materials).
Field controller software would be an open source download. Install it and go. Ideally, this would be a Labview App.
This would include built-in monitoring and diagnostics, of course.
With 1500 teams testing it out for 6 weeks we might get a lot of valuable feedback prior to the events themselves ...
thefro526
11-05-2008, 12:32
Maybe it's already in the works but, I'd love to have an easy way to get program info without a computer. So possibly a built in text LCD or something similar.
It would be nice to be able to set certain constants without having to reprogram (for PID tuning and such). Something on the OI would be nice.
Let us customize the information displayed on the OI - Possibly even full control of the LCD.
Of the items not yet mentioned, the most important one to me is to be able to program it entirely from Linux (use of Wine is acceptable).
Of the items not yet mentioned, the most important one to me is to be able to program it entirely from Linux (use of Wine is acceptable).
I'm not sure if the tools will work with Wine, but I'm sure you can use the tools in a VM running Windows on Linux. That's not to say that it won't run on Wine, I just haven't tried it.
-Joe
gryo w/drift compensation and programmable op-amp gain (similar to those used on model helicopters like ICG400).
I'm interested to better understand what features you are interested in here. I found very little detailed documentation about what this does technically. What op amp are you referring to?
sensorless motor feedback using back emf measurement sync'd with pwm cycle (i.e. automatically interrupt pwm setting, substituting neutral for a couple of cycles, but sync'd with start of pulse train). programmable op-amp gain would be a bonus. Should be available on any pwm output, but would require A/D channel to get the measurement. Would need sync signal on when to acquire analog sample.
This sounds like a request that would need to be implemented in the motor controller directly. For a controller like the Victor, there is a relatively long time that the H-Bridge will be driven after the incoming servo PWM signal stops. The Servo PWM is also not necessarily synchronized with the H-Bridge PWM. I'm not sure what op-amp it is that you keep referring to.
I'm interested in following this up. Please give more information.
Thanks,
-Joe
-Again, I'm not sure if this is FPGA level stuff, but the ability to write out some PWMs faster than others (just like we were able to do with pwms 13-16 on the IFI control system). This could be useful to run tight and powerful control loops, particularly on the drive train.
I'm interested in the use case here. Is it truly for control loops driven by motors connected to speed controllers that use the standard servo PWM signal?
Does anyone have a use case for PWM generation that is not servo PWM protocol?
Thanks
-Joe
The more that I think about various sensors, I would really like to see more rs-232/485 ports on the controller
What kinds of things do you have in mind to hook up to those ports?
Thanks
-Joe
1.) could someone please give us the name of the Project Head at both FIRST and NI. I am a member of the Colorado FIRST planning committee, president of Colorado School of Mines Robotics Club and a long time FRC mentor. We have a great relationship with our Regional NI sales office and have all the resources to do a mentor workshop on the new control system, but we need to know more about certain things (like access to the Digital Sidecar) so we are able to do such a workshop. Myself and many other are more than willing to sign a NDA. It is frustrating to say the least of the politics inside of NI and FIRST are cutting good people off at the knees. BTW I called FIRST on Monday (4/21) and they told me NI had nothing to do with the new control system, even after the announcement. go figure
Wow... I'm surprised to hear the response from FIRST... guess they were just in the habit. I'm afraid the only project head is at FIRST, since FIRST owns the new control system. NI is a supplier to FIRST and is working closely with FIRST to provide them with everything they need.
Please don't lump FIRST politics onto NI. ;) Sorry about your knees.
2.) Encoder interfaces galore - I would love to see 8-10 encoder interfaces. It would be really nice if some of the encoder interfaces had upper and lower limit switch support. In our lab we setup 9403 channels as follows:
8 x RC-PWM outputs
8 x quadture encoder inputs (channels 0-7)
4 x upper and lower limit switches (mapped to channels 4-7)
Currently in our 2008 bot we used 6 encoders (4 channels had upper/lower limit switches), but that could of easily been 8 if we chose to use a Mecanum drive.
Sounds like a nice setup. Are you controlling a robot with it? I'm curious if there is actually any hardware interaction between the limit switches and the encoder inputs. If so, please describe it.
3.) More powerful sensors like gyros, accelerometer, ultra-sonics, laser range finders moved onto a communications bus (I2C, SPI or CAN). This will reduce pin count and if implemented correctly will allow for self diagnostics.
Are there any specific sensors that you are most interested in?
4.) Make a Radio modem cRIO module. - if implemented correctly inside of VxWorks it could be used to provide the supervisory control that FIRST needs while still granting us access full access to the FPGA
Perhaps you mean something like this (http://www.sea-gmbh.com/en/crio/cr1_index_e.php?page=xlan_einleitung)?
5.) Migrate to using a cRIO module for motor control (NI 9505?)
The NI-9505 is not capable of high enough current to run drive train motors and consumes a slot in the chassis for each motor. Probably not the best use of slot real estate.
6.) let us use the NI 1742 - I love this thing!
You and me both. It's very cool.
7.) Larger cRIO Chassis maybe 12/16 Slot
Ah ha!... you were thinking of item number 5 above, eh?
Thanks for the comments,
-Joe
Now that the controller can do I2C similar to the NXT, I would like to see drivers on the cRio for all Lego NXT sensor products.
Mindsensors - http://www.mindsensors.com/
Hitechnic - http://www.hitechnic.com/
In terms of interfaces, here is my priority list,
1. I2C
2. Serial Ports
3. Quadrature Encoders
4. Analog
5. SPI
Eventually having more interfaces for SparkFun's huge product line would be nice as well,
http://www.sparkfun.com/commerce/categories.php?cPath=23_85 an IMU would make life so much easier
The NXT has 4 I2C sensor ports on it that are used as a point-to-point bus, and as such, every sensor has the same address. You are only be able to put one NXT sensor on a given I2C bus.
SparkFun.com is awesome. :D
-Joe
I'm interested to better understand what features you are interested in here. I found very little detailed documentation about what this does technically. What op amp are you referring to?
This sounds like a request that would need to be implemented in the motor controller directly. For a controller like the Victor, there is a relatively long time that the H-Bridge will be driven after the incoming servo PWM signal stops. The Servo PWM is also not necessarily synchronized with the H-Bridge PWM. I'm not sure what op-amp it is that you keep referring to.
I'm interested in following this up. Please give more information.
Thanks,
-Joe
For the gyro, due to DA not working entirely in the analog domain, the digitization quanta can hide/diminish/interfere with measuring small amounts of rotation. To compenstate, many gyros have adjustable analog amplification that amplifies the analog voltage via an operational amplifier. Think of it a voltmeter autorange feature, but under program control. You need to do this at the analog level before A/D conversion. The drift compensation is different - it compensates for drift of the gyro h/w output.
The tail rotor gyro referenced splices directly into the tail pwm signal and by adjusting the gain and setting the mode to heading lock, you can get the helicoptor to fly straight without having to constantly compenstate.
For the back-emf, this isn't typically implemented in the H-bridge. Usually its implemented at the source where the PWM signal is generated. When you idle the speed controller and don't output any drive voltage, the motors free spin and act as a generator. A measurement of the back-emf voltage is in direct correlation to the motor speed. Doing an analog pre-charge capture at this point in time allows you to measure the back-emf and thus speed of the motor. Often the motor voltage is higher than the A/D capture range and so a resistor divider is used. Due to digitization quanta, analog amplification is used to auto-range so you have better measurement of low speeds (voltages). You can do some of this programmatically, but you have to set the PWM to idle, wait some small but finite amount of time for the signal to propogate out, sample the back-emf voltage, and then restore the PWM value. The measured back-emf is often used in PID feedback loops for motor control. Its especially useful for smaller motors where quad encoders would be overkill. Also, its real easy to detect motor stall as the back-emf voltage drops to zero during stalls. This also means its relatively easy to quesstimate the amount of current being drawn by using both the value of pwm and the measured back-emf.
For the gyro, due to DA not working entirely in the analog domain, the digitization quanta can hide/diminish/interfere with measuring small amounts of rotation. To compenstate, many gyros have adjustable analog amplification that amplifies the analog voltage via an operational amplifier. Think of it a voltmeter autorange feature, but under program control. You need to do this at the analog level before A/D conversion.
There is currently no gain available on the analog frontend, but there shouldn't be anything that stops you from putting an op amp in line, perhaps controlled by some bus like I2C or SPI.
While there isn't analog gain, you can oversample the signal which has the same effect of increasing resolution of the measurement. The benefit of oversampling compared with analog gain, is that you don't have to sacrifice range for resolution. What it does require is an A/D and frontend that samples faster.
The drift compensation is different - it compensates for drift of the gyro h/w output.
How does this drift compensation work?
The tail rotor gyro referenced splices directly into the tail pwm signal and by adjusting the gain and setting the mode to heading lock, you can get the helicoptor to fly straight without having to constantly compenstate.
I'm guessing people would want more control over this for their robots than putting it inline with the PWM signal, but thanks for explaining how it's done for helicopters.
For the back-emf, this isn't typically implemented in the H-bridge. Usually its implemented at the source where the PWM signal is generated. When you idle the speed controller and don't output any drive voltage, the motors free spin and act as a generator. A measurement of the back-emf voltage is in direct correlation to the motor speed. Doing an analog pre-charge capture at this point in time allows you to measure the back-emf and thus speed of the motor. Often the motor voltage is higher than the A/D capture range and so a resistor divider is used. Due to digitization quanta, analog amplification is used to auto-range so you have better measurement of low speeds (voltages). You can do some of this programmatically, but you have to set the PWM to idle, wait some small but finite amount of time for the signal to propogate out, sample the back-emf voltage, and then restore the PWM value. The measured back-emf is often used in PID feedback loops for motor control. Its especially useful for smaller motors where quad encoders would be overkill. Also, its real easy to detect motor stall as the back-emf voltage drops to zero during stalls. This also means its relatively easy to quesstimate the amount of current being drawn by using both the value of pwm and the measured back-emf.
I see what you're getting at here. There are a few requirements that I'm not sure will be clean, but I'd bet it can be done to some extent.
First requirement is obviously that the speed controller be set to coast (which most drivetrains are) so you don't short the back emf.
I'm not sure about a clean mechanism for synchronizing the PWM and the analog measurement. Also, the back emf will be an AC signal (top 1/3 of a sine wave as the brushes commutate, so you'd need to measure some portion of that singal to find the maximum (or minimum depending on direction), not just take a single sample.
The other issue I see is with the isolation of the analog measurement. The NI-9201 analog input module is isolated, but only on a per module basis. The frontend is also single-ended only (no differential) so you would have to connect the reference of the module to one of the speed controller output terminals. This would preclude you from using that module for much of anything else.
It's a good idea, but I suspect it is too complicated given the current module selection. That being said, there's nothing stopping you from trying and it certainly could get easier in the future if the modules change (i.e. NI-9205 (http://sine.ni.com/nips/cds/view/p/lang/en/nid/202571) which has programmable gain and differential measurements).
Thanks for the info,
-Joe
Kevin Sevcik
15-05-2008, 19:43
I'm interested in the use case here. Is it truly for control loops driven by motors connected to speed controllers that use the standard servo PWM signal?
Does anyone have a use case for PWM generation that is not servo PWM protocol?
Thanks
-Joe
I imagine the answer there is most likely:
"We don't know yet, but we'd sure like it." I don't think anyone's bothered with it on the current RC, but I can see a few uses. Given the lack of analog outputs, anyone wanting to output an analog signal is going to need to use an SPI or I2C chip, or will need a very flexible PWM output that they can filter to get an analog signal. So I can see a few uses, though they're likely rare.
Sounds like a nice setup. Are you controlling a robot with it? I'm curious if there is actually any hardware interaction between the limit switches and the encoder inputs. If so, please describe it.
We just have a standard controller config. This controller everything from robotic arms to misc project robots. This can be anywhere from a mowing robot to a robot that just does our vending machines runs for us.
The limit switches just shut off the motor in a direction so we don't hurt our bots. More or less like a safety switch.
Are there any specific sensors that you are most interested in?
Gyros, accelerometers, compass, ultrasonics, ir sensors, laser range finder,
Perhaps you mean something like this (http://www.sea-gmbh.com/en/crio/cr1_index_e.php?page=xlan_einleitung)?
Exactly !!!!
The NI-9505 is not capable of high enough current to run drive train motors and consumes a slot in the chassis for each motor. Probably not the best use of slot real estate.
Ah ha!... you were thinking of item number 5 above, eh?
I understandard that. I just think trying to integrate as much as possible on the cRIO would be the best bet for the long term. With regards to power, what about having a custom 9505 that has external power in?
You and me both. It's very cool.
Does this mean that we may see the NI-1745 in the KOP?
Thanks for everything that you are doing!
I understandard that. I just think trying to integrate as much as possible on the cRIO would be the best bet for the long term. With regards to power, what about having a custom 9505 that has external power in?
Does this mean that we may see the NI-1745 in the KOP?
The 9505 already uses an external power input to drive the motor. The issue is the power dissipation allowed in the c-series module spec. We are looking into options, but it won't happen by 2009.
The NI-1742 won't be in the kit in 2009. :( Maybe someday.
Cheers!
-Joe
Daniel_LaFleur
19-05-2008, 17:44
I guess my wishlist would start with being able to framegrab and run image recognicion (sp?) using multiple, inexpensive USB webcams (ethernet cameras are so expensive).
acdcfan259
19-05-2008, 17:52
For the controller to control the robot...flawlessly.
I guess my wishlist would start with being able to framegrab and run image recognicion (sp?) using multiple, inexpensive USB webcams (ethernet cameras are so expensive).
Since the controller does not have USB ports, that will be problematic. You would need to have an external interface board that supports both ethernet and USB, then write software for it to shuffle the data between the busses. It would probably end up being more expensive, take up more space, be more complex and have lower performance than simply using an ethernet camera.
How expensive is "so expensive"? How does that cost compare with USB cameras? How about compared to the cost of the CMUcam? Are you considering any specs of the cameras besides the interface?
-Joe
Daniel_LaFleur
19-05-2008, 18:23
Since the controller does not have USB ports, that will be problematic. You would need to have an external interface board that supports both ethernet and USB, then write software for it to shuffle the data between the busses. It would probably end up being more expensive, take up more space, be more complex and have lower performance than simply using an ethernet camera.
How expensive is "so expensive"? How does that cost compare with USB cameras? How about compared to the cost of the CMUcam? Are you considering any specs of the cameras besides the interface?
-Joe
I can get a 30fps @ 640x480 for $19.99 here (http://www.thinkgeek.com/computing/avcards/9d1c/) (yeah, I know ... it looks like mr burns :P ). As long as the resolution/focal length is acceptable then all that would be needed is a USB interface into the cRio (**wishes**)
The CMUcam is $239.00 here (http://www.seattlerobotics.com/cmucam3.htm) and still needs an interface as it's serial (I haven't seen any serial interface on the cRio).
And the thing I was really interested in, though, was the ability to Frame Grab and IR with multiple cameras.
I can get a 30fps @ 640x480 for $19.99 here (http://www.thinkgeek.com/computing/avcards/9d1c/) (yeah, I know ... it looks like mr burns :P ). As long as the resolution/focal length is acceptable then all that would be needed is a USB interface into the cRio (**wishes**)
The CMUcam is $239.00 here (http://www.seattlerobotics.com/cmucam3.htm) and still needs an interface as it's serial (I haven't seen any serial interface on the cRio).
And the thing I was really interested in, though, was the ability to Frame Grab and IR with multiple cameras.
The primary reason that the cRIO doesn't have USB is that, for industrial automation and control (the primary market), USB is rarely used. If a USB interface is needed, then a solution like I described above must be employed.
Ethernet cameras can be found for around a hundred dollars for low quality to a few hundred for decent quality imaging.
The cRIO has an RS232 serial port on it.
Cheers!
-Joe
whytheheckme
19-05-2008, 19:24
Ethernet cameras can be found for around a hundred dollars for low quality to a few hundred for decent quality imaging.
I bought some Ethernet cameras off of Woot! for $20 last year (640x480 if I'm not mistaken.)
-Jacob
Because our school's wireless is PEAP-based, I would love if it could connect to that considering that the place most of the programming is done is far out of range of the workshop.
Also, it would save alot of trouble if the OI could easily be powered by battery for testing.
~DtD
Daniel_LaFleur
23-05-2008, 14:08
The primary reason that the cRIO doesn't have USB is that, for industrial automation and control (the primary market), USB is rarely used. If a USB interface is needed, then a solution like I described above must be employed.
<<SNIP>>
-Joe
This actually surprises me, considering the number of USB DAQ devices ( like this (http://sine.ni.com/nifn/cds/view/main/p/sn/n24:USB/pg/2/lang/en/nid/1036/ap/daq), and this) (http://www.measurementcomputing.com/cbicatalog/directory.asp?dept_id=403) entering the market. Attaching a simple driver circuit (either voltage or current) to one of the USB DAQ DOs allows for control of most pneumatic systems and some DC motors (single directional / single speed) while the limited AOs can control many of the more sophisticated motor systems.
Not to mention the sheer number of other USB devices that the cRio could control (Enviromental control and monitoring, control feedback through DAQs, Logic instrumentation, ocilliscope signals, etc) and all through a common port (latency, timing, and bandwidth would be an issue on the higher end devices).
This would seem to me to be an easy way to expand the cRio's capabilities while keeping the cost to the end user down.
JMHO
This actually surprises me, considering the number of USB DAQ devices ( like this (http://sine.ni.com/nifn/cds/view/main/p/sn/n24:USB/pg/2/lang/en/nid/1036/ap/daq), and this) (http://www.measurementcomputing.com/cbicatalog/directory.asp?dept_id=403) entering the market. Attaching a simple driver circuit (either voltage or current) to one of the USB DAQ DOs allows for control of most pneumatic systems and some DC motors (single directional / single speed) while the limited AOs can control many of the more sophisticated motor systems.
Not to mention the sheer number of other USB devices that the cRio could control (Enviromental control and monitoring, control feedback through DAQs, Logic instrumentation, ocilliscope signals, etc) and all through a common port (latency, timing, and bandwidth would be an issue on the higher end devices).
This would seem to me to be an easy way to expand the cRio's capabilities while keeping the cost to the end user down.
JMHO
It is true that there are many USB data acquisition systems out there, but there is a reason they are not used for control. The bus latency and non-determinism are detrimental to control systems above around 250Hz. The USB only tries to send data to or from the device every 1ms (125us for high speed) or less, depending on bus utilization. Fundamentally, that is why they are called data acquisitions systems and the cRIO is called a programmable automation controller.
You'll notice that even for the cSeries IO modules, we have different chassis to use them in, such as the NI cDAQ-9172 chassis (http://sine.ni.com/nips/cds/view/p/lang/en/nid/202545). This chassis is USB and can interact with the same modules that come in the kit. This is for reading lots of data very fast or writing lots of data very fast. It is not made for the read-compute-write single point data path that is needed for control systems.
I hope this clarifies the reason why USB is not used for control. If you have more questions, I'd be glad to attempt to answer them.
Cheers!
-Joe
Daniel_LaFleur
25-05-2008, 16:33
It is true that there are many USB data acquisition systems out there, but there is a reason they are not used for control. The bus latency and non-determinism are detrimental to control systems above around 250Hz. The USB only tries to send data to or from the device every 1ms (125us for high speed) or less, depending on bus utilization. Fundamentally, that is why they are called data acquisitions systems and the cRIO is called a programmable automation controller.
You'll notice that even for the cSeries IO modules, we have different chassis to use them in, such as the NI cDAQ-9172 chassis (http://sine.ni.com/nips/cds/view/p/lang/en/nid/202545). This chassis is USB and can interact with the same modules that come in the kit. This is for reading lots of data very fast or writing lots of data very fast. It is not made for the read-compute-write single point data path that is needed for control systems.
I hope this clarifies the reason why USB is not used for control. If you have more questions, I'd be glad to attempt to answer them.
Cheers!
-Joe
First off, Joe, I want to thank you for this discussion thread. The information here will be invaluble to students that do not understand bus architecture / limitations (something I know a bit about ;) :P)
Now on the the method behind my madness :P :
Our old controller gave us a 40ms slow loop (where we could write PWM outputs). Given that, the capabilities of USB 2.0 (even with latency) would be a dream. I wasn't suggesting USB for output control (even though, in some cases it's possible) but instead for data input from cameras and other sensors.
Now my guess is that the cRio (I havent seen a datasheet on the base unit yet) uses either CAN, PXI or a PCI express bus (My guess is CAN bus). The FIRST demonstration (not really complete :( ) showed a single ethernet camera at 640x320, 15fps, full color. This (to me) didn't seem to tax either the ethernet port nor the bus/processor but is stated as the capabilities of the cRio. This is why I was looking for USB connectivity and webcams.
So I guess my question is ... is the (FIRST configuration) cRio capable (framgrab and IR) of more than than 1 camera at this framerate? higher framerates at lower resolution? higher framerates at lower color? Multiple cameras (at all)?
First off, Joe, I want to thank you for this discussion thread. The information here will be invaluble to students that do not understand bus architecture / limitations (something I know a bit about ;) :P)
I hope that in the course of transitioning from the old platform to this new one, we can share the design decisions that led up to the ultimate design for the system that the students and mentors will work with. I think an understanding of how we made the choices we made will help them to make better use of the system.
Our old controller gave us a 40ms slow loop (where we could write PWM outputs). Given that, the capabilities of USB 2.0 (even with latency) would be a dream. I wasn't suggesting USB for output control (even though, in some cases it's possible) but instead for data input from cameras and other sensors.
I realize that you weren't asking for that particular I/O expansion. I was responding to the assertion that you made concerning the use of USB DAQ products in general with the cRIO. It is true that some slow control applications can use USB, but the typical application of that doesn't use cRIO as the primary controller. Instead, a single board computer or even a PDA will be used. As such, the typical high-speed, high-reliability applications that demand cRIO, can not abide a USB interface to the real world. That is the reason that the commercial cRIO has no USB port. We did put USB on an old model (cRIO-9012 (http://sine.ni.com/nips/cds/view/p/lang/en/nid/203347)) which supported mass storage devices like memory sticks at full speed (USB 1.1). There was no real demand to either make it USB 2.0 or to support other types of devices, so it was left out of later designs.
Because the cRIO for FIRST teams will fundamentally be a stock commercial cRIO, the addition of USB to the controller is not possible. :(
Now my guess is that the cRio (I havent seen a datasheet on the base unit yet) uses either CAN, PXI or a PCI express bus (My guess is CAN bus). The FIRST demonstration (not really complete :( ) showed a single ethernet camera at 640x320, 15fps, full color. This (to me) didn't seem to tax either the ethernet port nor the bus/processor but is stated as the capabilities of the cRio. This is why I was looking for USB connectivity and webcams.
So I guess my question is ... is the (FIRST configuration) cRio capable (framgrab and IR) of more than than 1 camera at this framerate? higher framerates at lower resolution? higher framerates at lower color? Multiple cameras (at all)?
The cRIO does support CAN by using an NI 9853 (http://sine.ni.com/nips/cds/view/p/lang/en/nid/201972), but it is not supported natively on the controller. The primary interface to the cRIO is Ethernet.
In the demo, the cRIO was not heavily taxed to simply stream the image back to the PC, and the Ethernet port certainly wasn't saturated. I imagine multiple ethernet cameras would be straight forward to get going if a switch were used to attach both of them. The real problem comes when you try to do video processing on the images. At that point, I think the processor in the cRIO will be very heavily taxed and the frame rate of processing will likely be significantly less than the rate that the images come from the camera. Naturally this depends a lot on what you are trying to do and how efficiently you implement it.
Cheers!
-Joe
Greg McKaskle
28-05-2008, 08:39
If the goal of multiple cameras is to have a view in multiple directions, a single camera can do this with a mirror and some math. Point the camera straight up. Mount a curved mirror -- a hyperbolic is best, but simple mirrored Christmas balls can work. The image from the camera contains information from all around the camera, but it is distorted due to the shape of the ball. A math transform lets you put the pixels onto a cylinder, letting a single camera see everything around it.
Not the same as stereo-optic vision, but much simpler, and perhaps useful on a crowded field of robots.
Greg McKaskle
Daniel_LaFleur
28-05-2008, 13:07
If the goal of multiple cameras is to have a view in multiple directions, a single camera can do this with a mirror and some math. Point the camera straight up. Mount a curved mirror -- a hyperbolic is best, but simple mirrored Christmas balls can work. The image from the camera contains information from all around the camera, but it is distorted due to the shape of the ball. A math transform lets you put the pixels onto a cylinder, letting a single camera see everything around it.
Not the same as stereo-optic vision, but much simpler, and perhaps useful on a crowded field of robots.
Greg McKaskle
My reasoning for asking this is that i believe that FIRST will 'up the ante' when it comes to game complexity because of the advanced features available in the cRIO.
Up until now the vision system used in FIRST has only had to track a single, non-moving, known sized (usually illuminated) target. Thus, it's my belief that FIRST will challange the teams with either (or a combination of) multiple targets, moving targets or targets where their form, color or shape may change.
With 2 cameras and a known distance between them I can calculate distance to a target ... and with 2 frames from each I can calculate the vector (curve with 3 frames, if needed) in 3D and thus estimate a target location at a future time.
Your suggestion of a parabolic mirror (sounds like a fish-eye lens effect) looks like it could answer the multiple targets possibilities but may make image recognition a bit difficult (depending on mirror quality, orientation of the target, distance, etc).
From the answers above, it sounds like the cRIO is quite capable of reading from multiple cameras, but that the processing power may limit the framerate. This leads me to another question. Will the LabView program supplied to FIRST teams be able to compile to processors other that the cRIO PowerPC (Like an ARM processor running linux in a Gumstix)?
P.S. In case it sounds like I'm whining for more ... I want you all to know I love the cRIO. It's a wonderful system, and I can't wait to get my software teams hands on it.
Greg McKaskle
28-05-2008, 21:51
Your suggestion of a parabolic mirror (sounds like a fish-eye lens effect) looks like it could answer the multiple targets possibilities but may make image recognition a bit difficult (depending on mirror quality, orientation of the target, distance, etc).
... Will the LabView program supplied to FIRST teams be able to compile to processors other that the cRIO PowerPC (Like an ARM processor running linux in a Gumstix)?
P.S. In case it sounds like I'm whining for more ... I want you all to know I love the cRIO. It's a wonderful system, and I can't wait to get my software teams hands on it.
If you've seen the virtual walkthrough's realtors often put on websites, then you've seen the results that a good camera with a good exposure can produce. They are often produced with this sort of setup on a tripod. Then processed into an interactive cylinder.
LV realtime currently supports two processor architectures, x86 and PPC. LV supports other desktop varieties, though not officially anymore. And then there are the embedded tools which actually compile to C, which is then sent through other tools to target processors such as the ARM. So technically LV can target the ARM, but the dev cycle isn't quite the same as RT.
Whining on a wish list, ... I think that is what it is hear for.
Greg McKaskle
Mike Mahar
04-06-2008, 10:59
My biggest wish is to get the controller and the default code as soon a possible. I know that I'd be willing to accept the fact that there will be bugs in both the FPGA and the libraries. Heck, there will be bugs in those systems regardless of when we get them so it would be better for all if the FIRST community could find them early and have a better chance of getting them fixed in time for the competition.
lingomaniac88
05-06-2008, 21:02
I don't think there will be much of a problem with the webcam, even if the camera doesn't send info to the cRIO as quickly as it can. Even if the output stream only updates at 8 fps, it should serve its purpose rather well (unless you're doing something really complex with it that requires a faster refresh rate). I don't think it will be a serious issue unless you're doing something really complex.
I am probably not the best person to ask about this, but it's just my thoughts on the matter.
lingomaniac88
08-06-2008, 21:45
I know this was mentioned before (on page 2 I believe), but I would also like to have control over what the LCD screen on the Driver Station says.
I know this was mentioned before (on page 2 I believe), but I would also like to have control over what the LCD screen on the Driver Station says.
That is also something I would like to see happen. Hopefully we get lucky.
-Joe
vBulletin® v3.6.4, Copyright ©2000-2017, Jelsoft Enterprises Ltd.