2009 Control System Feature Wishlist

[tdlrali]

As requested by Greg McKaskle, 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]

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]

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.

[qnetjoe]

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]

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.

[jhersh]

Originally Posted by qnetjoe

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.

Originally Posted by qnetjoe

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.

Originally Posted by qnetjoe

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?

Originally Posted by qnetjoe

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?

Originally Posted by qnetjoe

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.

Originally Posted by qnetjoe

6.) let us use the NI 1742 - I love this thing!

You and me both. It's very cool.

Originally Posted by qnetjoe

7.) Larger cRIO Chassis maybe 12/16 Slot

Ah ha!... you were thinking of item number 5 above, eh?

Thanks for the comments,
-Joe

[qnetjoe]

Originally Posted by jhersh

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.

Originally Posted by jhersh

Are there any specific sensors that you are most interested in?

Gyros, accelerometers, compass, ultrasonics, ir sensors, laser range finder,

Originally Posted by jhersh

Perhaps you mean something like this?

Exactly !!!!

Originally Posted by jhersh

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?

Originally Posted by jhersh

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!

[jhersh]

Originally Posted by qnetjoe

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]

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]

For the controller to control the robot...flawlessly.

[jhersh]

Originally Posted by Daniel_LaFleur

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]

Originally Posted by jhersh

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 (yeah, I know ... it looks like mr burns ). 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 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.

[jhersh]

Originally Posted by Daniel_LaFleur

I can get a 30fps @ 640x480 for $19.99 here (yeah, I know ... it looks like mr burns ). 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 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

[jhersh]

Originally Posted by Guy Davidson

-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

[Kevin Sevcik]

Originally Posted by jhersh

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.