Re: What Dr Joe Wants for Christmas...
 

Joe,

Al is right (as usual). You'd have to use an oscilloscope to tune the circuit or the motor controller would have to sample the back EMF many times to find the peak voltage. Even if the controller could read the back EMF, how would you account for line impedance differences between two motors that you want to run at the same velocity? Furthermore, the controller has no knowledge of absolute velocity (other than zero), without being calibrated.

-Kevin

Re: What Dr Joe Wants for Christmas...
 

How about closing the loop with the EDU-RC? You could command a position or velocity using the serial port, which would free up the FRC-RC for handling other tasks like navigation. Mars Science Laboratory (our 2009/11 rover) and two of our experimental rovers use this distributed approach.

Yes, this would be nice, but it would be very hard to send commands and data using the current PWM setup. We'd need a real serial data bus to do this correctly.

-Kevin

Re: What Dr Joe Wants for Christmas...
 

I concur about the need for a "real serial data bus" Jim Zondag and I were talking about all the very cool & very cheap I2C sensor chips that are out there. It is borderline criminal that we don't have an easy way to pump data to and from such devices.

As to your and Al's objections about tuning parameter, I respectfully disagree with you and Al.

Are you guys saying that you don't tune your PID loop gains in your C code? Of course you do. Any I'll bet 99% of the folks doing PID gain tuning are NOT using an O-scope to do it. They are doing it the "old fashioned" way: Trial and Error!!!

All I am saying is that we could put the PID sensor and the gains on the Victor-like device, rather than in the C code on the RC. Again, I am not saying the current Victor is what I want. The process of getting the gains onto the Victor-like device is going to involve some other method than the "standard RC" interface we use now.

To my way of thinking it is just plain silly to use the RC pulse method on a FIRST robot VICTOR. If we went to a serial interface on the Victors we could have perhaps addressable Victors and a simple set of wires hopping from Victor to Victor rather than the mess we have now where all the PWM wires from each Victor has to be plumbed directly to the RC.

