Chief Delphi

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)
-   CAN (http://www.chiefdelphi.com/forums/forumdisplay.php?f=185)
-   -   TI and future Jaguars (http://www.chiefdelphi.com/forums/showthread.php?t=105531)

techhelpbb 10-05-2012 11:55

Re: TI and future Jaguars
 
Quote:

Originally Posted by Al Skierkiewicz (Post 1168518)
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.

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.

Al Skierkiewicz 10-05-2012 13:51

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.

techhelpbb 10-05-2012 14:04

Re: TI and future Jaguars
 
Quote:

Originally Posted by Al Skierkiewicz (Post 1168553)
If I can't understand what you are talking about, a lot of folks won't be able to follow it.

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.

mjcoss 10-05-2012 15:05

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.

techhelpbb 10-05-2012 15:47

Re: TI and future Jaguars
 
Quote:

Originally Posted by mjcoss (Post 1168568)
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.

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.

Quote:

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

PAR_WIG1350 10-05-2012 22:28

Re: TI and future Jaguars
 
Quote:

Originally Posted by techhelpbb (Post 1168454)
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.

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.

Quote:

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

Quote:

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

Quote:

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

Quote:

I will say that this footprint is smaller then what I originally described.
One of the complaints about the Jag is its size, especially its footprint (and its side vents don't help).

Quote:

I'm just worried that using the space like that might make it hard to put indicators on the unit
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.

Quote:

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.
I was sort of feeling that way too.

Quote:

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

techhelpbb 11-05-2012 05:53

Re: TI and future Jaguars
 
Quote:

Originally Posted by PAR_WIG1350 (Post 1168676)
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.

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?

Quote:

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

Quote:

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

Quote:

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

Quote:

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

Quote:

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

Quote:

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

dcherba 11-05-2012 10:26

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

techhelpbb 11-05-2012 10:44

Re: TI and future Jaguars
 
Quote:

Originally Posted by dcherba (Post 1168748)
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

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.

dsirovica 14-05-2012 00:05

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

Al Skierkiewicz 14-05-2012 08:18

Re: TI and future Jaguars
 
Do you guys know what you are committing to? For just the KOP and enough to fill Spare Parts you are looking at almost 10,000 units before teams start to buy extras.

techhelpbb 14-05-2012 09:12

Re: TI and future Jaguars
 
Quote:

Originally Posted by Al Skierkiewicz (Post 1169195)
Do you guys know what you are committing to? For just the KOP and enough to fill Spare Parts you are looking at almost 10,000 units before teams start to buy extras.

It's not required we build anything for the KOP to have it approved for FIRST use. I confirmed that quite some time ago with FIRST KOP. If FIRST KOP wants it badly enough for that purpose they are welcome to boot strap the funding.

However, according to my contacts at FIRST KOP we can get something approved by September when the documents are finalized and then, because we don't wish to put it in the KOP, we just have to make production volume for those that buy when they find out it's approved in January. If we did put it in the KOP we'd need production volume by October.

As stated I'm willing to provide boot strap resources to get working near production ready prototypes, and produce 50-100 of whatever FIRST ends up approving. More if people actually gobble those up.

If we can't make the deadlines for this year I'm perfectly fine putting resources into this into next year.

Additionally between the monitoring equipment I am working on right now for the power supplies on the robot, the websites, I've already poured $3,000 of mine into this (never mind the $4,000 I spent already messing around on my own outside of resources sent to Team 11 for projects over the last 2 years).

Besides 10,000 units is really trivial. With the resources involved if push really came to shove I could probably easily make 50,000 units a year if there was demand to buy it and the schedules weren't ruinous.

dsirovica 14-05-2012 12:01

Re: TI and future Jaguars
 
I think we need to wait for the RFP results.

Brian: do you know from your FIRST contact when that will be?

I think IFI may be the only bidder. And if so, I don't see how an open-source solution can compete. The best we may be able to achieve is to keep IFI under pressure not to make too much profit from FIRST.

Dean

Al Skierkiewicz 14-05-2012 12:38

Re: TI and future Jaguars
 
Quote:

Originally Posted by dsirovica (Post 1169240)
The best we may be able to achieve is to keep IFI under pressure not to make too much profit from FIRST.

Dean

Dean,
I am guessing you don't know the history of IFI and First. You don't need to worry about this.

Alan Anderson 14-05-2012 13:52

Re: TI and future Jaguars
 
Quote:

Originally Posted by Al Skierkiewicz (Post 1169195)
Do you guys know what you are committing to? For just the KOP and enough to fill Spare Parts you are looking at almost 10,000 units before teams start to buy extras.

The RFP gives an expected sales volume to FIRST of "only" 6,840 units for the 2013 season. Adding the team sales brings the total to a bit over 10,000.


After looking back over the thread, it appears to me that Brian is talking about a completely separate proposal from the "future Jaguar" RFP that I though the discussion was about. That difference in assumptions will likely have led me to make comments that aren't quite applicable to what he has in mind. Brian, if that's the case, it would have avoided a lot of confusion if you had split your project ideas into a separate thread instead of filling this one with them.


All times are GMT -5. The time now is 00:50.

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi