TI and future Jaguars
 

My wife was strolling through the FIRST website this morning, when she found this:

http://www.usfirst.org/uploadedFiles...sal-Jaguar.pdf

I'm not sure what to make of it. It looks like a several year commitment to the Jaguar, but it also looks like Texas Instruments is going to punt :confused:

-- Len

Re: TI and future Jaguars
 

From what i saw it just looked like a two year commitment but i really just skimmed through it. My team personally likes to use jags so i dont have a problem with them being more available. By the way congratulations for winning the RCA in Vegas it was a really fun regional.

Re: TI and future Jaguars
 

Thank you very much! We had a great time, and we are proud of our students.

We exclusively use jaguars, now, so we are all for Improving their function, quality and availability.

-- Len

Re: TI and future Jaguars
 

Page 6 of 11:
"TI is donating all aspects of the Jaguar product (rights, design, firmware, etc.) to FIRST for continued use in and management by FRC. Furthermore, TI has committed to working with FIRST and partners to transition the product effectively and efficiently. This RFP solicits support from outside organizations for help with hardware, firmware, and software support, manufacturing, sales, warranty, and FRC and community technical support."

Well this document is signed by the KOP team members, procurement and a Director, but not TI. The KOP team members would have to sign off.

I know because:

On 3/29/2012 I sent a request to FIRST to discuss the requirements to create an approved electronic speed control including the relevant costs and timelines. The request was directed to KOP at FIRST corporate request. I had considered manufacturing a CAN enabled electronic speed control with community input as to it's design and wanted to get an idea of the obstacles.

Further, interesting because I've had several private conversation regarding the limitations of even addressing firmware issues with relation to the Jaguar. I am neither surprised by what appears to be TI's decision to hand this to FIRST or by the fact that at the core of the issue now becomes who is going to handle the relevant details.

Re: TI and future Jaguars
 

I guess what is confusing me a little about this RFP, is that it looks like FIRST is not soliciting a contract manufacturer, but a full-service company to completely take over all development and support of hardware and software. TI chips are to be retained, as is the Jaguar name.

What I am missing, is why this isn't a more open-ended solicitation, where applicants could propose totally new designs that meet the requirements. It reads as though they want an improved Jaguar, in a Jaguar package. Whoever wins this will be responsible for support of the new Jaguars. Will they also be responsible for supporting the tan and black Jaguars? That could be quite a burden for a small company.

If I were to change or add features to the current model (one part of the proposal), I would probably focus on software features to add more configurable parameters for the PID controls. For the hardware, I would add a pair of 7-segment LED's to the current single multicolor LED, to indicate CAN address, error states, or operation mode. As an educationally focused motor controller, this would be a valuable addition for troubleshooting. I think the cost of adding this could easily be offset in reduced support calls for ambiguously blinking LED's.

-- Len

Re: TI and future Jaguars
 

I would add a diode to the control board, so reversing input power wouldn't fry the jaguar. It's a cheap and effective fix to a problem that has cost many teams hundreds of dollars.

Ooh, and how about the ability for one Jaguar's PID to slave itself to another. Because we often use two motors on one shaft and one encoder.

I agree, an open opportunity to make a new motor controller could really benefit teams, which would further FIRST's goals.

Re: TI and future Jaguars
 

Actually it appears to be plural or singular. So either a single company to do the whole thing or several companies each accepting a part of the greater project. See page 3 of 11, the section RFP Component Responses, the first paragraph.

Well if you think about it you've got (now less than) 30 days to respond or you are cut out (page 7 of 11, top, due May 11, 2012...page 3 of 11, see sentence with e-mail address to send response to) I've already tried to call FIRST on this matter and gotten no response at all (very disheartening). Even if I wanted to propose something no communications means it won't happen.