But I digress... ...I am convinced that we could get much better motor behavior (even if it isn't perfect) for not that much effort.

Joe J.

Re: What Dr Joe Wants for Christmas...
 

Yep, I agree 100%


I was referring to finding the peak of the back EMF spike, not to tuning PID parameters.


I agree and If you're very serious about this, let's start bugging the IFI & FIRST folks to get this done. I'll even design it and write the code gratis. Give me a call if you want to discuss this.


Controller Area Network (CAN) bus would be perfect.

-Kevin

Re: What Dr Joe Wants for Christmas...
 

I was hoping someone would get around to this!
CAN bus is an established architecture with considerable history and implementation possibilities. In the medical imaging field (my area of history and expertise) CAN bus was used extensively in gantries, tables, suspensions and almost anything else that needed to access multiple devices for communicating control parameters and/or status. I've even seen vendors use it in place of a common serial bus on image processing systems. The automotive industry uses it as well. Switching to it at FIRST would be logical, but it would take a couple of years to see the benefits gained from it as it would be a completely different way to control a robot.

Change is good. The rate of change will be the determining factor. If this change could be done in phases, over a couple years, I think it would be a great success!

Re: What Dr Joe Wants for Christmas...
 

CAN would be fine, so would a half dozen other protocols.

From a cheap & cool sensor perspective, CAN is a bit more than we really need or want. In fact, it is a probably a hinderance in this area. But hey, I'll take what we can get. Illiminating the current system (which more often than not results in a crazy rats nest of PWM cables) while also giving us more ability to customize the behavior of the Victors (for distributed PID control for example) would be a very good thing indeed.

Once we get that, we can press for some sort of quick/cheap serial in/out bus to interface to these cool sensors I keep yammering on about...

Joe J.

Re: What Dr Joe Wants for Christmas...
 

There are some great possibilities for this technology if...
When I first looked at your suggestion (or any for that matter) I tend to filter in the rules from previous years. That being said, anything between the motor and any other part of the robot electrical must go through battery connections and RC PWMs. As such, this type of technology is impossible to implement with our current hardware and rules. However, it is very cool. For those of you who haven't taken the time to look at the video, they are using an FLL motor and the demo is as impressive as anything I have seen lately.
What I am saying Joe, is that the other variables in auto are not going to be fixed by this magic bullet. Without a lot of processing power, the system would not be able to tell when a wheel is slipping, if the robot is driving straight, or if the robot gets bumped. I don't think it could easily compensate for changes in frictional losses in the transmissions as they change temperature or wear, electrical losses as the motors change temperature and the brushes wear or for other things like tread wear, bearing misalignment, frame damage, etc. What I would like to see from the demo is a change in direction on the FLL motor and how well the system handles that. Without going into any deep research, the electronic boards at the top of the frame in the demo look a lot like a single board computer and driver board so that runs the cost up too.
That being said, I like it's performance so far. I would give the technology a solid 8+ on the Al "WOW me Out!" scale. And please note that the motor does not need to be spinning for valid data to be interpreted and correct command data to be sent.
We still need a simple to build, easy to use, cheap positional system for finding yourself on the field. It doesn't need to be terribly accurate but it does need to be absolute. i.e. more than 50% of teams can install the hardware and know that they are starting the match at coordinates x,y and that when they need to get to x',y' they can do it within +- a couple of inches.

Re: What Dr Joe Wants for Christmas...
 

I don't want to put words in anyone's mouth, but I'm guessing Dr. Joe was wasn't thinking about this for autonomous mode so much as just general motor control. Even with an absolute "GPS-like" positioning system, you still need to worry about how fast your motors are going while en route to your target location, and when you get close you still need some feedback to get them to stop exactly where you want (and the fictional GPS-like system may not be accurate enough for this).

Something like this would have all kinds of practical uses beyond autonomous, such as holding an arm joint at a certain position, or creating an "automatic" transmission that uses low gear when the driver is going slow and automatically shifts to high gear (while maintaining the current velocity) when the speed gets faster (I know there's teams that have done this already, but this could make it a lot easier for other teams).
Agreed, but such a system likely wouldn't be accurate enough for really precise driving. The best situation I think would be an absolute positioning system that gave you position updates accurate to +/- a few inches anywhere from every couple hundred milliseconds to 1 second or so, and then wheel encoders, gyros, and/or accelerometers that could be used to dead reckon in between position fixes. I believe this type of setup is very common for devices that use GPS for when there's loss of signal or poor satellite geometry.

Regarding a CAN or I2C or other serial protocol network: I've heard this idea floated before and it would be excellent. Not only for motor control, but for sensors as well. In fact, I'm thinking of trying this out next year on our robot, possibly by using standard RS-232 in multidrop mode. The idea would be to couple a very tiny, very inexpensive microcontroller with a quadrature encoder and let this thing do the heavy lifting of decoding the quadrature signal into a count (and may as well compute velocity while we're at it). Then it's a simple task for the RC (or custom circuit) to query any one of these rotation sensors on the robot without the interrupt overhead and code space of doing it itself.

Re: What Dr Joe Wants for Christmas...
 

Now we are talking....

I think that there are a number of things that could/should be addressed by the control system. Including closed loop control (for autonomous and for just plain well behaved robots) and remote sensor/actuators.

Through my flowery language and lack of clarity, there was some confusion and misdirection but I think we have settled in on a number of improvements that are possible & desirable.

Specifically,
1) a serial interface to the Victor-like devices (and perhaps other devices),
2) perhaps enabling some remote computing on the Victor-like things (remote PID or other distributed control)
3) a method to access cheap/powerful sensors via established (and cheap) serial protocols (in my mind probably not the same as #1 -- but again, let me remind folks I am an ME not a EE)
4) some combination of software, hardware, manuals & handholding that makes integration of these features into a robot possible & desirable by 50% or more of the teams that participate in FIRST (Note the end goal should be capable robots not technology for technology's sake).

I think that if we come to reasonable recommendations, IFI, FIRST, AndyMark, etc. are likely to try to implement them.

Thoughts?

Joe J.

Re: What Dr Joe Wants for Christmas...
 

Mark and I are currently planning on what to do for next season, and this idea has come up. Mark is both an EE and ME. A few years ago, I recall hearing him and Jeff Burch (former TechnoKat engineer) discuss a feedback system dependent on motor EMF.

By the time of IRI (late July) we will know what products we are offering for the upcoming FIRST season.

Thank you for this discussion.

Andy B.

Re: What Dr Joe Wants for Christmas...
 

Al,

The video shows position and velocity control, but two questions that need answering are: 1) What velocity is the motor being commanded to? Is it one radian/second (absolute) or, to use the spinal tap scale, something between 0 and 11 (relative). 2) What position is the motor servoing on? Is it an absolute position, like Pi/2 radians, or is it just whatever position the motor was in when they started servoing? Not being able to do absolute position and velocity control is pretty useless in my mind.

-Kevin

Re: What Dr Joe Wants for Christmas...
 

Kevin,
You are right on. I see the video as demonstrating constant velocity and positioning. It is pretty slow for this motor, I am guessing at about 20% of free speed but it is still very impressive. I was under the impression that the second demo returned the motor to where it should have been had the shaft not been held in place. It just seemed that watching the rotation and estimating where it should be is where it ended up. There didn't seem to be any overshoot that I could detect. We do need to remember that this motor does have a integral gearbox as well.

Re: What Dr Joe Wants for Christmas...
 

The only other cheap, robust solution that I can think of is RS-485. I2C and SPI aren't viable because they are designed to stay on the PCB.

-Kevin

Re: What Dr Joe Wants for Christmas...
 

I wanted to add that a distributed control system as we have now with the PWMs is more desirable from the point of view of student builders. A looping serial bus would kill those teams that have trouble with the PWMs now. One wire would kill their whole robot, potentially.

Re: What Dr Joe Wants for Christmas...
 

You nailed my thoughts exactly Al.
I was hesitant to mention this aspect, or concern, not wanting to be a wet blanket, but Al is correct. There a MANY teams that have difficulty with what FIRST has provided already. Completely changing the design will require some phase in time, maybe in the order of years.

I like what Joe J. said,


The "50%" is a great, or reasonable, starting point. Not all teams have the luxury, or blessing, of having multiple, highly skilled and experienced engineers to support them. Many are fortunate to have just one. With that being said, I must admit, I will never stop being amazed at what these teams are capable of achieving, even when facing obstacles such as this, and still creating capable robots anyway!