TI and future Jaguars

[techhelpbb]

Per some of the existing comments in this topic:

Originally Posted by Al Skierkiewicz

I think it is time to restate some basic principles here...
1. The resettable breakers are chosen to prevent fires on the robot. Nothing exotic about this, the current rating protects the wiring. What you choose to connect is up to you, the user. The breakers are not intended to protect a relay, a speed controller or anything else you put on the robot.

No interest in waiting for the breaker. I hope we fully intend to implement adjustable current limiting that will cut out cleanly at the limits much faster than that breaker can manage and at optionally higher limits than the Jaguar.

2. You must consider that these devices are going to be used by inexperienced students up to and including very experienced mentors. They must be designed to satisfy both groups with ease.

As far as ease of use is concerned, given the admission of TI to members participating in this topic of the known existing short-comings I think it should be easy to start with good documentation and make the immediate change in taking responsibility to acknowledge and resolve issues actively. Far too much effort was required by existing members to realize a good list of issues positive and negative for the Jaguar. The life of this project is not predicated on the need to cover our tracks as it were.

3. Any modular design you come up with had better be fully insulated, i.e. no exposed conducting surfaces.

Technically as the metal tabs on the existing Victor MOSFETs are exposed and very much conducting surfaces I'm less worried about the use of connectors that entirely wrap the pins like 0.1" pin header males and females. Given the existing designs of both the Victor and Jaguar use 0.1" headers (PWM, encoders, jumpers) I should think they qualify especially if the parts of the electronic motor control are literally locked together with bolts. I think we fully intend to make it entirely practical to remove those connectors and hardwire the modules together. We'll leave it to FIRST to decide if that's reasonable to allow that bit of soldering.

4. Must use common wiring methods.

Screw terminals for the high power wires (no fancy connectors). 0.1" headers or terminal blocks for the rest as necessary. Prefer to avoid buying large quantities of terminal blocks but they do make swaps much cleaner.

5. They must be addressable through the current hardware solution (PWM or CAN) and be capable of being commanded to make zero output from the field controllers.

Eventually I would like to have I2C or the 'custom circuit module' but for now I just want to ship what we know works with the rest of the control system.

6. This protection must also compensate for failures in the robot driver interface(s).

FIRST's limits will be implemented in software for any interface module we make. If we do make the 'custom circuit module' it's only purpose is to impose FIRST's limits anyway. To my knowledge these limits include: maximum current, brownout voltage, field disable, in-band field disable (where applicable). The current Victors don't really offer much in these regards either...other than stopping...I think we can certainly do better than that.

7. Above all, they must be easily inspected for conformity to robot rules.

Besides offering FIRST a 4 wire connector to verify the software and settings of the modules, I hope we fully intend to keep the enclosures for this simple and if at all possible cubic. So at most if someone wanted to see what's in the electronic motor control box it might just be easier than with the existing Jaguars. Injection molding cool looking enclosures is a nice luxury when you have the pocket for it, in this case I'm less worried about that.

[Al Skierkiewicz]

Originally Posted by techhelpbb

FIRST's limits will be implemented in software for any interface module we make. If we do make the 'custom circuit module' it's only purpose is to impose FIRST's limits anyway. To my knowledge these limits include: maximum current, brownout voltage, field disable, in-band field disable (where applicable). The current Victors don't really offer much in these regards either...other than stopping...I think we can certainly do better than that.

Those are not First's limits. Those were chosen by the original manufacturer. The only FIRST limits are the safety issues of stopping all output when commended by the field. What are you calling "in-band field disable"?

[techhelpbb]

Originally Posted by Al Skierkiewicz

Those are not First's limits. Those were chosen by the original manufacturer. The only FIRST limits are the safety issues of stopping all output when commended by the field. What are you calling "in-band field disable"?

