StangSense: WildStang's Current Sensing System

[Dave Flowerday]

Team #111 Wildstang just completed it's first regional this year at Great Lakes and onboard the robot was our current sensing system which we have nicknamed StangSense. We are happy to report that it performed flawlessly, and now that we have a regional under our belt we wanted to share some information about our circuit for those who are interested.

Description:
Our custom circuit is primarily composed of a Motorola 68HC908 microcontroller and 8 Maxim MAX4172 current sensing chips. Each MAX4172 is connected to a 1 foot piece of 10 gauge wire which is connected between the fuse block and the speed controller. Connecting between the fuse and the speed controller eliminates the problem of current flowing in the opposite direction when the motor runs backwards. This piece of wire has a resistance of 0.001 ohms. Using this information, we can set the MAX4172 chips to show whatever current scale we want. Currently we are using a scale of 0 to 130 amps. This means that at 130 amps, the MAX4172 outputs 5 volts to the microcontroller's ADC.

The microcontroller runs fast enough that it can sample the PWM pulses accurately. We are able to sample each motor current at roughly 6 to 8kHz. The microcontroller averages roughly 0.1 seconds worth of these readings before forwarding the average to the robot controller.

Data from the HC08 is fed into the robot controller using the digital inputs. We use 4 digital inputs to specify a motor number and 7 other digital inputs for the current data for that motor. This information is then placed into the packets that are sent to the operator interface without the intervention of the BASIC stamp. In this way, the BASIC stamp can read the motor current data if it wishes, but the data will be sent to the dashboard port at the operator interface regardless.

Once the current data is in the packet, the packet is sent over the RF link to the operator interface. Here, the packets are sent out the dashboard interface into a Palm m505 for further processing. The Palm parses the packets to produce several different displays as well as stores the packet data for post-match analysis. Here are a few screenshots of our Palm display:



The first screenshot is our bargraph mode which simply displays a bar which changes length and color depending on current. The second display is our blueprint or schematic mode which displays a graphical representation of the robot and uses color to indicate the current in each motor.

Once a match is complete, the StangSense database is downloaded from the Palm onto a laptop where further processing is done. With this data we can generate graphs of each motor's current as well as the battery voltage over the course of the match. Here's an example taken from one of our matches at the Great Lakes Regional (please note that on the Y scale, the numbers do not represent actual amps, but rather the 8 bit value that the microcontroller ADC is reading):



For those teams that will be at the Motorola Midwest Regional this weekend, please stop by and take a look if you're interested. Also, if there's anyone else attending MMR who experimented with a custom circuit, please reply here as we'd really like to see what other teams did. Good luck to everyone, and we look forward to seeing you at MMR and Nationals!

[BSMFIRST]

Cool stuff! What's even cooler though, is that you shared it with everyone.

Good luck,
Dan

[Greg Ross]

From your description, it sounds like you don't use the information on board the robot to actively limit the current consumption. Is this correct? And once the data is displayed on the Palm, I take it it is left up to the driver what to do with the information. How does that work? Are they able to respond and keep from tripping circuit breakers?

