What Dr Joe Wants for Christmas...
 

...if it arrives by Kick off, I'll be happy.

Reading this thread about how to control an Omni Driver robot, I read about this paper ($1.50 for a copy from Circuit Cellar -- worth it!) written by Rich LeGrand who works for Charmed Labs (who, as it turns out make some pretty cool robot things -- check out their site -- really) .

The paper make reference to the idea of using Back EMF to control a motor. The great thing about it is that you don't need to put any extra stuff on the motor to get PID control. At the Charmed Labs site I found this video that dropped my jaw.

If you want to learn more about how it works, look at this link from another cool robot website, Acroname.com. I think they really do a pretty good job of making the concepts understandable.

Anyway, I think that some smart person at a company that makes stuff for FIRST robots (IFI, AndyMark, Radio Shack, etc.) could make a mint and, more importantly could do all of us FIRST robot builders a huge favor, if they made an Victor-like product that had PID motor control via Back EMF sensing built in. Actually, Acroname.com is part of the way there already in that they offer an H-bridge with velocity feedback built in (Yes, it is too wimpy for FIRST it still shows the idea).

Think about it. Right out of the box, you could have robots driving the way robots aught to be driven: in closed loop not open loop mode.

I am not sure I'll be able to sleep at all on Dec. 24th...

...visions of well behaved robots danced in their heads...

Thoughts?

Joe J.

Re: What Dr Joe Wants for Christmas...
 

Wowh. man i realy want that. imagine a robot that goes straight exactly how far you would like it to go. and arms. Dont even get me started

Re: What Dr Joe Wants for Christmas...
 

this is crazy...put me down for it all too...i want but of course i can't have so sad...

robot going straight :ahh: that's crazy cool...

Re: What Dr Joe Wants for Christmas...
 

WOW
Tiff. and Tytus are thinking motion aspects...what about the reverse...
Automic holonomic/mecanum parking brake anyone?

Re: What Dr Joe Wants for Christmas...
 

why not instead of using an expensive piece of equiptment, use a simple brake . and save all that money?

Re: What Dr Joe Wants for Christmas...
 

I'm thinking the whole point of Back EMF is you don't need to use any expensive equipment, such as encoders.

Re: What Dr Joe Wants for Christmas...
 

If a robot using a brake does in-fact get moved, it stays on brake, in its new moved to spot.
If a robot with that control system gets moved, its tries to get back to where it was before
Also, I think the circuitry would weigh less then a mechanical brake.


EDIT//
Joe, I am confused, I understand that it can maintain constant motor speed and motor position, but can it determine distance? Or is that just run through a formula through the constant motor speed function?

Re: What Dr Joe Wants for Christmas...
 

I wonder if this technology is or can be used in CNC machines.

Re: What Dr Joe Wants for Christmas...
 

You might be able to set up your own Back EMF controller using the current sensors we got a few years back. If I read the article right (I skimmed), the readings are made by setting up an interval in which to drive the motors, and to kill voltage and let them free spin. If 50 hertz is the magic number, a nice function to drive the motors in a Back EMF compliant way could be created with the onboard PIC timers.

Now I'm not an electrical guy, but if the current sensors are wired in series with the motor in question, would they not measure current whether being taken from the power source (battery) or produced by motors while floating the windings?

If so, we may be able to set something like this up..

1) Create a timer driven interrupt at 50hz which checks a state flag and does either of the following...
- If in "Drive" State, Drives motor with whatever speed setting needed (either manual or autonomous control)
- If in "Read" state, kills power to the motor, and reads the current being produced.

2) Compare current produced to expected current generated.

3) Drive motors accordingly in next "Drive" state. (ie. Motors are set to neutral, but X amount of positive current is being produced. We would then know the direction and speed the motor is being back driven, and know how to compensate for it by incorporating that number into a PID control loop)

This all may seem very naive on my part, but it might work :confused:

Re: What Dr Joe Wants for Christmas...
 

This seems potentially useful, but (if implemented like the Acroname device) it's quite likely illegal by FIRST's 2005 rules. ("Custom circuits may not...[d]irectly affect any output devices on the robot, such as by providing power directly to a motor, supplying a PWM signal to a speed controller or supplying a control signal to a relay module.") Maybe, depending on the exact implementation, you could convince the RC and Victor to simulate this functionality without contravening the rules, but you'd still need a custom circuit for sensing, and you'd have to hope that the standard controls could respond quickly enough—which may be a sticking point.

So if people want it, they'd better ask FIRST for the appropriate rule change at the earliest possible opportunity, so that <R53> doesn't get grandfathered into 2006—or instead, get IFI build it, and add to add it to the controls portion of the kit.

Re: What Dr Joe Wants for Christmas...
 

Sounds like an interesting idea. Perhaps someone might make that suggestion over here where it might be seen by some of the right folks. :)

-dave

Re: What Dr Joe Wants for Christmas...
 

Whoa,
Don't go getting all excited yet. The technology behind the this discussion still has a lot of variables in place that would make this impractical for our use. There is too much production variation in the motors such that any two motors will not produce the same voltage when turned at the same speed. Add to that the resistance of the power leads and their length, temperature, connector resistance, etc. and you will see that precise speed control and distance is a going to be inaccurate. It may be possible for a theoretical controller to "learn" the circuit charachteristics, but at varying speeds and the short distances traveled I think there is still a lot of room for error. I would need a little more convincing before I would jump in on this.

Re: What Dr Joe Wants for Christmas...
 

There are parameters that get tuned but I don't think this would prevent this from being a very useful feature.

Note that the guys at Charm Labs are selling robot systems right now that do just what we are talking about. Somehow they are dealing with motors variation, temperature variations, connector resistance, etc.