For the purpose of the RFP/RFQ provided to manufacture the Jaguars essentially FIRST seems to have adopted those limits. Luckily that's only serving as a template at this point not an absolute. FIRST KOP did indicate they would be flexible about the current limit and that's great because I'm good letting currents flow up to 90As often even with the 40A breaker. I'd also love a nice latched visual indication that any current limit within the controller was exceeded for quick troubleshooting.

The CAN functions implement not only FIRST's protocol to check that the FRC firmware is present (BTW that's been totally hacked so it would be dead easy to slip some other firmware in there...we don't use Jaguars on Team 11 any more so I don't feel concerned pointing it out) and in effect implement the field disable in-band on the CAN bus. Not that anything would know if you hacked the Jaguar firmware anyhow if you used PWM.

PWM is not much of a bus so I don't consider the absence of signal in-band. That could happen sitting on a bench all by it's lonesome.

If we do make the 'custom circuit module' I suspect it'll just use a digital I/O as a global disable/enable, so that would be out-of-band disable.

[Al Skierkiewicz]

Again,
Explain in band and out of band, please, in your context.

[Tristan Lall]

Originally Posted by Al Skierkiewicz

Again,
Explain in band and out of band, please, in your context.

I think he means that the disable signal is either an element of the control signal (neutralizing PWM to disable is "in-band"), or a separate signal (neutralizing via digital I/O + PWM is "out-of-band").

[PAR_WIG1350]

Here is a concept of a modular controller that was inspired by the system used for arduino 'shields'. The stack is fed power from the bottom up, with high power circuitry at the bottom on one module, this eliminates the need for high current connectors between modules. The fan is mounted just above the high current module to cool the MOSFETs. The low-current section of the stack is mounted above the high current module and fan with a gap for air flow. The signal (from the cRIO) is fed from the top down, this separation of power and signal inputs helps reduce noise. the processor is on the bottom. In some configurations, this could be a simple PWM H-bridge driver, in a CAN application, this would actually be a micro controller/processor. It is designed to accommodate 2 input modules that are each half the width of the other modules (so they occupy the same layer in the stack). One of these would be the pwm header or CAN interface. The other is for encoders, limit switches, potentiometers, hall-effect sensors, etc. On top is the auxiliary output. This is for status indicator lights and error reporting.

[techhelpbb]

Originally Posted by Tristan Lall

I think he means that the disable signal is either an element of the control signal (neutralizing PWM to disable is "in-band"), or a separate signal (neutralizing via digital I/O + PWM is "out-of-band").

Basically.

In telecommunications when we are doing in-band management we are managing something often over the same bandwidth that infrastructure is providing (SSH for example). When we do out-of-band management we are providing some alternative communications infrastructure to manage devices (a dial-up modem to a Cisco console port for example).

If you can somehow communicate over the CAN bus to the electronic motor control your intention to disable it you are operating in-band.