It looks like you must only sample a single motor on each 40Hz program loop. Is this correct? (There are only 16 digital inputs in total, and 4 inputs for the motor number plus 7 more for the data doesn't leave very many for switches, etc. -- let alone for another motor sensor. ) Do you then sample all your motors in a round robin manner?

[Tom Fairchild]

VERY cool stuff!! My hats off to you.

~Tom Fairchild~

[Dave Flowerday]

Greg,
At the moment the PBASIC code running on our robot does not use the current data to limit motor output. We are beginning to experiment with that on our practice robot now. Right now the information is merely presented to the drivers. Unfortunately getting their attention can be difficult during a match, so we are exploring the possibility of having the Palm make alert noises when conditions are bad. We actually are not having any problems tripping breakers at the moment so that hasn't been an issue. However we are working on incorporating a mathematical model of the circuit breakers into the Palm so that we can predict when the breakers are getting close to blowing so we can alert the drivers.

As for the motor sampling, I think my explanation above was slightly off. What we do is sample each motor for approximately 1/8 second as fast as we can (roughly 60kHz). The average of this dataset is then sent to the robot controller, and the microcontroller moves on to the next motor. Each time we output the current motor we are sampling as well as the average current. Even though we have 4 bits for the motor number we only use 3 (8 motors). We left the extra bit for other possibilites such as using the gyro. Our robot only uses a few limit switches so this is how we can get away with sucking up so many of the digital inputs. However, earlier in the season we weren't sure if we could use those digital inputs or not so our custom circuit board is equipped with a DAC so we can output an analog average to the robot controller.

[ECarlson]

Impressive!

[K. Skontrianos]

Nice Stuff!!!We talked about building the same thing for our robot, be we didnt have enough weight for an amp box. We came up with a very good back up plan, that worked on last years' robot when we tested it. We used magnetic switches to tell when the shaft on our drive motors were moving or still. If the program found that they were not moving and the joysticks were near full forward or full reverse, then it could assume that the motors were stalled instead of being off. The program then reduces the pwm output to the motor to a value that would not draw sufficient current to pop the breakers. We had it accumulate the information about every .25 seconds. While we built the mechanism on this year's robot, we never tested it or used it because we had no problem cutting out, amazingly. Measuring the current is probably a lot simpler, especially to program. Our switches were a pretty slick back up, though.

[Joe Johnson]

Very cool.

This is the kind of thing that I wish we had time to implement.

Nicely done.

I like that you are using a 1ft section of wire you would have had to have in the system anyway to implement your "shunt resistor" Very clever indeed.

Joe J.

[Al Skierkiewicz]

Stangsense has now been field tested and has proved very useful for post match analyzing as well. In comparing currents and battery voltage graphically, we can look back at a match and correlate peak current demand and battery dips very accurately. So accurately in fact that we can see when our robot "shoots" out a ball into the goal. Also by checking post match data, we have been able to determine a list of minor problems that needed to be addressed in the pits. On one match we saw higher current in one drive module indicating that it had come out of alignment and an adjustment was made. In another we were able to determine that for part of the match, one motor was not on the floor.
What has proved most helpful though, is our mini version that is portable enough to carry to other teams, make a few motor connections and analyze electrical problems on their robot. We are able to pinpoint defective motors, high current draws for individual motors in a multi motor drive system, running current vs no-load currents and voltage drop in wiring.
Stay tuned as we further analyze some data we will publish some graphs later this week.
Good Luck All

[Tom Fairchild]

How useful has StangSense (which is, btw, a very cool name for a VERY cool feature) been during the actual matches? Does the coach/driver check to see if motors are stalling during the matches?

~Tom Fairchild~

[Al Skierkiewicz]

I will have to let you know after a team meeting tomorrow. Since we have found that over current is not a serious problem with this robot, it may not be used in real time while driving now. It has made a difference in showing drive and strategy teams what functions on the robot carry the highest risk and we have modified driver methods accordingly.

[Digo]

Congratulations to team 111!
Last year you had maybe the most incredible robot and this year you seem to have special things again.

This feedback from the robot is fantastic, and I'd like you to answer that previous question: was it useful?
and also: did you get any award for that in a regional?

[Al Skierkiewicz]

Digo,
This is the initial report I have had from the drive team. (Hard to get as they are on Spring Break this week.) The driver does not monitor the palm during the match but our button box operator does have the time and watches not only the palm but also the battery voltage monitor on the OI. Our human player may also play a part in watching the monitor and checking the field to help coach strategy, a second pair of eyes is always a good thing! Although there were no specifics, I suspect that the drive team does check it out when we are in a pushing/pulling situation to make sure we are not close to resetting the controller. What we have been doing though, is reviewing the match data back in the pit and the drive team will be present to ask questions and point out times in the match they remember were struggles.
BTW, we are downloading/converting the raw data from the palm into a spreadsheet and then plotting all eight motors and battery voltage on a laptop. When anything looks out of the ordinary we alert the mechanical or electrical pit crew to check for problems (bent or misaligned parts broken wires, etc.)
As to awards, no, none yet. Stop by out pit and check out the graphs and write up (we have a report board set up) or if you are having problems on your robot, ask us to analyze with mini-StangSense. We have accumulated a lot of data over the last two weekends working with teams. You would be surprised at the differences in some designs, between running with the wheels off the floor and actual driving in the pits. I can only hope that the teams we worked with were able to correct some design problems and get back in the game.
Good Luck All