If you are a company who manufactures power electronics, and you follow these forums, when you do your due diligence do you think you will submit a proposal within 30 days? Basically you're taking the risk that you'll be asked to accept production volume on a product you don't get to design at all (page 7 of 11, the section Specifications, the second sentence...the only requirement they want separate is coating the boards, see item M...and they need that because of SWARF!). A product that you'll have to produce in quantity in possibly short order from documents that have typographical errors in them (let's just assume that the images on the pages can be reversed and scaled to Gerber). Never mind that I can't even tell if you will inherit *all* the injection molds (and that's not cheap tooling) (see page 9 of 11, the section Available Project Resources, item C).

If the request is for me to make the Jaguars precisely the way they are and agree to that in 30 days, I would say no. I'm sorry but I've already expended $4,000+ dollars just trying to get information about the Jaguars that you can't read in the manual. I know how to use them and when they should not be used. I can't in good faith accept liability on this product and I'm not the sort that hides behind my disclaimer.

I suspect I am not alone in this concern and it's purely a business concern so I suspect this means that in 30 days FIRST is going to be short support vendors. Otherwise the section Proposal Evaluation Criteria (page 10 of 11) is FIRST telling the vendors they are already courting the ground rules and this process is just perfunctory. The item I of the Proposal Evaluation Criteria specifically jumps out at me as hoping they'll not have someone that already makes approved speed controls unless they can assure that diversity.

This may be the last ditch attempt to push the life boat clear.

I read it as hopefully make the existing product now and improve on programming first, then incrementally in hardware later. If my interpretation is correct this is actually potential liability you accept if you pick this up as one piece. More importantly this is not good news if you're a Jaguar junky and this dies without response.

Personally I have a website I constructed that I never brought public about the Jaguars. I'd put that up for this request but without communication from FIRST I won't. I'm still talking with Linuxboy about his project and I'll fund and support it if he wishes, but what future can it have if FIRST can't provide more Jaguars or something that needs CAN termination?

There are a great number of things that can be improved on the Jaguars including the size, shape. weight and features through modular design. If you must squeeze new life in that exact box you're not going to get incremental change. However, if you happen to have lots of plastic parts for Jaguars (and I bet they do) you'll save money on making more. I bet that to cover the cost of the molds for the injection molding process a significant number of plastic components were made.

I will publicly commit to this: if I can find out from FIRST the criteria and process to make an approved speed control assuming FIRST doesn't object I'll provide the information to whomever requests it. I've been trying since 3/29/2012 so basically it's an existing project.

If they open this door I'll do my best to try to catalog the feature requests so perhaps a more universal design surfaces. I actually have something I already made as a prototype that works and supports CAN but I can't call something community support with a straight face if I ignore community feature requests.

Re: TI and future Jaguars
 

Oooooooh! I forgot about "follow me" mode. You can do sync groups now, but that doesn't link outputs.

Master - slave could be done with making PWM ports bi-direction configurable. I would hate to flood the CAN bus with all of the sync traffic.

What about multiple bridging CAN buses. Instead of having a passive daisy chain link, make both ports terminated buses, where traffic is repeated across from one port to another. With this, each network would be automatically terminated (like 10-BaseT vs. 10 -Base2 Ethernet). For master - slave, you could un-bridge the two CAN networks on the master node, and use the second CAN bus for sync traffic, exclusive to the pair.

Just more thoughts.

-- Len

Re: TI and future Jaguars
 

My read is that they want the same Jaguars in a Jaguar package, but responders are welcome to suggest changes as well.

They clearly state that FIRST does not have the resources to do any of this, so a contract manufacturer is out - they need someone to own the product. The volumes are small (~10k) as well.

Re: TI and future Jaguars
 

With the statement that they are only guaranteeing that the Jaguar will be used for the 2013 and 2014 seasons, the long term "appeal" of this plan has to be even further diminished to a potential supplier.

Re: TI and future Jaguars
 

I just finished speaking with US FIRST about this.

Basically here's the deal:

A project could be started to make an approved electronic speed control. There are 2 ways this can play out.

1. It could just be approved, if you want to use them you need to go get them yourselves. The process FIRST outlines will try to insure a supply chain healthy enough to make the product available.

2. It could be included with the KOP. This would mean that FIRST might ask for them to be donated or offer up some cash if it's vital to the KOP. There's ambiguity here so let's assume we might have to donate it. This wouldn't stop you from getting more from outside the KOP.

In order to achieve this basically here's what would need to be done:

A. A sample as close to production as possible (preferably) would need to be presented to the US FIRST KOP team no later than the end of August. This will need to have with it essentially a business proposal that describes the business aspects of what is planned and should consider both possible outcomes above.

B. If somehow the end product is selected to go into the KOP then deliverable products need to make their way to US FIRST by October for distribution. Otherwise, you can't disclose the approval of the product until January because you will very likely be prohibited by an NDA. So you can sell it, build it, play with it....but even if you know it's approved you have to keep a zipped lip about it.

C. If this is a community project (and that means we have a bunch of people contributing) this would mean that you'd better basically be ready to make something fundamentally ready for production by the end of August at the very latest. Sooner if you're smart about it. So basically the time to brainstorm needs to roll to a close in probably 30-60 days from now (now being defined as mid-April). A modular design would enable later changes to those modules but they might not get approved for use as part of the electronic speed control system until next year.

So if you plan on trying to do this yourselves you need to realize that FIRST will expect a level playing field for COTS. So you must have an accepted plan to make these things and deliver them to teams all over the world for use at the very least. At the most you might get FIRST to feed funding if the the product is so outstanding that it becomes vital to get it into the hands of every team from the time the KOP is opened.

Re: TI and future Jaguars
 

Some ideas I floated during my conversation:

1. Using off the shelf rectangular polycarbonate boxes (think RadioShack plastic boxes) with necessary machining. It would seem as long as it doesn't interfere with functionality it's okay. It might not be very pretty however. Could fix that later. I suppose this would open the door to plastic welded boxes as well.

2. Raising or lower the current limit. I proposed this to bring this product closer inline with the Victor's performance. They said they'd have to see it work with proper technical review.

3. Making the unit modular. As long as all the parts that could be approved are provided for review that seems okay. It means we could expand the functionality later, but the only approved parts are those that the unit was reviewed with.

4. I mentioned being CAN enabled. This seemed to be okay. I was very clear the point was to add diversity not demote the Jaguar.

5. I mentioned reverse voltage protection and we discussed a little about that issue as well.

Re: TI and future Jaguars
 

So I kept my commitment and shared what I discovered.

Is there community interest in creating an electronic speed control?

Recommendations on how to get started with this as a community project?

I'm willing to fund making some speed control prototypes within reason.
Should we gather prototypes from diverse sources or submit everything to be built centrally?

Re: TI and future Jaguars
 

The commitment to possibly have to donate enough to fulfill the KOP needs, is enough to kill a community project. At least one without a very generous benefactor.

Techhelpbb, what exactly do you mean, when you say modular? Are you talking about add-on modules for CAN, or other controller-specific IO, or perhaps exchangeable H-bridges, to handle different peak loads? Or are you talking about having a rail mount, or backplane connected set of motor control modules?

-- Len

Re: TI and future Jaguars
 

Did I miss something? Not to offend anyone, but is there anyone on these forums who really has the expertise, time, capital, manufacturing connections, and means to mass produce an entirely new speed control in this timeframe? Nice idea, but realistically, I just don't see it happening unless it is already significantly underway. Feel free to prove me wrong.

Re: TI and future Jaguars
 

I recall hearing of something similar happening once...
Maybe even twice.

Sure, these might have had more time, but with more people, it could be expedited. The biggest obstacle is communications. The production could occur at several different locations, but distributing the work load based on ability and producing equivalent products at all locations requires a good deal of coordination.

Re: TI and future Jaguars
 

I am aware that putting these things in the KOP as a donation is probably out of line for a community project that has yet to 'prove itself'. As I said FIRST communicated that their ability to buy an item is ambiguous. In other words we should assume that if FIRST can't justify making sure that these things are in every team's hands the instant the KOP opens (in short that the new item is vital) to get them in the KOP might requite a donation of around $250,000 in electronic speed controls or even more. That's a lot of money and commitment for a community project, or maybe not, sort of depends on how you look at the benefactors that fund so much of FIRST already. It also depends on how creative the community is with these things (consider the RepRap community as an example).

This being communicated, getting the electronic speed control approved does not require a donation anything near this scale. Personally I think it's quite practical to produce a near production quality prototype to get into the approved components list. This would probably be a dramatically smaller commitment. In that environment you can produce the product in smaller lots and more accurately produce only what you might get money for.

Producing a community oriented electronic speed control is not without precident see the OSMC:
http://www.robotpower.com/products/osmc_info.html

More importantly the beauty of setting our sights on merely getting the hardware approved for use in the manual means that as we develop the product's maturity we neither burden FIRST nor ourselves beyond what would be an otherwise ordinary business venture. If during the course of evaluation (be them for this year or later years) FIRST and ourselves discover the value of the project increases to vital to the FIRST mission statements we could then risk amped up production.

Again I am going to ignore that the Jaguar might be at the end of it's run here. This is about diversity in our approved components. This is not about rushing to fill the void that the Jaguar might leave. It's possible that the Jaguar might fall out of production this year and FIRST will leave it appoved for use (if you can find them to use). It's possible that FIRST can get the Jaguars and this item would be an alternative to the Jaguar. It is safe to say that we can use the FIRST RFQ for the Jaguar as a guideline to frame what FIRST sort of expects in various aspects.

Possibly all of the above, but most particularly separating the high power section from the control aspect, separating the communications aspect from the control processor if viable, and possibly even separating the indicator functions from the control aspect.

For example we could use a cheap module with a PIC at the heart to make a PWM speed control like the Victor when it's connected to the high power H-Bridge section. We could then make larger or smaller H-Bridge sections. We could also make reverse voltage protection modules for the H-Bridge section that could be used during initial setup and removed from the system during competition.

We could create another module with a TI Stellaris that can be connected to the same H-Bridge modules.

We could create another module with a Parallax Propeller that could also use those same H-Bridge modules.

We could create a 'common denominator' interface module for that H-Bridge section that could even enforce FIRST's requirements while allowing teams to produce their own control sections for the electronic speed control. It would encapsulate the current limiting and provide basically a TTL interface to the front end drivers within the 'common denominator' interface module.

We could make it possible to interface LCD modules to the control boards. Think of all the user interface possibilities this would open.

We could make it possible to interface storage modules. We could possibly put memory cards on the speed controls for data logging. We could even put static or dynamic RAM on a module with a possible battery backup (that would be much faster than a flash memory card logger).

The idea here is to encourage diversity without explosive costs. Obviously it's much more expensive to make 20 whole products than 20 parts of a product. Also in-line with the today's FIRST approved choices, if you nuke the high power section you could just replace that part of the modular system.

Re: TI and future Jaguars
 

Also a modular system reduces costs for the teams.

Originally the Victors were more expensive than the beige Jaguars.
The market pressure helped force down the price of the Victors.

However, that's not all there is to the analysis. The original beige Jaguars didn't have the RS232 bridge and that meant you had to get the 2CAN if you wanted to use that (at the time). So one can't ignore that with the beige Jaguars if your goal was to use CAN you had to fork over an extra few hundred dollars for the 2CAN.

In effect the 2CAN was a module of the CAN equipped network of beige Jaguars. You could simply not use CAN and the Jaguars would at the time be cheaper than the Victors (let's ignore other things about performance we know about the Jaguars with this analysis and stick to costs).

I am proposing a similar idea. If you want cheap versions you buy basically the PWM module and the power H-Bridge module. So let's try to keep that near the sub-$100 price range with an H-Bridge that's FIRST level of power handling.

If my team wants reverse voltage protection we fork over the extra cost.
If my team wants CAN we fork over the extra cost.

If my team buys the PWM modules this year with the power sections. Then next year decides to use CAN we can try to revolve a similar enough interface that we build a stock of parts over the course of successive competitions. So we might be able to remove the H-Bridge power sections from the PWM modules we bought the prior year and use them with the CAN modules we bought the next year.

This also saves money if there are unforeseen problems. Perhaps one model of one year's power sections has a problem. Maybe the next year you already have the CAN modules, but you replace the last year power sections with the design flaw with newer less problematic H-Bridge power modules.

In the worst case if the product is generally very well recieved it's possible there could be some economic bootstrapping for only new teams or new users to this product. For example last year only new teams got the newer cRIOs in their KOP. Perhaps there could be a discount for new users of the product to help them build up momentum. This might help drive the market acceptance of the product without risking a large donation of thousands of products into the FIRST KOP.

Re: TI and future Jaguars
 

I'm interested in being a part of this project. I have been thinking about doing it myself for months, but have been waiting until build season winds down before doing anything. For my sanity, I was thinking of targeting getting something working for the 2014 season, so life wouldn't have to be so rushed. But, that doesn't have to be the case since you want to push for next year.

I have already designed a custom motor controller, fabricated boards, and soldered them. This was very low quantity (5), but I have some good experience already from them. Mine are only rated to 5 amps, but the circuitry for an h-bridge is pretty much the same regardless of the amount of power that it will be rated for.

From my point of view, there are a couple of things that jump out at me as necessary features. The controllers need to be able to take anything we ask of them and keep on ticking. Victors currently do this, but the jaguars have trouble with it (First hand experience, multiple times, multiple ways). The switching frequency also needs to be significantly higher (jaguar range) to provide better control. The power circuitry for the uC on the controller also needs to drop out below 4.5 volts, unlike the current Jaguars. That has caused us many problems in the past.

They should also be a lot smaller than the current Jaguars, and the same size or smaller than the victors. I think it would be interesting to try to make them sealed and potentially passively cooled, but that may be dreaming.

I'm not sure that modular is that big a deal, personally. MOSFETS are pretty cheap. $5 per controller at low quantity for nice ones. A CAN transceiver is $1 at low quantity. All you need for CAN is a transceiver, a connector, and a uC that supports it. Most modern microcontrollers now should also be able to support running PID and friends without much worry.

If you decide to go further, please let me know. I know a couple of people who might also help out, at varying skill levels.

Well, off to work. We should meet up at CMP and talk.

Re: TI and future Jaguars
 

I intend to make a real effort to get this done. Several people are in contact with me about this effort now. It's still just starting but I'm committed to giving it some money, a little nurturing and some support from my personal resources. I don't know how far we'll get this year either, but I think we can produce results that are more tangible than just ideas by those deadlines.

We might need to reduce the feature set to make best use of the resources in the available time frame which is another reason I had proposed a modular system. There's nothing stopping us from making both a modular and non-modular system or only one of the other. There are certainly aspects of the non-modular system that could be valuable as well.

I'm going to try to essentially list features and ideas as this goes on. I think it might be wise to possibly enable a sort of voting process for features that lets people weigh in to some extent. That's a bit of a project so I wouldn't expect that immediately. The purpose would be to try to find the most important features we can deliver upon and then fit the resources towards that goal. It might be that people just really want mostly a CAN speed control like we've both been tinkering with and for PWM they prefer Victors.

I'm prepared to contribute to whatever direction the community wants to take it as long as we don't go totally out of the realm of practical.

Re: TI and future Jaguars
 

Wow, TI is bailing out!

So guys/gals, what we have here is an opportunity to create a best-of-breed motor controler for 12V 20-60A range. Are we sure that there is no commercial manufacturer out there that owns this segment?

If not, then this is an opportunity to own this segnment. I liked the Jaguar (with some mods to fix obvious issues). Is TI donating the Jag IP ? If so we could build on from that ...

I think we have plenty of collective "brains" to make a good job of this!

The volume of FIRST is small. But the 12/24V 20-60A segment has got to be huge...

If TI decided to bail out - we should first understand why they choese that path?

Cheers
Dean

Re: TI and future Jaguars
 

One thing that just occurred to me, is that just being FIRST approved would be a huge deal for a community effort that could make the whole need for manufacturers and support companies moot.

About six months ago, I heard a talk by the the principals behind http://diydrones.com. The gist of their operation is that they produce a completely open-sourced design for an autopilot and IMU for making RC planes and multi-copters into complete autonomous drones. Hardware, software, everything is open-source. They setup a small contract manufacturer for making boards in Tijuana, Mexico, but they provide the gerber plot files or other board masks if you want to make your own boards. Likewise, they sell kits that range from a bunch of components up to completely assembled boards. The cost of the finished product is directly related to how much work you want to make for yourself.

Back to the topic at hand, a community designed motor controller could follow the same model, at least if FIRST approves. Under the current rules, this controller would be considered a custom circuit. The open-source nature of the code and hardware schematics would make it available to all interested teams. A prototype reference design, only produced in small quantities would run afoul of the COTS rules, as currently implemented. If FIRST allowed board kits, produced on demand with a completely open design to be equivalent to COTS parts, then there may not be a problem.

-- Len

Re: TI and future Jaguars
 

I don't think so. Custom circuits may not directly control motors.

Re: TI and future Jaguars
 

I need to clarify part of my discussion with FIRST about this matter.

We can make a modular electronic speed control. We can make kits >HOWEVER<:

In order to be approved even for inclusion into the manual, we must have a process detailed that delivers assembled products to teams. That's the reason we must include the nearly production ready prototype (the rules about COTS circuit production are not applicable to this process...approval overrides them entirely).

So we can sell kits if we like, but we must be able to deliver assembled products to teams to meet demand so that the field of available hardware is even amongst the teams.

Not all teams have access to the hardware or skills to assemble an item such as this. We can't even assume that all teams have someone on them that can solder a through-hole PCB. Some of the items in the current KOP do require basic soldering skills but they are not vital to constructing a working robot. Approved electronic speed controls are vital to constructing a robot so we don't get that luxury.

We can make the units modular with connectors. We might even get FIRST to agree to make it so the connectors can be removed and replaced with wires from point to point (think 0.1" headers that aren't soldered in on delivery and can either be soldered in or you can use wire instead like the gyros and accelerometers). However, again, even if we sell kits as a side aspect they'll want the units almost entirely assembled. I don't think they'll accept a list of assembly houses that 'could' do the job either. They'll want as part of our business proposal a clean cut path to us being able to produce and deliver a few thousand units if the demand exists to pay for that. Keep in mind again, if the demand exists to pay for that it would mean that we have a few thousand monetary commitments for the product we wouldn't be donating a few thousand of the product (though at our option we could be discounting some of the costs).

So at very least we would have to commit sufficient assembly houses to being ready to assemble several thousand kits but with the potential of that not actually happening (or the cost). Also we would have to commit the assembly houses to lead times that are practical because if we are only included in the approved list, but not in the KOP, people will only find out and start ordering product the very first day of build season. I would think that any lead time over 2 weeks is asking a lot from FIRST and 3 weeks would be excessive.

One upside of inclusion in the KOP is that the lead times are for delivery between September and Halloween in October. Of course the risk with inclusion in the KOP is the risk we would have to entirely donate enough speed controls to give at least two to every team which is very costly. I should think it makes more sense to target inclusion as approved this year and hope that the product works out so well that FIRST decides that it's vital and then will commit money to help secure it for the KOP a following year. This way if it flops this year we expose ourselves to standard business losses.

Re: TI and future Jaguars
 

Your point is extremely valid. Only approved control devices may control motors (doesn't have to be an electronic speed control, could be a Spike under the right circumstances).

However, I propose that FIRST's primary concern with that rule is safety and to keep the playing field relatively equal.

I think we might be able to create a module with a power H-bridge at it's core that forms an approved 'front-end' for a custom circuit speed control.

Such a module would probably have to have some intelligence to it to implement current limits. To insure that timing of the signals doesn't short the H-bridge. To provide some way for the custom circuit beyond it to measure things like current and voltage at key locations without changing the H-bridge performance. Possibly even a way to indicate that things are overheating. Maybe some place to connect a fan for cooling (or not if you consider the way the fans work on the Victors).

If we did this I suspect we would be required to produce at least one 'interface module' that connects to this 'front-end' (as we don't have the custom circuit to give them) to demonstrate aspects of it's performance and equalize availability to all teams. What sort of interface on the 'interface module' is up to community discussion as well. I would speculate that CAN and PWM are the 2 front runners, but FIRST does have Ethernet, SPI and I2C on the existing control hardware and they would seem acceptable per the Jaguar RFQ we can use as a rough template.

It's not entirely clear to me currently that FIRST would say no to such an idea but I'll inquire further if it's something the community is seriously interested in.

The primary difference between a custom circuit connectable 'front-end' and a modular front end is specifically a question of whether you let people create the custom circuits or dictate functionality to them via the available selection of modules. There's no reason that a module couldn't be made for a modular front end to allow custom circuits and retain the existing selection of modules the community provided to FIRST to be approved along with the modular front end.

If someone made a custom circuit to connect to such a 'front-end' then that circuit would be impacted by the COTS rules. They wouldn't be able to use it the following year unchanged unless the COTS rules change or they provide it to be approved with the community work the following year. Then that newly accepted approved module would be subject to production requirements as well.

Current rules would impact your ability to directly alter the control of the electronic speed controls. So perhaps we could make the custom circuit module available and let FIRST decide during the approval process if they want to open that door. Keep in mind the rules aren't officially set until September. So if this custom circuit module existed and they want to allow that they could alter the rules to allow it.

I can diagram this out if someone wants me to do so. It might be easier to visualize drawn out.

Re: TI and future Jaguars
 

If you're calling the H-bridge the "front end" of the controller, I believe you misunderstand an important part of the approval process. The number one priority for approval is the ability for the control system to shut down all motors regardless of custom circuits or team-written software. The "approved front end" would have to be the part of the speed controller that connects to the rest of the control system. The approval requirements for the part that connects to the motors are going to be much less rigid.

Re: TI and future Jaguars
 

So you make the 'custom circuit module' (which is just one of the available interface modules), that connects between the H-bridge 'front-end' and the custom circuit also have a way to ensure that the control system can disable it regardless of the custom circuit connected to it. All you'd really need is a single digital output with the enable signal from somewhere on the control system and you could daisy-chain that signal from one 'custom circuit module' to the next (these robots are not that large).

Again, I don't envision it as 100% necessary to allow any custom circuits to be added after approval. I do think we can make a module for a modular unit's H-bridge 'front-end' that would allow it and be entirely subject to the approval of FIRST.

It's very appropriate to say that it's entirely up to FIRST if they want to open this door with a custom circuit connected to an approved 'front-end' through a 'custom circuit module'. So we need to be prepared to have it slammed shut if they don't like the idea. That's why we need to ship at least one module that is fixed to perform the interface function to that 'front-end'. That fixed module (PWM, CAN, SPI, I2C, etc) approved with the 'front-end' would be required to adhere to the field shut down while also performing whatever else it does (it wouldn't need the 'custom circuit module' at all so it's more integrated, lighter and smaller.)

Think of the 'custom circuit module' as an adapter between the H-bridge 'front-end' and some team's custom circuit, only it's intelligent and it can override your team's custom circuit entirely. In theory if your custom circuit was utterly perfect and you weren't using this at a FIRST event you'd be able to connect your custom circuit directly to the 'front-end' module and not need the 'custom circuit module' (it exists specifically to allow you to make a custom circuit that could fail and to retain control essential to FIRST during a competition).

Re: TI and future Jaguars
 

One feature I would really like to see in a FIRST approved electronic speed control is the ability to power the control assembly separate from the H-bridge assembly. This way if there's any doubt about the power quality feeding the control assembly you can provide it with a separate power supply to eliminate the possible issues from the motor operations.

This would also be handy if you wanted to log data in the control assembly memory for debugging.

Re: TI and future Jaguars
 

If a modular controller does get approved, I think an add-on module that basically allows you to use any motor as an rc servo would be awesome (rc as in PWM, not CAN).

Re: TI and future Jaguars
 

DC brush also called DC commutator induction motors at least (most every motor we use in FIRST whether or not we call it a CIM). Unlike AC brush or repulsion induction motors, brushless motors also called electronically commutated motors, stepper motors, AC motors, synchronous motors, pony motors (also part of a synchronous motor), pneumatic motors, hydraulic motors, heat engines (phase change, gas, liquid, electron, magnetic) which are different animals (and I'm sticking to things that don't run on ignition).

I think, but I could be wrong, that given the prevalence of PWM and CAN already in the FIRST systems that this project will eventually find itself supporting both one way or another. Might be 2 entirely separate electronic motor controls or the modular solution.

It would also very cool if we could use it to turn the CIM motors into servos to make CNC machines.

Re: TI and future Jaguars
 

I've separated the post because I changed topic:

One nice part about the modular solution is that we can keep reusing parts and if we want to include something complicated we can make that one part while leveraging the other. For example we could make a Jaguar compatible module with an electronically similar CAN interface as an interface to the high power module. We could also make a CAN module with a different interface then the Jaguar but still CAN. We could make a single PWM module that looks similar to a Victor, but can also have it's performance tweeked to have a wider response range or a different carrier frequency (one single PWM module different software personalities). If someone wanted to they could take an ARM9 and make a speed control with multiple high power modules (one interface multiple motors).

When it comes to the interface modules not connected to the 'custom circuit module' we'll need someway to insure that the code FIRST approves is actually within the core of that module. Currently FIRST achieves this because the Victor is one time programmable and the Jaguar has it's FIRST firmware effectively checked. We could make it so that FIRST can check the firmware with a tool quickly (in-circuit programming would allow a quick comparison when the interface is PWM, we already do this with the CAN to some extent). We can make it so that the modules approved by FIRST are one time programmable. Then again we could encase the programming circuit mechanically to make it tamper evident. In any case we'll probably be required to provide this protection to keep the FIRST playing field equal.

Re: TI and future Jaguars
 

In theory with a 'custom circuit module' you could connect the digital ports of the digital side car on the existing FIRST control system directly to the inputs. So if neither of the existing FIRST approved speed controls can handle 100% duty cycle we could make the 'custom circuit module' handle that by producing the maximum acceptable duty cycle instead of fully saturating the MOSFETs. We could also make the H-bridge module into a Spike relay like that.

We could give the 'custom circuit module' some other possible fixed pulse width settings as well. Those settings could be simply be turned on and off with a digital input. However, I'd like to avoid turning the 'custom circuit module' into an I2C/SPI/digital bus if possible. At some point it would defeat the purpose of a module for that specific purpose as well. Perhaps the fast, cheap and easy way to do this would be some solder pads close together on the 'custom circuit module' that represent binary. Someone could blob some solder over the pads to close them like they sometimes do on computer memory. Considering someone wouldn't have to use the 'custom circuit module' that might work out. I suppose you could also use dual row 0.1" header and just let someone solder a piece of wire between the pads for that header if they wished as well.

Re: TI and future Jaguars
 

Perhaps a command to checksum the installed firmware would be a good solution, rather than one-time write? I would hate to make the module useless if the communication protocol changed or a new feature was added next year. The new Jaguar firmware this year gave even the oldest ones an automatic voltage ramp capability that they did not posses before, as well as a more graceful re-enable after brown-out.

--Len

Re: TI and future Jaguars
 

I agree. I was thinking maybe we could sort of 'give' FIRST a connector of maybe 4 wires they could use as they like. Perhaps one is an enable/disable. Perhaps the rest are for some sort of communications. Perhaps we can use it for double duty as an in-circuit programming port as well but it'll need about 8-10 pins then. On the upside if FIRST can read every bit in the device then they can absolutely confirm the authorized firmware.

Maybe they need it or maybe they don't. So for example on the 'custom circuit module' they'll very probably need it for a safe enable/disable. However on a CAN enabled module they could sneak their checks in over the CAN so we don't always need more wire. I'm honestly not sure about the PWM (maybe they can sneak some one-wire over the power). Obviously CAN can be upgraded through the CAN bus but I'm not so sure you'd be able to firmware upgrade over just one-wire like you might be able to sneak with PWM.

Between that and the option to walk up and test the firmware checksum on the otherwise unused 4 wire connector I would think that's pretty good diligence to the concern.

(Could get crazy with it and actually make a inductive coupler and literally let them read through the case with the hand held tester.)

Still if maybe we pour some industrial epoxy on the unpopulated in-circuit programming port pads up to that section of the MCU that might just be enough. If someone chips or melts it off it's DQed for FIRST use (still would work fine though we'd give them the in-circuit components anyway, maybe provide a service where they can swap for a FIRST module and we can QA and recycle). If we did the epoxy perhaps we can even stick a stamp like wax or little paper disc with the FIRST logo into it before it cures. Course that won't help with a firmware upgrade unless you swap the modules.

Perhaps there's a way around the firmware upgrade when the in-circuit port is covered with the epoxy. It's possible with both AVR and PIC to use a boot loader. So basically most of the code can be upgraded through the 4 wire FIRST connector using some serial protocol and then the rest you'd need to remove the epoxy for. FIRST would probably be only able to verify the section of code you could write as well (because they couldn't access the ICSP port either) unless we put a bit of code in the bootloader to call into the uploaded code and then read back into the bootloader as well (sort of a section of code at an absolute memory address like a buffer overflow exploit). This has another added advantage because like this you probably won't be able to set the programming flags on the MCU. So they won't accidentally be able to put it in low voltage, watchdog, oscillator options or other modes that could induce hard to diagnose results via the FIRST port. If they really want to play with that they can just remove the epoxy.

Makes sense or is clear as mud?

You know if you make the 4 wire port for FIRST: enable/disable, RS232-RX, RS232-TX and ground. You could upgrade the firmware with a USB-RS232 adapter, an RS232 port or...if you're not using them for FIRST...you could put an RS422 adapter on them and program them from more than a thousand feet away if you like. In short that might be really handy to more than just FIRST (I have a picture in my head of a hundred of them connected to advertising or CNC machines with CAT5e split out to provide RS-485 for the control data and the 4 wires for the FIRST port...use the enable/disable for area wide emergency stop).

Re: TI and future Jaguars
 

I should also point out that if the community endeavors to make these things it's always smart to find applications for it besides just FIRST. The more of these things you make the lower the costs are likely to be and the more likely the longevity.

This is a public domain idea so hopefully if anyone is thinking about a trip down to a patent office someone will bother to look at this because it now belongs to everyone and anyone.

The only money that might be possible to make of this for a private business (outside of manufacturing it directly) would be to make a private module that does something the community doesn't have a module for. Then they've contributed to an open source project and let this serve as notice they will be required to disclose the use of the collective community work as part of their dealings.

Community in this case defined as anyone and everyone bundled into this project regardless of where it may communicate including Google Cache, TheWayBackMachine and these domains I bought in case we want them:

EMCPROJECT.COM
EMCPROJECT.NET
EMCPROJECT.ORG

EMCTURF.COM
EMCTURF.NET
EMCTURF.ORG

OPENEMC.COM
OPENEMC.NET
OPENEMC.ORG

I registered the alternate TLD (the last 3 letters) to prevent domain squatting.

Whether or not all the ideas I've presented I have an exclusivity on is unclear to me currently. However, I am considering my ideas openly donated this this particular project and the community involved with it.

Consider yourselves at the minimum GPLed :D.
http://en.wikipedia.org/wiki/Copyleft
http://en.wikipedia.org/wiki/Open-source_hardware
http://en.wikipedia.org/wiki/GNU_General_Public_License

Anyone with an objection to that particular license or whatever else about what I wrote in this post make it known please (let's not have some lurker suddenly selling this thing next month with a manual full of quotes from this topic then screaming we can't make them because they did first).

Also there's a Xen virtual private server (VPS) available to Linux host any or all of those domain if the community wishes it's currently empty. It's the same host that hosts: http://www.mort11.org/ It's my dime, however, if it goes that way assistance to maintain and develop is welcome always.

Re: TI and future Jaguars
 

Also I think we should deploy a unique identifier with these units. This way we can create a database and track any manufacturing issues that might run from a certain assembly house or supply of components.

We don't need to etch it into the PCBs. but maybe we can get a patch on the silk screen. Maybe put a sticker on the units. Maybe engrave the cases, the PCBs, or some epoxy with a CNC mill. Maybe hide it in the FIRST firmware.

I'm not sure if I want to put any company's name on this, unless the community elects to create an entity to promote it's interest. I don't need my company names on it.

Re: TI and future Jaguars
 

These notices probably won't be effective. American courts recognize the validity of terms of use imposed by a website upon its users, but are unlikely to give much weight to a third party (e.g. you) imposing terms. (In other words, posting this notice here probably won't hurt you, but neither will it help much. It might have an adverse effect if you imply something here that is contradicted by terms found elsewhere, and someone argues that they relied on your statements here.)

In patent terms, your declaration that this "now belongs to everyone and anyone" is pretty much ineffective. If someone takes what's been discussed here, adds something novel to it, and patents it, your declaration doesn't do any good. And if they don't add anything, then this thread represents prior art, and their claim is defeatable, declaration or not. You can't bind someone else with a unilateral declaration.

Similarly with copyright, you can't tell people that the GPL applies to what they publish on ChiefDelphi. All posts on ChiefDelphi should be assumed to be copyrighted by their authors.¹ You may be able to assert fair use or some other prerogative, but that depends on the circumstances of what you plan to do with it. Certainly don't expect that you could incorporate others' posts into the documentation that you distribute with the product. If you want to bind people to some licence, you have to have an agreement with them. It's not your forum, so you can't impose terms of use on the users.

¹ It's possible for a post to be ineligible for copyright, but that's rare with any substantial content.

Re: TI and future Jaguars
 

Thanks,

To be clear even if I can only speak for myself as I've given away a bunch of things in here, actually several of them quite specific to form and function, I'm quite fine with it more addressing my contribution to the project than anyone else at the moment.

If someone wants to try for a design patent using a modification of this idea then I wish them the best of luck. They don't have nearly enough to satisfy those requirements from what I've seen. I'd specifically like to avoid anyone claiming a utility patent on the ideas. I hope that I've conveyed that I have reduced my own copyright towards the community attempting to make this item. So that in effect I am agreeing not to pop up one day with a demand if you are a member of the community that supports this. Otherwise I perceive that by describing my ideas in such detail I risk making the idea less and less doable for the community.

I've had people steal stuff from me before in forums on the Internet, then run down and patent them, and usually what happens is sooner or later I show up with the posts showing the dates as prior art and they decide they'll not enforce against me if I would kindly avoid taking apart their patent. It's surprising actually how many times their attorneys tell me that no one at all comes forward and challenges the patent during the initial time frames. So you end up with these patents that cover basically the entire kitchen and the sink that some patent examiner doesn't think all the way through. Someone may have a patent that directly incorporates something from my publicly listed idea that a patent examiner completely ignored (probably lack of experience in something exceedingly technical). Those would be those patents the patent trolls love...you know...it's a patent that means their IP is 'all cell phones ever created' because it's far too broad.

However, you bring up a good point perhaps we should consider moving the venue for the legal implications beyond myself and make the other forum private behind a login that indicates acceptance of this license. I should think beyond that we would need to trade paper.

More precisely beyond the legal specifics I was concerned that someone might utterly object to the licensing principal itself with regards to the project. Not just my legal hackery :yikes:. So let's hope that they are seeing this very public exchange as fair warning as to possible legal implications of moving to our own site.

Any specific concerns you can offer with the use of GPL in this regard?

To be additionally clear, I am not suggesting I'm using anyone's posts in my documentation. I am suggesting that I worry that someone else could do that.

Re: TI and future Jaguars
 

No problem; I just wanted to clarify that the scope of the protections were what you expected.

It's a little bit clumsy, because it requires a copy of the licence be transmitted along with the copyrighted material. Not a big deal if the works are large; more of a problem when you're distributing small works individually.

The GPL is also quite software-focused, so some of the terms are a little strange in the context of hardware (or hardware designs), or artistic/non-technical works. I haven't reviewed it in detail, but I suspect it should work fine for this purpose nevertheless.

The Creative Commons licences don't have those restrictions/optimizations. They'd probably be fine too.

Re: TI and future Jaguars
 

Back to the next MC topic.

I think the only realistic way to make this work is if some "large" vendor steps in and manufactures this product as a charitable donation to FIRST.

Realistically there is no way a community effort can support KOP/FIRST needs. Remember kids need to use these products, we cannot have a gazillion of modules/combinations. Today we have two: a Vic or a Jag and just these two is confusing everybody and creating a huge debate :-)

Vics and Jags are sub $100. There is no way one can build this for less unless you are a large volume manufacturer - way larger than the FIRST market.

Vics and (to a much lesser extent) Jags have had multiple generations of fine tuning. If we design our onw in the next few months - will it work just fine ???

I think some vendor needs their arm twisted to take the donated IP of the Jag and improve on it in an incremental fashion. We've all witnessed some really good suggestins on how improve a Jag. With some of these implemented I think the new Jag will be a fine product for FIRST.

This is not rocket science and it doesn't evolve much anymore, so we just need a stable product and ride down the cost curve asap. I can imagine the New-Jag in a Vic format for < $50.

What our community effort can do is to act as an advisor to the benevolent manufacturer. Maybe FIRST can orchestrate this and there ought to be prizes and recognition for those that contribute a lot.

Dean

Re: TI and future Jaguars
 

The cRIO control system and the KOP themselves are 2 examples that literally defy that point. The cRIO alone offers more variations.

Using this logic why not manufacture an integrated control system why commit to making anyone think about the details?

FIRST has a commitment to diversity in their kit of parts they made that clear in my discussion with them. To me that means that they support the idea of a community motor control even if they can source the Jaguar still.

Not sure how that works. You make hundreds of thousands of a single iteration product to leverage what market? How many do you make for what year and if TI could sell these why didn't they? If the problems were all software their non-FIRST firmware was utterly open so why didn't it turn big money? Also if the TI Stellaris is selling so well why the requirement to use it in the FIRST RFQ?

More importantly if the pockets on that side are so deep who insures that they don't reduce the options down to their gospel and lock out the other vendors? Please review the RFQ there's a quite specific note about that towards the end obviously because often such deep pocket interests don't have an interest in co-existence but market dominance.

Something like earlier you wrote:
Depends on your goals and the way it's managed. I have little doubt we can build a power H-bridge module properly. I have little doubt we can build a functional PWM module. I have little doubt we can build a CAN module. As others and myself have stated we already built designs for a CAN enabled motor control. Mine are modular already to a point and for several good technical reasons including insuring that the power and ground planes of the control section are not the power and ground planes of the H-bridge section. Years of experience have taught me the issues of that...I don't buy into the whole if we only are very careful in the layout nothing could go wrong.

I have some doubts we can build a perfectly operational PID implementation unless we mimic the ideal PID loop of the Jaguar. However, we can not ignore that the ideal PID loop of the Jaguar (even when it's implemented properly) is not the only form of PID loop and it doesn't work perfectly in all applications. I'm not sure I want to do what the Jaguar PR does in effect and claim that we are providing you 'the PID loop' of choice. As many have found it's just not adequate in many situations.

I already stated clearly that as I don't feel this is designed to force the market closed on the Jaguar, there is no absolute need to finish before next season it would be fine to finish the season after. As far as bugs, you will quickly find that you have bigger problems then you think with the Jaguar no matter how deep your pockets. Let the community project worry about what it needs to worry about, we already saw what big companies did with the Jaguar who is to say what the community project does...it's without precident for an electronic motor control (but AndyMark and others prove that it can be done as a business).

The Jaguars made little effort to show how they fit into the target market. A fair representation of their upsides and downsides was left to the community. To some extent telling people to read the manual is a learning exercise. When it exceeds the content of the manual then it's reverse engineering with no evidence you can forward port it to the product. If you argue that you support reverse engineering you're defying the even playing field goals of FIRST. Many teams can't even solder. Now you ask them to troubleshoot this? That's one of the reasons more veteran teams use the Jaguars with CAN than the newer teams.

The community project isn't going to be locked out of testing anything, to changing anything, the quantities will be smaller and every step of the design process there to review. A very large company generally does not have any interest in finding faults in their very expensive by quantity product. They also have little interest in creating diversity. If you knock out a few hundred thousand of those Jaguar PCBs right now I'm quite sure you'll be making an error if your goal is to remove the problems.

On the plus side if you provide the Jaguar to FIRST you only reduce the initial burden on the community project.

I support this. If you can find someone and a way to do that feel free. You have the RFQ and obviously the interest of FIRST because they published it. I made it extremely clear earlier in this topic that whether or not they fulfill that RFQ I am doing this as a community effort. I feel I also made that extremely clear to FIRST and the people I spoke to were thrilled with the idea.

My goal isn't to harm the Jaguar. My goal is to do something I feel is very important to the longevity of FIRST. To find a way to navigate to community solutions from FIRST itself and put those up against the other options. What I have to wonder is: why would you even need the community if all the bugs are well known already here? Why would the massively deep pocketed company not just offer it's service to FIRST, absorb, collate the information and manufacture? What does the community need to do if the bugs are already so fleshed out?

Feel free to find vendor that can hit that price point. I'll be very happy to produce a electronic motor control in the sub-$100 range with specific options. I think a community such as FIRST will value it more than a few bucks here and there. The mere costs of single competition, the costs of the cRIO, the costs of the network cameras. If you note the FIRST community often makes decisions that aren't based on the price point. Though I welcome a solution in that price range if it can be achieved to help those teams with a lower budget. The lower you make your price the easier you make it on the community project because the less demand for the product to fill the lowest price point. In effect, we can charge reasonably more because the Jaguar already has earned itself a reputation and more importantly it will cost you *much* more to compete on feature than a community project.

Contact them you have the RFQ. Only FIRST knows what FIRST will approve for that sort of thing. However I suspect you'll have to get the funds for those prizes from the manufacturer.

You might even get some flexibility from FIRST about that RFQ's demands. Course you've sort of stuck them with the TI Stellaris, the cases, and to some extents the current limits. Wait why did the last benevolent manufacturer leave behind a requirement in a FIRST RFQ?

Re: TI and future Jaguars
 

Here's what's not in the interest of a large company selling the Jaguar:

To teach sufficient process to compete with them.
To explore prototyping.
To teach electronics.

A community project touches on all of those points in a way that would be almost financially irresponsible to a large company. Sure even the community project won't be a level playing field for you if you can't solder. However, it won't also encourage those who can solder to sit around slapping the only choice on the robot because they are not welcome to do otherwise or you might have dusty stock.

The fact that the current 2 choice community feels the need to polarize on a choice means that too many people feel they can find sufficient weakness in the Jaguar product to advocate over it what is basically a large RC car speed control. The core reason to replicate the Jaguar, cause it's already here and you don't have to think too much (in fact if the community does the reverse engineering and fixing a very few people will have to think cause only they will get the prize).

What's the prize of deciding what you want to learn worth?

To me it's worth getting the community project going even if it's not big business. No one can ignore that I've already started putting my money where my mouth is.

If the Jaguar is worth so much to those who walk that path don't tear us down when *we* are part of the target market, just go prove that's it's so easy for the big business and do it. Maybe tearing us down is easier than getting big business to do this?

Re: TI and future Jaguars
 

Honestly,

As a team we'd just want a speed controller that can do this:

-Something incredibly robust
-Small
-Doesnt' Break
-Nice linear control like the jags.
-Doesn't break!
-Sealed!

Somewhere between $70 - 100 would be great. Cheaper it is, the more we'd buy most likely.

-RC

Re: TI and future Jaguars
 

One of the motor controllers that I have used in the past had a language on it that you interfaced to it with. This allowed you to do the basic things like set voltage and stuff, or to do the crazy stuff like custom control loops. The language was basic-like, and pretty simple. This makes it so teams could do whatever they want at the lowest level (1khz custom control loop ftw!), but the kill signal would always be respected.

Re: TI and future Jaguars
 

Currently I think, as was touched on above, that a FIRST speed control should approximate the design of the Victor in the sense that the body of the speed control should fit under the fan with perhaps the exception of I/O and power connctions which, like the Victor, sit beyond that perimeter.

I was thinking that the power board would be situated directly below the fan along with, at minimum, that board's power connection (high current so less connectors and trace length the better) sitting beyond the fan's perimeter when looking straight down at that fan.

I was thinking to put the control or 'interface' module directly below that power module.

If you were using the 'custom circuit interface' I was thinking that your custom circuit would be the lowest level of the stack.

For prototyping one could use ribbon cables to essentially unstack the modules horizontally.

The fan would blow directly on the parts most likely to generate heat.

If necessary a much smaller secondary fan could be put on the side of the stack to move air between all the modules.

I was also thinking that a piece of cold laminated aluminum foil or copper foil could be stuck between each module as an RF barrier if one desired. That item being light, somewhat rigid and most importantly with a surface that's not conductive. It's like the foil in an Apple computer it could be sort of folded to something like a shield. This would also help with swarf besides sealing all the boards and possibly putting it all in a suitable box.

I realize that the the cheaper the unit is, the more would be bought, but Dsirovica is correct above that a community project in the early stages will be cash strapped without benevelent benefactors of faith. I can throw around a few thousand dollars out my pocket. However our initial bottom line ability to ram down the price will depend on whether the near production prototypes make FIRST drool during the approval and whether someone else comes along and opens their pockets as well. I hope that as things advance and we crystalize on basic business functions and tangible work; we acquire not just community hands but some community contributors. I can respect deeply that as of this moment the economy is a very tough place for seed money which is why I pulled out my wallet and my production resources and offered to help. I have faith in you all to deliver...if not this year...then perhaps next.

Re: TI and future Jaguars
 

Easily achieved. If you use the module design initially one could make that by making a small rough PCB board with any BASIC Stamp like module and connecting it at the bottom of the stack to the 'custom circuit module' then putting the high power H-bridge module at the top.

You could decide the interface to your custom circuit. Perhaps you run some digital side car digital I/O to it, perhaps some PWM, perhaps I2C or SPI or a combination. As the BASIC language process would be entirely at your choice initially you could literally use a Parallax BASIC Stamp 2 (pBASIC) or for other flavors Parallax Javelin (Java), Parallax Propeller Spin Stamp (Assembly, Spin), Digi Rabbit Core (Dynamic C, plug your speed control in your Ethernet if they let you)...etc to infinity and restricted only by other FIRST rules for custom circuits for whatever year is in question.

The first year you use that your custom circuit (assuming FIRST approved the 'custom circuit module') would receive the FIRST level restrictions from the 'custom circuit module' (IE: enable/disable, current limits, etc). Then if wanted you could add the restrictions from the 'custom circuit module' yourself (with community help if you wish) to your custom circuit the next year and hand in your new module design to FIRST to approve for general use without the 'custom circuit module'. Keeping in mind that your new module will have to reach at least some production volume once FIRST approves it.

In this manner we provide a great deal of diversity. Assuming FIRST approved the 'custom circuit module' a team could make just enough custom circuits for themselves one year. Then if they don't like their end product they can toss it away the next year. If they love it they polish it up and let FIRST decide on it's acceptability as a module without the 'custom circuit module'.

I'm not sure how many of something like that you'd need to sell but that's also in your favor. You let the community handle the heavy lifting with all the other modules and you only need to produce enough to handle those people that really love your idea. If your custom circuit turns out to be fantastic I'm sure the community will advocate assisting handling the mass in-flux of orders to allow it to thrive. So you might need to make 10 or 25 or you might get a lot of hands to help you make hundreds (if all you needed was a few I'd help you make them).

Additionally at the moment there are rules in FIRST about reusing custom circuits the next year. So please be aware that if FIRST approves such a 'custom circuit module' so you could do this, unless FIRST alters the COTS rules, you'll have to either get your design approved to use it the next year or alter it sufficiently. Let's cross one bridge at a time (not all 3 LOL) and see if FIRST is willing to open this door. I suppose if FIRST approves the 'custom circuit module' they might tweak the rules if you make your custom circuit entirely public for all teams to use as a design, then you could just give it to the community and maybe use it over and over with the 'custom circuit module' but there is much speculation involved here. I'm just giving you my idea of how this could work out.

Just remember that FIRST is generally concerned that anything we create that's heavy on the electronics engineering is not just limited to a few teams with adequate expertise and resources. That would create an uneven playing field. To some extent the existing custom circuit rules risk an uneven playing field for basically one year at this time. So if FIRST allows you to reuse your custom circuit module as it was gifted to the public they risk that the other teams might not be able to actually assemble it themselves. Obviously a touchy problem.

Re: TI and future Jaguars
 

It occured to me that you might have meant that it had a very simple proprietary motion control language.

My previous statement in reply remains the same. Except you might be able to entirely skip the custom circuit if you keep it simple.

What would need to be done is pick what processor or MCU that langauge would be written for, then create a 'custom control module' or go directly to the interface module design phase with the necessary hardware and a suitable interface(s).

I would think that you'd need to run the language as an interpreter, reading the commands sent to it from the interface, parsing them, then performing the desired actions. Like a shell script (in point of fact if you used a 68k compatible or ARM CPU you could run Linux or ucLinux). This can be done in something as simple as a PIC 16F628 or the Atmel AVR AT90S2313.

Obviously this involves writing basically a new language unless you have specific information about the former language's structure.

At the most simplistic you could create commands like:

SET (BRAKING, RPM, VOLTAGE, CURRENT, PID, POSITION, DIRECTION, LIMITS, VARIABLE, OUTPUT)
READ (ENCODER, SWITCH, VARIABLE) - Note that the difference is one has units and one is raw
OVERRIDE (LIMIT, ENCODER)
RESET
GROUP (SWITCH, ENCODER, MOTOR, CODE BLOCK)
WRITE (CODE BLOCK, STATE, ALL)
UNGROUP (SWITCH, ENCODER, MOTOR)
RUN (CODE BLOCK, BACKGROUND, FOREGROUND)
DEFINE (CODE BLOCK) - Use a start and end delimiter to stream reset of command set
END (CODE BLOCK) - Ends a running code block
TRIGGER (#, CODE BLOCK) - Could trigger on a memory mapped input, encoder reading or event like reset

(20 minutes of dreaming up a new language of commands...200 hours of actually writing it...LOL)
Then you could instruct the system with those commands:
...Set it up so that an actuator performs an action on a trigger on it's own.
...Set it up so that an actuator just goes were you tell it at a fixed speed or with braking, or with a PID control).
...Even create a background process to watch an encoder while while you do other things.

Someone will quickly note that that language lacks decision making and loops. Not a problem because the interpreter is really more a command interpreter like a shell. Inside the processing it defines the common recipes for the loops you would otherwise define in a programming language.

That's quite a project but I wouldn't want to force everyone to use it. In an industrial setting it would be handy, but in an educational setting it would sort of reduce the amount of thought involved. Still obviously it's within the practical capability to achieve it. In some ways that would drag a lot of the functionality of the cRIO into this system.

Re: TI and future Jaguars
 

After some lunch I realized I should probably clarify why the motion control command interpreter I outlined above would have to have a module at all.

In theory with the open (non-FIRST) firmware for the Jaguar you could already implement that.

In theory you could write a library, a software module, a component for LabView, or even a converter for the command line that takes that more stylistically familar lanaguage and shorthand for grand motion control functions and breaks it down to something more practical to implement in existing languages.

In theory to conserve memory on the module you could also do what Java and Parallax pBASIC interpreters do and compile what you write down to simplier more compact form (byte-code) while checking it for errors. You could then upload that to the module.

Here's the thing, you could essentially take an existing CAN module for example (assuming it already existed any place accept our heads) and change out the software within it for this motion control language. Just like you could do with the Jaguar (in fact a great deal of what I described above is already in the Jaguar...so it's a short reach...the Jaguar is just a little less developed in language right now).

The problem that will crop up is that FIRST is going to want to approve something so they'll need to see something tangible in operation. If you create something for one or many existing modules on a PC and it doesn't change the possibly already approved software in that module then it shouldn't be a problem. However, if you alter the module's software you the open proverbial can of worms.

If you tried to create a piece of alternate firmware for existing modules you'd create quite a few new things FIRST would have to evaluate and possibly that would mean dragging you as the motion control langauge developer into the module designer's approval process. That's a lot more variable concerns for something otherwise simple.

So the fastest way I can figure you'd break that self-feeding complexity would be to make a module that is the exact hardware you desire so you don't have to worry about someone else using different processors or MCU and then you having to port your work to their changes and then getting everything approved again.

It's a lot more direct if you simply absorb someone's module design or make one yourself and bundle it with your motion control language (in programming terms fork their project). If you absorbed an existing module they are free to develop as they like and even change hardware. You are free to develop as you like and even tinker with the hardware. Unless of course FIRST will award you approval process coopertition points. :D

Re: TI and future Jaguars
 

Lets see if we can agree on a few observations (I don’t know if they are correct):
1. The volume of FIRST is too low for healthy commercial interest.
2. The motor controller for FIRST has no other significant market.

If #1 & #2 are true then we are stuck and we have to beg a vendor for charity.

I am not sure (though this is not my field) that #2 needs to be true. Maybe it is true for the Jags but the Victors seems are used elsewhere too. So maybe what we need to do is to find something that is close (eg. Victor) and ask/beg that vendor to augment their controller for FIRST and hopefully encourage them to find other applications too. Who makes the Vics – maybe we can ask them – I read somewhere FIRST consumed 60K Vics so far. However, my team and many others it seems burn a few Vics every season so there is probably no incentive to change the design 

I think Techhelpbb said that in industry people don’t use generic speed controller like a Jaguar but custom design things for each application. I wonder why that is, and maybe a generic speed controller needs to hit a price point for that to change?

Dean

Re: TI and future Jaguars
 

I think you are correct, otherwise TI would not be willing to essentially donate an entire business unit, they just recently acquired, to FIRST. I understand that the reason they acquired Luminary was likely for other parts of the operation and they got "stuck" with Jaguar business unit. However even if they didn't want it why wouldn't they try to sell that business unit, or continue the existing contract, they inherited, to supply FIRST till it ends then not renew it? The logical answer is that it looses too much money as is and they determined that selling that business unit would not bring much in today's market if they could even find a suitor.

Re: TI and future Jaguars
 

Let me be clear about what I'm really saying. If one wants to sell a lot of something you must be fast enough on your feet to realize just how to make it appealing enough to the situations where it might not be a perfect fit and how to make it fit well enough in the few tough situations where it must be a fit (unless you have a captive market or you don't mind lying possibly a lot).

Take the PC. Using a full blown PC for a FIRST robot is entirely possible. FIRST chooses to use a PLC because it's really more designed for industrial setting (so it's vocationally intelligent for future training) and because they don't have to narrow the hardware down so they get more predictable platforms. However quite obviously a massive number of PCs have been sold into lots of non-FIRST applications where maybe they aren't a perfect fit, but with a few alterations they'll work out. That's how you sell stuff by the truck and train load.

A FIRST specific speed control might be a perfect fit for FIRST (and in the case of the Jaguar it's not even really that because it's specifications limit it's usage to not every system generally) but a terrible fit for a linear positioning company like Intelligent Actuator.

You might be able to sell someone a Jaguar to build a CNC machine with CIMs. However, you'd need to make something to convert from G-code to the different instruction context of the Jaguar.

The Victor is basically a great big RC car speed control. That means it automatically taps the hobby market which is massively familiar with PWM and has an existing supply of PWM equipped control systems (some of which cost a sizable amount of money). The Victor works well for BattleBots where the idea is to scale up the basic RC car, while retaining similar designs. FIRST differs from BattleBots in the educational motivation (we don't just need quick and dirty robots to wreck, we need to be able to provide a positive educational experience).

The Victor isn't an ideal fit for FIRST either. It's advantage in FIRST starts with the fact that I suspect AndyMark tested all it's gear boxes with Victors driving the CIMs. It's really easy to build a drive train with AndyMark gear boxes that will hit the overloads on the Jaguar so the Victor often wins that contest of market by legacy placement and appeal (the 'older timers' saying: "We always did it with Victors and it worked so why do I need these Jaguars that seem to be a problem?"). Then there's the fact that the Victors are so simple and their reset cycle so graceful that most people didn't realize the Victors were reseting on them from overload for some time. Put a Jaguar in there where the monitoring of the system is much more evolved and suddenly you see the failure you never noticed before. Again lucky for FIRST our usage is infrequent or I suspect we'd destroy a lot more Victors with some of these robot designs. Then there's the lack of sensor inputs which is something the Victor design doesn't include because you'd have to decide what extra parts you want to stick users with that just want a big RC car speed control. The lack of sensors is a problem if you're trying to intimately control that motor through that Victor, obviously we work it out, but we pay for it with direct control and responsiveness.

The point I'm making? I am picking the one common demoninator that you've repeatedly noted in your comments to this topic. The FIRST speed control fits a specific power range of a specific style of electric motor. By putting the part of the electronic speed control that dictates the power it handles into a common module, mostly all by itself, we create a single part essentially common to almost all users in all fields. There is your 'big seller'. Everything beyond that? Everything beyond that in the interface modules and the 'custom circuit module' is up for grabs depending on what your priority is as the end user. If you're FIRST you want your limits imposed. If you're not FIRST you probably need almost the same circuit minus those FIRST limits. If you're building an RC car you probably don't need limit switches and encoders you just need PWM. If you're building a CNC servo controller you probably do need encoders and/or limit switches. If you're FIRST putting those sensors on that interface offloads your work load on the control system whether it's the cRIO, the IFI system or the original Parallax BASIC Stamp 2 system.

Heck you don't even need to limit yourself to just the power requirements of FIRST. You can make a high power 'front-end' module that acccepts an interface we made for one thing, but can drive a 48V 1HP or larger commutated induction motor with a few minor tweeks. Do you want to control the drive motor on a golf cart with the same interface module you used in FIRST...you certainly could! However, that size 'front-end' for this electronic motor control would be physically larger and need more cooling than a Victor that's for sure.

You are trying to find the business case for a FIRST product, but what I've actually described in this topic was a electronic motor controller with enough diversity in design to have multiple business cases in a variety of markets (I thought of more than 20 to date in other private conversations about this).

So if you're talking about tossing some funding and resources at something that in production might expand well beyond FIRST might I suggest that when the community project starts churning prototype hardware you consider helping us getting some donated funding? Consider that effectively you'd be getting in on the ground floor of a virtual startup that the community members basically boot strapped. Just keep in mind with that donation we would be churning community hardware that feeds diversity and creates expertise that other businesses could create commercial parts to. It's like donating money to MySQL, Linux or obviously FIRST. It's a donation that might pay back to a commercial enterpise it's weight in gold.

Re: TI and future Jaguars
 

That is definitely an issue. Though once again, you could do what they did for the Jaguars, and add it in after a year as a firmware upgrade. And who says that the interpreter has to be fancy or anything? Forth, basic, scheme(!)... There has to be a simple interpreter already out there. Scheme would be really easy to write, too. There is very little to no syntax. Or something like Logo, or ...

One of the really valuable parts of having a control language is that you can run things that matter and are custom at very high frequencies (1khz), and it can be sandboxed so that FIRST is always in control. Without having to mess with extra hardware which adds significant development and manufacturing challenges.

Re: TI and future Jaguars
 

I'm not saying it can't be done. With enough cooperation between the module development before the language and the people that develop the alternate firmware they add to the interface module later in the lifecycle of the module it could be done. I just encourage you to consider that you'd be linking the life of your additional project to the lifecycle of the interface module you added it to.

For example of what concerns me:

Let's say we have a CAN equipped interface module. It's appoved and we as a community have a supply process to satisfy FIRST as part of the approval. You decide to work with the people that made that CAN equipped interface module to make your custom firmware. Great, no problem yet. Then the next year you help the CAN equipped group offer your extra firmware for the same CAN equipped interface module for FIRST to review and approve. Still no issue.

Let's say the next year the folks making that CAN equipped interface module decide they need to alter that hardware in such a way that it still performs their original specifications, but it tweaks your additional firmware. Well now you'd have to play along with their change. You may have the language stable and working and suddenly you've got to change it because they decided to change.

I propose to fork the project to avoid you dragging each other with restrictions or schedules. You can certainly absorb their module as it already exists. So just make your firmware and make it work then take it for approval. If that module project decides to make hardware changes later you can just keep making the original module with the same community resources. The community shouldn't look at it like being asked to make old hardware for the original project. They should look at it as making the hardware to support your language. Nothing would stop you later from later making the upgrade to match the original interface module again. However, you could each operate freely of each other in the mean time.

It's mostly just an issue of logistics. Not a way to make the language developer stuck to making hardware. I suspect most interface modules will rely on community resources for manufacturing anyway so I'm not sure it's much impact except to change some part numbers.

Outside of those mostly bureaucratic concerns I think it's a valuable idea for the same reasons you've stated.

Re: TI and future Jaguars
 

Generally speaking:

I should think that most production manufacturing for a project like this is going to be done by community resources. I don't think many teams that might contribute to the project are going to want to turn production quantites of units. I think it's important to insure such a project's commitment to FIRST that whatever we make that is approved by FIRST is made from the greater pool of resources.

Otherwise I worry that we'd limit contribution because someone that might offer up a design would worry they'd have to carry the burden themselves. We might also make FIRST uncomfortable that there isn't really a commitment to deliver if the demand of quantity is there.

From a business educational perspective probably the most education for the students comes up to the certain point of commitment and then beyond that it's repetition and distracting. So it'll be important that the community have the resources to handle those logistics. Probably need to compile lists of friendly assembly houses. Lists of friendly suppliers. Lists of people willing to donate production resources like myself.

Re: TI and future Jaguars
 

All of these features sound cool, but in my opinion before any new feature is introduced we need to really take a stab at making the current offerings more robust. Jaguar failures have bit a number of teams I have associations with and probably many others.

Here's what another speed controller would need to do to make the Cheesy Poofs stop using Victors:
- Proven reliability
- A unit just as small, if not smaller.
- The ability to deliver ridiculously high amounts of current and withstand low voltages. We have popped the main breaker before our Victors stop working.
- Faster, asynchronous motor drive PWM (I hate the sound of crunching CIMs)
- A closed case would be nice. Metal chips are abundant.
- Proven reliability
- Proven reliability
... Repeat 100 times ...
- Proven reliability

As far as control signals go, CAN is a "nice to have". The first rev of CAN in FRC had some major bugs and for me the first impression there was enough to write it off. On top of that, these interfaces are very highly abstracted out at the software level. I don't see how a student benefits any more from writing (-1,1) into an abstracted CAN interface than they do with an abstracted PWM interface.

Re: TI and future Jaguars
 

As to everything else you ask for it's all quite reasonable and I feel quite doable. Perhaps not in the first prototype PCB but I'd like to think we test till we are sure that reliability is the prime concern.

One thing that does concern me personally is the issue of size. I've used the horizontal surface footprint of the Victors as sort of my idea of a guide. So I want to keep that surface foot print as much as possible. My idea of stacking modules would risk increasing the height from the top surface of the fan to the surface the unit sits on. To me, increasing that height in some cases by 0.5" doesn't seem a lot to ask. I may be wrong and others have a different opinion.

You are correct that when one merely uses the CAN bus like a glorified PWM that the amount of information basically communicated is similar. The real advantage of CAN for communications would come when you can really use the sensors, the fault detections and possibly a motion control environment on the electronic motor control. Then PWM and CAN are quite different. PWM doesn't give you a lot of choices to even upgrade the electronic motor control firmware through it.

Also there's a potential difference in performance. PWM needs to transit several cycles for a PWM interfaced electronic motor control to operate. It's possible that a single byte at high speed communicated down a CAN bus could start a series of events that's intricate on the electronic motor control.

Obviously any general purpose communications bus has an advantage of flexibility over strait binary I/O on a single wire. Whether that binary I/O happens to look like PWM or whether it's a classic digital I/O port ON/OFF state from the FIRST digital sidecar.

I seriously take your concerns about reliability to heart. I hope that the community will police itself about quality and not merely rely on FIRST approval as the cardinal level of achievement. Many of us are professional engineers here and I'm sure we know how to address this responsibility and can fix issues that effect it.

To help insure this I've been working on a website idea where anyone with a quality issue can report it without necessarily having to return the item. Obviously some errors will get induced with reporting like that, but I think we can statistically pull the information about any quality issues out of the noise. With all the flexibility it's important to me that if we have a bad module we know where they are, we see any reports of it quickly and hopefully can offer quick response to deal with it. I don't want to hide from any issues I want to deal with them straight on till the thing is very hard to break.

Also as I'm putting my personal money into this, if my choice were to ship something marginally unreliable for next year or wait till the year after. Even if it cost me more time and money I put reliability first when it comes to something like this. I won't let this be a rush. There's no need. There's still plenty of existing Jaguar stock at DigiKey and floating between teams that if we wait till next year for approval it shouldn't be a crushing problem.

Re: TI and future Jaguars
 

Alternate website work update:

I've created a virtual hosting environment using WebMin and VirtualMin on my VPS running CentOS 6.2 (Linux).

As stated before I registered those 9 domains.

I've pointed the DNS and it's propogated for those domains from the registrar to a the DNS host and then to the static IP of my VPS.

I have done some shopping for suitable SSL certificates in case we want to create some public, some semi-public and some private forums. Also in case we want to use it for securing e-mail I can host on that site. It looks like a good place to start would be a wildcard SSL certificate from Comodo as it'll set me back $89 per year to secure one domain with lots of sub-domain choices.

I'm not sure if the community has a favorite in the domain names I offered before (post #35, page #3). If anyone has any preference feel free to speak up. What I think is most cost effective is to pick one of the 9 root domain names and host the website with that as the primary domain then use redirects to push traffic from the others to that domain. Then we only need to secure one root domain for SSL. We could also put other things at the other domains that don't need to be secured. I'd hate to spend $900 on SSL.

I also think the wildcard SSL is a good idea if we start using some mobile devices because sometimes you need a WAP version of something or a SOAP application.

Input or some help with this is always welcome.

Re: TI and future Jaguars
 

Github. It has a private mode for designated contributors, public wiki, and an issue reporting system. Also, it's free.

Re: TI and future Jaguars
 

I'm not so worried about the money at this point. I budgeted several thousand dollars of my money to work into this effort regardless of the website maintenace costs. I don't mind bearing that hosting cost for a few years at least and I'm not looking to exert any sort of ownership rights for doing it.

I'm even okay with subfolder hosting for other projects or community members if it's wanted so people can put up their own content. Might be able to further the usage of the root domain's SSL certificate like that.

I'll give Github another look as I recall when I helped start another project there was monthly fee for it. I'm not sure how the licensing issues and other issues might work into their model (see earlier in the topic).

This said hosting this ourselves most of these features we can get from other open source projects. Plus we'll have utter control over the bandwidth, the storage, the databases and whatever web applications we put into the space. Of course many projects use SourceForge but retain their own hosting as well. I do worry, however, that often times when a project uses both SourceForge and their own hosting it's hard to know how the site operations prioritize the usage of the resources and search engine hits can get confusing.

Is there a particular specific function of the services of Github that you think is unique and would be important to this project?

Re: TI and future Jaguars
 

World was fun! Must have walked several miles back and forth between the arena and the pits – really unnecessary people flow problems created by the staff.

I talked to TI at the event. Basically they want out f the Jag business due to its lack of business. The are donating everything except their silicon (Stellaris and a few other chips on-board). They are aware of current issues but clearly have no motivation to fix anything.

They also don't see who would want this business with the exception of the manufacturer if Victors whom they think/hope will bid on the RFP. They did not think an open-source program would have the industrial strength to be successful in the long run.

They have some Jaguars in stock, but they didn't think it was enough to carry FIRST through the next season.

I do think the the Victor manufacturer makes most sense to take this and produce a super-vic a fusion of a Vic & Jag. However from a business perspective I do not see them doing it with any resulting benefit to FIRST. As all business people know, if you have a monopoly you jack up the prices and stop further innovation... If you take the current Vic and just add the Stellaris processor to it their margins will take a hit.

At the end of the day for a successful solution we need a product that has other markets than the 2000 teams at FRC. The Vic is the only contender at this time.

This is just sad.
Dean

Re: TI and future Jaguars
 

I figured that had to be the case because the FIRST statements in the RFQ alluding to maintaining a diverse set of product can really only apply to the manufactures of the Victors. Unless there's some other company making approved speed controls.

As far as the issue of other markets. I think the modularity construct opens the door to that. FIRST can move in whatever direction they like, the rest of the product line can move in whatever direction it likes. We share only the common aspects where costs combine without major headaches.

In the end, as long as we limit ourselves to the existing power limits that FIRST wants any speed control will be stuck with only that market and only that sort of motor unless you can change that limit by swapping out the power section. I can see plenty of situations where the power limits FIRST requires are too high or too low.

In a straight up...hard and fast...quantity manufacturing situation the modular idea adds cost. There's probably no way we can make a modular speed control like this that will be on the cheap end of the R/C car spectrum. However, the value is in the flexibility. I'm sure that flexibility has a market as I've seen few unique alternatives. Also let's not forget that the Victor survives just fine apparently and it's not on the cheap end of the R/C car spectrum either.

As others have pointed out from the issues on the Einstein field, and through out the year at other venues, the whole expense of building something you don't absolutely *need* to survive is sort of lost when you drive blindly for cost. If a better radio, even $50 more expensive, would have prevented that situation I suspect the economics would be well on it's side considering the cost of even competing in just one competition. I know plenty of people that use electronic motor controls in hobby situations that would drool over some flexibility to mix and match, or more important convert their expensive model toy from entirely tele-operated to partially or completely autonomous.

It makes me wonder, however, when you spoke with TI did you describe the project as merely open-source or did you give them details? I do agree that if you suggest the manufacture of a electronic motor control with not much further inspiration from the Victor and Jaguar your market is severely limited, that's why I'm not really doing that here.

Re: TI and future Jaguars
 

I didn't discuss the details of your open source proposal with TI, just high-level.

I like your modular approach especially if the modules can find wider markets. But I wonder if we are slicing and dicing too much already. As you pointed out a modular approach is more expensive than an integrated one (everything else being equal).

I believe we could go the other way. That is a more flexible Jaguar. As we have seen in our technical analysis of the Jag (elsewhere on these posts), the power can easily be increased to 100A ++ just by adding another Mosfet per H-bridge leg, and setting different thresholds on the current sensing software. The BOM cost of that would be minimal. I was browsing through the 800 page Stellaris manual – that is a powerful and very well designed beast! It is made to run RTOS, abundant interrupt levels, it has an amazing brown-out hardware support – it seems the FIRST software image does not make much use of any of this. Therefore I believe one could make a Vic shaped Jag on steroids that would serve the 10A-150A market. And if it is just one SKU I believe the cost could be driven down to below $100. Further just like with the Vics and CRios, FIRST could obtain an additional discount for bona-fide FIRST users. But there must be other markets, and I would think there would be with such a flexible and robust unit. It will kill the Vic though.

On FIRSTs requirement of power control – why could that just be done by specifying the resettable fuse values for each type of motor? Then the judges would check that at inspection time.

Dean

Re: TI and future Jaguars
 

That's what we want! At a high level, all an FRC team wants is an improvement on the Jaguar, and the biggest complaints are the physical size and [apparent] current limit.

So, given the following two statements:

...it seems to me that we need to find the most direct (fastest) path to a Jaguar replacement. If not, the teams that have stocked up on Jaguars will have an unfair advantage over others (especially rookie teams).

On a side note: Dean, was this a typo?
I think you meant, "why couldn't that just be done..."

Re: TI and future Jaguars
 

I can see how having someone else absorbing the TI Jaguar as is might yield a higher current limit. The Jaguars with little change handle a higher current limit already (it's the FRC software in the way right now).

However, reducing the size of the unit, that's basically redesigning all the costly parts. Even the plastic molds for the cases would be in jeopardy. If you choose another purpose built enclosure you could be out $10,000 in just molds and light production just for the enclosures.

So basically what you want is the Jaguar, but not the Jaguar as you know it.

At some point you may as well build the modular speed control with a power module that is like the Jaguar, and an interface module that is basically the Stellaris running the FRC firmware.

Same headaches. Only change being it's modular. Yes it'll be marginally more expensive, but as Dean wrote, the Jaguar is not a money maker.

Re: TI and future Jaguars
 

Then their response was predictable.

The problem with integration is that you force the slicing of the bread just the way you offer. If integration alone was able to secure a large market segment they'd have achieved that long ago but when they did the knock-offs chewed it apart again.

As I've stated previously. I intend to move forward regardless of such an attempt. I think the Jaguar could be fixed. However, in doing so you'd be ignoring that TI couldn't massively sell the unit when it was totally open and sourced through DigiKey on any scale besides FIRST. As I've mentioned in private, custom robotics solution providers are not likely to simply accept the Jaguar (issues or not) as is. These users usually seek to lock in markets not open the markets up. Worse this isn't exactly a mil-spec product either so there goes most production aerospace and military application.

So even with the fixes, yes it'll satisfy FIRST, but I believe whom ever you convince to do that will be in the very same situation that TI put themselves in when they absorbed Luminary Micro. A new coat of paint with a target out of reach.

Why bother to measure current if you do that?
Also, generally self-reseting fuses rarely trip at the currents listed on them, short much higher currents can flow.

Even using the Stellaris and it's speed means that for a very, very short time a larger current could flow (it's just that the motors generally won't be able to make it happen).

Re: TI and future Jaguars
 

Since there is little in the way of actual schematics in this topic I should point out again.

If you take the Jaguar and look at the schematic. Look at the sections of it that handle the power. Look at the sections of it that handle the control.

Take the sections that handle the power and make them the power module.

Take the sections that handle the control and make that the interface module.

Stack them on top of each other.

You've just made the same modular electronic motor control I've been discussing and it's functionally (from the software perspective) the same.

What you just envisioned also has a smaller footprint.

So, I'm not following how redesigning the Jaguar...is all that much different from redesigning the Jaguar in a modular design. I realize it might be slightly more expensive. However, as I stated the original integrated result didn't exactly work as the designers intended on the sales end.

We bite nearly the same bullet. It's just that when we finish we can take the Stellaris off and use other things.

Some minor tweaks here and there but for the most part most of these circuits are not all that different from one another.

Re: TI and future Jaguars
 

Now twist what I just wrote in your head a different way...

Take this for example:
http://www.sparkfun.com/datasheets/R...8_H_Bridge.pdf

If this were put on a power module to be attached to an interface module that would be a big chunk of the power module all in one integrated part. Okay it's missing some of the features of the Jaguar and it's internally a different animal...but still you could make that module with discrete parts.

The idea is to turn the power module into the mass production component. For now that module could be discrete parts on a PCB. Later it could be a single part on a simple PCB if you could afford the integration.

The Stellaris is leveraged in IP. It's full of features that make integrating harder and the more you do, the more the costs to ever reach that scale will sky rocket.

This is no different than the power amplifier (PA) modules used in cellular phones or the RF modules using the D-Link AP. Heck it's no different than the parts from MiniCircuits in the old electronics magazines.

The guys that make cellular phones know what crazy features they want. They buy the 'magic' RF parts from companies and figure the rest out themselves.

Re: TI and future Jaguars
 

Thanks for confirming my speculation from earlier in this thread, that TI just doesn't see a business case where a profit could be made. Keep in mind that since it was just something they acquired as part of a bundle their decision to discontinue it was most likely made on the straight variable costs of manufacturing them and doesn't include amortizing the cost of development nor tooling.

Re: TI and future Jaguars
 

It probably really does not help TI that they source their own microcontroller if you think about it. What are they going to do mark up the price of it to themselves? :eek: (smacks head...I know a company that actually does do this...they'll be delisted from the stock market shortly).

Now think about what the FIRST RFQ demands. You have to use the Stellaris. So what do you think TI will charge you for it?

Yes to divide the Jaguar schematic as I posted earlier you'd need to buy the Stellaris from TI. However, you'd have leverage in a modular design. If TI makes it very expensive you can just swap it out for something more economical later.

Oh and if you're of the mind to make some silicon wafers to get around TI? Keep this in mind:
http://en.wikipedia.org/wiki/ARM_arc...#ARM_licensees

Let's consider this the Trojan Stellaris. You bring it in. It's all nice and pretty. However, it's filled with hidden costs.

Re: TI and future Jaguars
 

The modules are:
1. Power Mosfets
2. H-Bridge driver
3. CPU for fancy stuff and coms
4. Brown-out support (supercap etc that could be in a separate module)
5. on-board indicators (if desired)
6. Thermal management (for higher power systems, bigger fan, heatsinks, etc.)

In reality 1 & 2 would be one module (that is the Sparkfun link above).
3 - 5 would be the second module.
6 may be a selection of fans.


Have you seen the Raspberry Pi - a $30 Linux PC! that could give Stellaris a run for its money as the CPU module. Though we need an RTOS, but there probably is an open source RTOS that could be ported.

The problem we have is the lack of profits in this particular segment that would drive anyone to produce a Jag killer.

Maybe paying $150 per motor controller is not all bad if they don't break and we get to reuse them over many seasons...

BTW: I talked to a few teams that use other processors in addition to the cRio, and I was told the only thing FIRST cares about is that you run each motor control throughthe cRio so they can shut it down for safety. Otherwise you can mount a Cray on each tetacle of the robot. Is that so?

Dean

Re: TI and future Jaguars
 

Do not forget these probably need to be on the high power section or somehow optional to it:
A. Current monitor / voltage monitor.
B. Reverse voltage protection (optional and removable).
C. High side supply (driver could mean 2 different things)...please let's not use P-Channel MOSFETs for the high side.
D. Someway to identify what you just connected to the interface module.

Also we could use a SuperCap, or we could use battery backed static RAM, or just make sure it has a separate power supply interface for the interface module and the power module (let them find a battery to keep the interface module alive or take their chances).

The Raspberry Pi's prime interest to me is the very low cost. Other than that Gumstix, Cotton Candy, BeagleBoards and Pandaboards interest me as well. Along with the stuff at FriendlyARM.

Keep in mind also the Parallax Propeller is 8 processor (they call them COGs) each at 20MIPS microcontroller in a single chip with shared memory. That's 8 things you can do without sharing, scheduling or messing around. My current electronic motor control abused this nicely (why interrupt the processor for the CAN communications, just dump the adjustment data in the shared RAM and let the other processor pull it up when it's ready...no timing issues with flags and semaphores).

Given I'm offering to help offset the costs for a near production prototype, not really looking for an owner as much as contributors. They contribute a little here and there and then when it comes time for production they can use it as well. As demand grows for it, eventually we can start KOPing them if FIRST desires. At that point FIRST might chip in. In the mean time I won't object to people making them or having them made for them on an as need basis.

I think honestly we can make a PWM interface module and power module for less than or around $100 in small quantity.

The CAN modules? Pushing it a bit. Probably not with the Stellaris. Microchip PICs can do it. Atmel AVRs all the way to the XMega with some fiddling. The ColdFire 68k stuff no problem (even CAN2). The Parallax Propeller is a bit of a hack but it works.

Not entirely. Team 11 of whom I am one of the programming mentors did in point of fact field an AMD X2 dual core netbook on our robot this year. It was a full blown system without the display attached (I'll never see those tiny screws again BTW). It had an 32GB SSD. It was *just* under the $400 restriction. We connected it's ethernet port to the D-Link AP and used sockets to talk to Java in the cRIO with Java on the laptop (the students wrote a video processing application basically from scratch that used Video4Linux actually quite interesting). We did use the battery for the unit and all of that was legal and approved for field use at 2 competitions. We did remove the unit towards the end competition outings because of unrelated issues to what the driver's needed. It was connected to 2 USB cameras. One was 1080P resolution and slow frame rate. The other was VGA resolution and high frame rate (more than 30fps). It ran Ubuntu Linux.

The big trick was that it added weight to the robot (3lbs for the netbook) and no matter what anyone said including the Q&A last year I was very concerned we were gonna get told no at the inspections. Turned out great, just needed proof of cost.

I'll also point out again. If we endeavor to make the 'custom circuit module' the FIRST field shutdowns and limits would be honored by that middle module. A person could, if FIRST approves all that, take a laptop put a Parallax Propeller on a single PCB (they are usually used with USB for programming and debugging), make that PCB have places for 6 or 7 'custom interface modules' and then put 6 or 7 power modules on that. That would make one brain out of the laptop, with a USB interface to 6 or 7 electronic motor controls. Again you could do that technically that is all uncharted territory for FIRST to decide on. However for the hobby person they could remove the custom interface module and have essentially a single unit with a USB connector and places to connect 6 or 7 CIM size motors...just do some packaging. It's possible to make the entire control system for a FIRST size robot the size of a kid's lunchbox like that. (Just remember that something still needs to trigger the 'custom circuit modules' safety controls...so there would need to be something from FIRST to do that, software or hardware somewhere...but outside of FIRST...no such issue and no need for those middle modules).

Re: TI and future Jaguars
 

So the deadline is May 11th. Are you going to submit anything on opensource? I browsed through the RFP, they are cearly expecting the bidder to have staying power. I was surprised that they also expect passive royalties to FRC - I wonder if Vics and Jags have a % of sales that goes to FRC?

I got pressed into being the coach of our team - so I'll be busy with that...

Dean

Re: TI and future Jaguars
 

I have a question into the relevant people at FIRST about whether or not such a project needs to submit an answer to the RFQ under the circumstances.

Also, I have a question into my attorney about it.

The only way I could answer the RFQ currently would be to use my company interests to do so which I think sort of defeats the purpose of open-sourcing the project because I'd be, in effect, declaring myself the owner and sole source. It's not clear if I can openly declare myself source of last resort either.

We'll see.

Re: TI and future Jaguars
 

Posted in-line again because I can no longer edit my post above and further when I shift focus dividing the posts makes the entire thing easier to follow IMHO. So when one of you chooses to give me negative feedback about multiple posts in a forum with timeouts beyond my control again...well you have no one to blame except yourselves if you have administrative access.

That out of the way:

I've contacted FIRST KOP and they consider this project unlinked from their intent to have someone manufacture and support the Jaguar speed control nearly precisely as TI had done. So therefore the May 11th deadline in the original link of the RFP/RFQ does not apply to this community project. They would however appreciate as much documentation and information as we can produce as fast as we can produce it.

I've also indicated to them some of the basic details, such as 2 part modular design, one interface part, one high power part, an intention to make a PWM interface, a priority to make a CAN interface, the possibility of a 'custom circuit module', the goal to be able to produce a nearly finished prototype by the deadlines (which could be this year or next), the intention to provide the units outside of the KOP, the intention to have contract assembly houses assemble our parts on demand, and my personal intention to insure that at least 50-100 of them are available at the start of whichever season for delivery (regardless of existing orders for the units...if we start getting orders we can make whatever we need).

I've been running around between getting together data collection tools for Monty Madness, securing my time for Monty Madness and taking care of an emergency or 3. It's on my priority list this evening to get back to finishing up a site for this project so we don't burden ChiefDelphi.

Re: TI and future Jaguars
 

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.
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.
3. Any modular design you come up with had better be fully insulated, i.e. no exposed conducting surfaces.
4. Must use common wiring methods.
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.
6. This protection must also compensate for failures in the robot driver interface(s).
7. Above all, they must be easily inspected for conformity to robot rules.

Re: TI and future Jaguars
 

Per some of the existing comments in this topic:

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.

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.

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.

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.

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.

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.

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.

Re: TI and future Jaguars
 

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"?

Re: TI and future Jaguars
 

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.

Re: TI and future Jaguars
 

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

Re: TI and future Jaguars
 

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

Re: TI and future Jaguars
 

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.

Re: TI and future Jaguars
 

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.

Re: TI and future Jaguars
 

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.

Re: TI and future Jaguars
 

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.

Re: TI and future Jaguars
 

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.

Re: TI and future Jaguars
 

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.

Re: TI and future Jaguars
 

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

Re: TI and future Jaguars
 

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.

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.

Re: TI and future Jaguars
 

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

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.

Re: TI and future Jaguars
 

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.

Re: TI and future Jaguars
 

I didn't use the terms at all until the topic was revolved back over ground it already covered which distracted from the original points (like those points had no merit at all) so for expediency I was trying to get past repeating myself (by being brief as I was asked repeatedly). Sort of like revolving on this point is serving to absorb time and resources but not making the forum itself more practical for this sort of communication.

Are we designing an electronic motor controller or are we discussing the finer points of why forums for Internet communication have issues yet to be resolved? It's not like I personally am the reason that Newton's Telecommunication Dictionary has 25+ editions and so many pages of often cryptic and slang terms. In fact I never even saw a copy of Newton's Telecommunication Dictionary until some college professor started looking for clever word games to play.

It's also not like other people didn't basically figure it out in subsequent posts.

Re: TI and future Jaguars
 

If I can't understand what you are talking about, a lot of folks won't be able to follow it.

Re: TI and future Jaguars
 

Until you made the claim that this couldn't be followed it seemed plenty of people were actually following it.

So if they are lost and not following the topic (and everyone is probably lost now or soon will be because of the side-track):

1. It's not interesting enough to them to take the time to ask about something.
2. They are worried about distracting the topic as this has.
3. They are intimidated that if they ask the question or make an error they'll get themselves attacked.

I've made every effort to explain myself even when I'm wrong. When I am wrong I apologize generally. However, once that is out of the way it doesn't seem to stop there. So yes, I do see why someone might feel that participation might have negative results.

It's nothing personal to anyone. It's a very valid concern. It's like being incredibly sensitive about grammar. Acceptable grammar changes with time. So what might be correct in one English standard today, in about 5 years might be entirely unacceptable. So do we not communicate because we might offend the resident grammar expert? No. We do our best. Then once the result is formal writing we insure the utmost accuracy.

I can't even say that TI managed that formal documentation process with the Jaguar responsibly. The documentation for the Jaguar has both grammatical and factual engineering errors. I see no apology or official attempt to correct from them. It's an electronic document...they don't even feel the need to fix that. It's somewhat hypocritical to put so much effort into worrying about brief brilliant communication when the official documentation for the product that started all this can't even communicate the proper operation of it's own H-Bridge and TI didn't think it important to fix that.

More importantly how bizarre is it that whenever Ether or other members who know about this error tell someone to read that section of the manual they have to post a warning that section is wrong. How handy really. So for all the rest of the students out there that don't happen to have the benefit of that disclaimer how much time do they get to waste trying to figure out or worse memorize that error? How much damage can that officially sanctioned document from TI do before someone finally demands it be fixed? Read the manual sort of implies that effort was made to produce a proper manual to take as gospel.

Re: TI and future Jaguars
 

Well as a software guy, who understands little about the intricacies of motor controllers, I understood exactly what Brain meant regarding in band vrs out of band messaging. Of course, all of the discussions on mosfets and other things leave me bewildered.

At the end of the day, we all want the same thing for the teams. A motor controller that provides lots of flexibility with regards to command and control, and high reliability. TI bought the IP for the Jaguars, and the product was really just a way to demo the chip. Not to really sell motor controllers, so I was not surprised when I heard that they didn't want to continue to support it for FIRST.

I'm a bit concerned about the ability to manufacture in quantity a motor controller without getting a someone with deep pockets to cover the losses/expenses. Maybe sparkfun might be interested in such a project. They could in theory resell to other hobbyist.

I really like the module design, and as an embedded software guy would be more than willing to help on a ROTS/Firmware development project. But I suspect that the timeframe would be at least 12 - 18 months out.

Re: TI and future Jaguars
 

To a certain extent I can fund this effort. I can't afford to buy everyone development kits. I don't want to be responsible for figuring out how to direct resources to developers like that. I'm sure SparkFun would be willing to provide PCBs for a project for a low cost when they run batches. However the issue becomes if we have the time to stockpile based on their production time tables (not our time tables).

I think after we sell 50 to 100 which I can finance we'll be in a much stronger position to justify further expense. I can bank roll this that far. Then we can shop it around like LinxuBoy is doing with his CAN terminators and see who wants to help. It's a hard sell right now. Some people will be skeptical of the ability of anyone to make the project. Some people are in serious financial trouble. Some people will place terms on this project that might not fit a project of this nature.

SparkFun or other sources are certainly welcome to take from the project and manufacture so far as I'm concerned as long as they give credit where it's due.

I have my concerns as well about making this happen from start to finish this year. From the research I've done there's several hundred Jaguars still floating in the supply chain that people can buy. I should think that would be sufficient for some teams to get what they need for new robots if they reuse some of their older controls (it's not like they'll get new features or designs anyway).

I'm okay with funding this well into next year and further if it gets to production. I'd rather ship a really well designed product than something we slammed together just to cross the finish line. If somehow FIRST finds a supply source of the Jaguar in the meantime, good for them it just takes more pressure off this project (I'll still fund it).

Re: TI and future Jaguars
 

Fair enough.

[quote]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.[quote]

One idea is to have a potentiometer input to recreate the function of an RC servo, but with whatever motor, transmission, and range of motion you want.

The headers placed on either side of the fan extend all the way down to the power module. They are rather tall, but I envision metal standoffs providing the structural support for the top of the stack so that is not a huge issue in terms of durability. The inputs wires could stick out the sides that are already blocked so they wouldn't affect airflow.

That is why this is only a concept, besides, this is only one view of the device, if we looked at it from another angle, the footprint would very likely exceed that of the fan.

The air gap is where it is so that the intake airflow could pass over the processor, which would likely be mounted on the bottom of its module. As for the shield, would a heat-sink be sufficient? the heat-sink could potentially fill the entire air gap as long as the fins would let enough air in to cool the power module sufficiently. This would also improve cooling of the processor.

One of the complaints about the Jag is its size, especially its footprint (and its side vents don't help).

The indicator module go on top of the stack using space already occupied by the connectors on the bottom of the input modules. This is an optional module, but I wouldn't be surprised if it would be required should FIRST use the design. FTAs like status indicators.

I was sort of feeling that way too.

Same as above.

I believe that the minimum system should be reduced down to the common H-bridge and a basic processor module. if the team then wants to upgrade then they shouldn't need to buy a new processor. Things like high-speed counters (due to cost) and CAN bus interfaces (due to size) should be add-ons. More advanced users could buy more advanced processors to get systems that exceed Jaguar capabilities, but most of what a Jaguar can do should be possible by adding onto the basic processor module and all of what a Victor can do should be possible with out any add-on parts (beyond the minimum system).

Re: TI and future Jaguars
 

If people are using PWM they wouldn't have any way to inform the microcontroller the maximum value of the potentiometer. So I suppose the value of that potentiometer would have to be fixed? Maybe pick a common value? Also the taper of the potentiometer would need to be fixed, for example linear instead of audio.

Maybe we could outfit the PWM module with a simple serial interface that can be set up once and left that way?

Another concern with the length of the extended headers between the power module and the interface module is that the parallel traces getting longer would be little antenna. Probably not so bad for the PWM signals but it might introduce noise on any current or voltage signals sent in analog from the power section to the interface module.

I suppose instead of really, really tall headers which would be hard to come buy one could use belt cable or PCBs with typical 0.1" headers. However, in either case passing up the sides of the module would block the side intake of airflow leaving access on only 2 sides.

I've got a bunch of ARM processor modules, including chips from Analog Devices, ST Microelectronics, and NXP and I can't say that I feel the need to provide them forced air cooling. Even at their performance level they don't generate a bunch of heat.

However, if you put them physically above the MOSFETs which could disipate 80W-100W of heat under the right circumstances as the heat rises it'll basically cook the chip. In fact in a really bad circumstance I can see how the rising heat might start to reflow the solder paste and since most higher end microcontrollers are surface mount they won't have the mechanical lock that through-hole parts get from the pads their leads pass through.

One downside of a physical heatsink is weight. Also, the tabs on the MOSFETs will require mica insulators to insulate them electrically from the metal heatsink. The tabs are connected to the MOSFET's drains so they are electrically conductive. Worse because of the nature of an H-bridge if you short the high side and low side drains together you'll have short across the supply once the right MOSFETs turn on without electrical insulation to the heat sink.

Obviously mica insulators for these transistor packages are made, it just adds to the base cost of manufacture. Also it's unlikely that we can avoid the fan even with the heatsink. If we put the entire unit in a plastic box we'll need to move the heat out of that enclosure somehow. One solution is put the heatsinks outside the enclosure, but then the transistor leads need to pass through the enclosure walls which makes inspection disassembly more difficult (adding connectors to those wires is possible but just adds more cost and points of failure).

True.

There's really no doubt that with the skill levels involved we need actually more indicators than are currently present on the Jaguar. Possibly even a small LCD under the right conditions (like the size of your thumb tip or down to the size of watch transreflective LCD).

To a certain extent the modularity makes sense. Adding a quadrature encoder and the support circuits for it certainly makes sense to make it optional (I am in favor of using support circuits for encoders like that so that we don't swamp the processor interrupts). However, it doesn't really make sense to make I/O modules for one limit switch contact at a time. Cost wise for limits switches it makes more sense to make a module that has 8 ports with pull-up resistors for limit switches and if they want just one limit switch they just have to accept a module that will give them the ability to use 8. The situation might be a little different with I/O modules that are designed to fill the most common FIRST applications. Surely there would be nothing stopping someone from making other modules for applications outside of FIRST.

Re: TI and future Jaguars
 

Seems to me that there are two problems here.
1. small package high amp pwm controller (aka victor)
basic fault detection and over current limit
voltage control rather than straight pw as victor
wdt
other robot markets
2. added features can, ic2, encoders, software, control algorithms.
possible USB interface for broader appeal

Can the basic small package be built cheap, durable, and flexible enough to add the second set of features at a resonable cost

Re: TI and future Jaguars
 

Using modular components the cost will be slightly higher. However, I am quite confident we can make a module that takes PWM like the Victor and costs in the $100 range in small manufacturing quantity.

Anything more complicated like CAN, I2C, encoders, A/D, control algorithms, USB...all that adds costs like fancy 32bit processors and microcontrollers. In small quantities these things will drive up the costs over $100. Hard to get around it.

I'm not worried about the foot print or the durability. Hitting it with a big hammer will both make it smaller and test for durability. ;)

That said I figure that teams would be willing to pay a little more for electronic motor controls if they work, if they are supported, and if they are reliable (course we have to prove that point by a show of endurance and that will take time). If the initial units are received well it'll be much easier to get additional investment to drive down the costs. So I'm not indicating these units will always be more expensive than the current selections. We just have to walk before we run.

Re: TI and future Jaguars
 

Ok, I'll chip in some capital if we can make this work.

When will we hear (if at all) about the responses to the RFP .

if no commercial entity bids for this , I'll consider co-investing in our own.

Dean