If you add a digital I/O wire to communicate the disable you are operating out-of-band (there's probably no other communications on that disable wire, or as much of my industrial stuff would call it the e-stop). The addition of the alternate communications infrastructure makes it out-of-band.

Stopping PWM might be considered in-band signaling in some ways, but personally, the absense of signal into a motor control to me should just naturally make it stop. Just as if you powered it up on a bench to test with no signal input. That's really a fault condition to me because generally with PWM there's a certain pulse width that's the neutral position for the speed control and in the absense of even the base frequency you may as well have left it floating.

[techhelpbb]

Originally Posted by PAR_WIG1350

Here is a concept of a modular controller that was inspired by the system used for arduino 'shields'. The stack is fed power from the bottom up, with high power circuitry at the bottom on one module, this eliminates the need for high current connectors between modules. The fan is mounted just above the high current module to cool the MOSFETs. The low-current section of the stack is mounted above the high current module and fan with a gap for air flow. The signal (from the cRIO) is fed from the top down, this separation of power and signal inputs helps reduce noise. the processor is on the bottom. In some configurations, this could be a simple PWM H-bridge driver, in a CAN application, this would actually be a micro controller/processor. It is designed to accommodate 2 input modules that are each half the width of the other modules (so they occupy the same layer in the stack). One of these would be the pwm header or CAN interface. The other is for encoders, limit switches, potentiometers, hall-effect sensors, etc. On top is the auxiliary output. This is for status indicator lights and error reporting.

Even with PWM you'll need at the minimum a microcontroller. One can easily perform the functions required with a simple Atmel AVR or Microchip PIC 8bit microcontroller. You can even do it with a BASIC Stamp 2 (which is merely a Microchip PIC with a built in pBASIC interpreter) it's not really a big job.

For this application it'll probably be more expensive to attempt to tweak an input PWM signal to drive the H-Bridge directly than just putting the microcontroller on the board. This is not to say that you couldn't drive an H-bridge with PWM. It is to say that to get linearity, current monitoring, thermal monitoring, and perhaps some other features it just makes sense to use the microcontroller and a cheap crystal. Even just a few cheap operational amplifiers otherwise would approach the same cost (plus be larger and possibly more easily effected by heating).

It's not clear to me how you would be able to benefit from inputs on the PWM version. I suppose you could use them to provide basic limit switches. However, generally PWM is an output from the existing control system and an input into the electronic motor control. You'd need to come up with some way to configure the electronic motor control to get more elaborate when using PWM. With CAN I can see having optional input and output modules would add more flexibility.

The idea of stacking things on top of the fan has a slight issue with it. If the footprint of the unit is nearly that of the fan you need some way to get communications to the power module under the fan. That's why originally I had envisioned building the other way and letting the connectors extend out from the sides of the stack. After all if you look down at the fan on the Victor the footprint extends out where the connectors go. Essentially the issue of your diagram is that you've created several places where we loose PCB space to keep the footprint entirely under the fan. I do agree, however, that the headers that interconnect the boards will likely end up on the edges. Perhaps the larger issue is that the air gap between the fan and the processor actually would work against you. With the controls below the power module it's easy to put a laminated foil shield between the bottom of the power module and the top of the processor. With the fan at that spot in the assembly such a shield might become a liability as it could restrict the air flow that's already being blocked by the processor anyway.

I will say that this footprint is smaller then what I originally described. I'm just worried that using the space like that might make it hard to put indicators on the unit and with connectors for I/O in the middle you risk situatiuons with the PCB layout where the through-hole parts eat away at your space to route traces. I'm additionally not really sure that we need too many input and output modules because most of the I/O is going to be directly reflected on the processor card with perhaps the notable execption being the encoder if you install a CPLD or purpose designed IC to track that.

Course we could take the whole thing a step further and simply use an FPGA and put a small simple processor in the FPGA, along with the encoder tracking functions and skip dedicated processors or microcontrollers all together. The major advantage with that would be we could embed new features that run at raw digital speeds.

[Al Skierkiewicz]

Tristan and Brian,
When dealing with the FCC and RF transmission, 'in band' and 'out of band' mean entirely different things and carry heavy fines.

[techhelpbb]

Originally Posted by Al Skierkiewicz

Tristan and Brian,
When dealing with the FCC and RF transmission, 'in band' and 'out of band' mean entirely different things and carry heavy fines.

http://www.silicon-flatirons.org/doc...ing%20List.pdf

When licensing RF spectrum so far as I know the basic context is the same.
You are supposed to confine your RF emissions to the operating bands as licensed or permitted (within reason). Everything within that permitted range is in-band. Everything outside of that permitted range is out-of-band.

So it's really not all that far off. It's just that the RF spectrum is regulated by a licensing authority (FCC).

There's no CAN police...and if there were...I suspect they'd have issued a lot of fines by now.

In any event I intend to take my spectrum analyzers and near field kit to this near finished prototype to insure that we are in fact not producing a handy dandy Class D/E RF amplifier. I'm not planning on FCC certifying the unit but if it's producing junk we'll shield it appropriately.

[Al Skierkiewicz]

Brian,
It is important to remember that many of the members of this forum cannot understand a post when it uses undefined technical jargon specific to a particular industry.
In your context, you are describing parallel or multiplexed control pathways that are valid for their intended purposes in a closed system. In my work, the same terms are used to describe intentional modulation vs unintentional interference to other broadcast services or multiplexed transport streams. I am not suggesting that my context has anything to do with the design of the control system in the device your are describing. However, for FCC purposes, these devices will likely be considered under the computing device classification for the FCC under Title 47, Part 15 of the Rules and Regs.

[techhelpbb]

Originally Posted by Al Skierkiewicz

Brian,
It is important to remember that many of the members of this forum cannot understand a post when it uses undefined technical jargon specific to a particular industry.
In your context, you are describing parallel or multiplexed control pathways that are valid for their intended purposes in a closed system. In my work, the same terms are used to describe intentional modulation vs unintentional interference to other broadcast services or multiplexed transport streams. I am not suggesting that my context has anything to do with the design of the control system in the device your are describing. However, for FCC purposes, these devices will likely be considered under the computing device classification for the FCC under Title 47, Part 15 of the Rules and Regs.

It's certainly not undefined technical jargon, it's term often used by Cisco themselves and they are certainly a key player in the networking industry. It's a term that's been in use since IT&T Telex days in the telephone industry (DTMF) and that predates myself (I worked on Telex well after it's prime when they were winding down TimeTran (TimeTran was not just a trademark of IT&T it was the name of a set of mostly TTL communications mainframes at 67 Broad St. in NYC) and working on ARX (was the software version that didn't require wire-wrap tools and 300MB 19-head hard drives bigger than end tables)).

