2009 Control System Feature Wishlist

[thefro526]

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.

[usbcd36]

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.

[tdlrali]

Let us customize the information displayed on the OI - Possibly even full control of the LCD.

[ay2b]

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).

[jhersh]

Originally Posted by ay2b

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

[jhersh]

Originally Posted by dcbrown

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?

Originally Posted by dcbrown

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

[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

[jhersh]

Originally Posted by qnetjoe

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

[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

[jhersh]

Originally Posted by lynca

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/cat...hp?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.

-Joe

[dcbrown]

Originally Posted by jhersh

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.

[jhersh]

Originally Posted by dcbrown

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.

Originally Posted by dcbrown

The drift compensation is different - it compensates for drift of the gyro h/w output.

How does this drift compensation work?

Originally Posted by dcbrown

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.

Originally Posted by dcbrown

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 which has programmable gain and differential measurements).

Thanks for the info,
-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.

[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