Also, talking to Jim Zondag of the Killer Bees (#33) about this, the auto industry has gone to this type of a system for the motors that drive the vent doors inside of HVAC units (replacing pots and/or switches for position feedback). I think this is very encouraging news.

From my point of view the most disturbing thing is that the process requires that the PWM be less than 100% In most cases that would be just fine BUT there are a lot of cases where I would want to have the motors get full power.

I am extremely hopeful.

Joe J.

Re: What Dr Joe Wants for Christmas...
 

This thread got me thinking, ( I know, sometimes that can be dangerous) " How could I simply implement something like this with the hardware and software we already have?" Here is what I came up with.

In a nutshell, the EMF system is taking feedback directly from the motor during a period of "coasting" without any drive signal.

Why not add a small motor or generator, like an Micro RC car motor, to the driven axis and get feedback from it? The drive motor will turn the driven motor causing the driven motor to create a voltage/current source proportional to the speed of the drive motor. With gearing, and a little programming, this could be used in a closed loop feedback system similar to the EMF systems. This would negate the need to interrupt the PWM signal, sample the EMF value and then re-apply the PWM in our systems. We could do the sample and drive signal modifications in real time.

BTW, I know there are already motors available with tachometer circuitry built in. Many of these use optical encoders and put pulse trains out and some are strictly analog. Either design should be fairly "easy" to implement.

Thoughts???

Re: What Dr Joe Wants for Christmas...
 

I am all for other sensors, especially if they are baked into the motors in the kit. I suppose that Chiaphua Motors (the makers of the CIM motor) would be willing to design in a cost effective quadrature encoder on the motor they sell FIRST if FIRST asked them. When I was with Delphi, I was AMAZED at how cheaply these guys could make a motor with very cool features (it was my research into finding a better motor supplier for Delphi's Power Sliding Door applications that got Chiaphua involved in FIRST).

One thing I don't like about this approach is that we are loading down the CPU. Eventually we will get to the point where interrupt load makes keeping track of dozen or so motors brings the MicroChip processor to its knees.

The Victors already have a brain onboard (as would most modern speed controllers). Given that, it would be nice to fob off some of the sensing and thinking required to implement closed loop motor control onto that remote brain.

Before folks object, Yes, I know that this would still require tuning and passing of parameters to get the PID loop to behave, but it would be a trade-off worth the cost.

I really think that FIRST could benefit from hiding the implementation details of feedback loops while making them standard operating proceedure of FIRST robots. We want FIRST robots to act like robots but we don't give folks the tools that robot designers have. Ask Copioli and other pros that design robots for a living: Closed loop motor control is a given.



Joe J.

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!

Re: What Dr Joe Wants for Christmas...
 

It should be possible to do the "looping" at the RC if that is a concern. Instead of PWMs 1-16 we have now there could just be 16 (or whatever number is reasonable) bus taps. That would allow flexibility to wire either in a daisy-chain or star configuration or a combination of both (as I suspect would be most useful).
Definitely a concern, but how big of a change would it be, really? I suspect if something like this were attempted, the speed controller by default could be programmed to react basically the same as today's Victors. Thus, the only real change would be in the way they are wired to the RC, but as I said even that could be minimized. This seems potentially much less disruptive than the move from PBASIC to C for the RC (which I thought would really hurt many teams, however it appears the impact was negligible).

Re: What Dr Joe Wants for Christmas...
 

Mostly true, Dave.
There were so many teams with multimotor designs that needed help getting them hooked up correctly during inspections, I was just being lazy for next year. More than one team looped the PWM cables underneath other structures and eventually had them connected back to another output on the RC while the two motors had PWMs connected together. This is one area where we need to _____proof the design of components. I am sure that the IFI guys came across much more than I did.

Re: What Dr Joe Wants for Christmas...
 

Concerning alternatives to CAN:

My experience (limited I know) is that I2C and SPI can work just fine with reasonable jumps to piggy back boards. We may have to slow down the clock speeds, but we are still lightyears ahead of the current situation.

Concerning 1 wire failure vs. the current 16 PWM wires:
I know which failure I would choose. With 1 wire on a serial wire at least you get feedback if a Victor goes dark. There are a lot of times when we don't know if the Victor died, or the PWM cable unplugged or the motor lead came undone. It would be a relatively simple matter to set up a dashboard program tell you "lost Victor N" rather than having to go to each Victor to look for for a solid orange LED. Also, with only one connector to the RC you may actually be able to have a connector housing that ensures good connections and perhaps even a positive locking feature.

As doing absolute position feedback with the back EMF method:
I think that end of travel switches can help calibrate the integration. Also, even without such as sync switch, this is no different then having quardrature decode on our wheels. Without a "zero" point, you can't control to absolute position. While I am on the topic, the folks on Charmed Labs claim that the drift from the integration of velocity to position is on the order of what they see from wheel slip when they use encoders. I don't know if I believe them but at least that is their claim.

As to the speed of the motors that they are controlling:
I am more impressed that they can make it go slow to be honest. From a controls point of view, I think the signal to noise problem is worse making an ungeared or lightly geared motor go slow that going fast. There are limitations to be sure. The limit on the duty cycle of the motor is definitely going to cause problems in some applications as will drift, parameter tuning etc. But on balance, I think that there may be something worth exploring for future FIRST robotic applications.

Good discussion in any case.

Joe J.

Re: What Dr Joe Wants for Christmas...
 

Closed loop control systems are wonderful but, they present 2 problems introducing them into the FRC. They add complexity and cost. Remember, these are high school students and they are getting hit hard with allot of advanced concepts. First they have to master the pic IDE and c as it applies to the Pic 18. Then there is the default code and the basic electrical wiring. It's amazing that every year even rookie and bare bones teams get something working as it is now. Not ever team has access to EE's.

Then again there are teams that have students and mentors that are capable of adding closed loop control to the robot. I would be in favor of keeping the base FRC and motors as they are now. RS485 ports could be added to the controller and the rules changed to allow a coprocessor to drive the victors directly. Some basic coprossesor function libraries could be added to simplify and standardize the communications. This could be done with little added cost to the FRC.

This year a magnetic sensor was included in the kit. The year before an Allegro current sensor was included. How much would it cost to integrate the magnetic sensor or an output shaft for an encoder or photo interrupter into this years gear box? It wouldn't take to much time or money to close the loop on what we already have. It could be an out of the crate solution that all teams could use. The down side is that it would introduce interrupt hell in to the default code.