http://www.cisco.com/en/US/prod/coll...d802bdc42.html

My copy of Newton's Telecommunications Dictionary is not on my desk or I'd post that definition.

It's just a perspective issue in this case. I'm looking at it from a physical infrastructure stand point. You're looking at it from the permitted RF emissions stand point (which is fine but we're still working out the structure stand point). I'm not sure how many people reading this are licensed ham radio operators any more (which stinks but I sold off my rig years ago).

None the less, I fully intend to test this unit far more than I think FIRST will require. In the past I've been surprised by the shear amount of energy even my low voltage LED lighting can emit in the RF spectrum. It's part of the reason my LED lighting power supplies intentionally walk their base PWM frequency and cycle timing from module to module (12V and 10kW could make a mighty amount of RF interference).

[Alan Anderson]

Originally Posted by techhelpbb

It's certainly not undefined technical jargon,..

It was undefined in the context of your post. I certainly didn't have any idea that you were talking about something like adding additional wiring dedicated to the disable function.

It's just a perspective issue in this case. I'm looking at it from a physical infrastructure stand point. You're looking at it from the permitted emissions stand point.

No, he's pointing out that you used terms with multiple established definitions, and it wasn't at all clear which (if any) of them you meant when you used them.

[techhelpbb]

Originally Posted by Alan Anderson

It was undefined in the context of your post. I certainly didn't have any idea that you were talking about something like adding additional wiring dedicated to the disable function.

It was actually discussed previously in the topic...almost all of it was.

No, he's pointing out that you used terms with multiple established definitions, and it wasn't at all clear which (if any) of them you meant when you used them.

It's fine. It's just that we were discussing the structure of the project and it was already discussed previously in this topic. I had no reason to suspect that people weren't reading it. See post #27 on page 2 from me.

None the less this forum structure for communications has this as one of the downsides, which is why while I've have PHPBB on the website I'm setting up I'm also working on making sure the current state of things can be glanced over sans all the back and forth communication that eats up time. This structure leads to a lack of persistent communication of key points and sort of a they-who-posted-last...posted-best pattern that's often just not productive.

[Al Skierkiewicz]

Alan's observation is exactly correct.
The majority of the audience has no idea of what the meaning of the terms that Cisco uses internally or the phone company for that matter. As to your previous post the same applies.