| View previous topic :: View next topic |
| Author |
Message |
kbb
Joined: 01 Jun 2007
Posts: 180
|
 Posted: Tue Mar 09, 2010 12:07 am Post subject: |
 |
|
Example host connector configuration:
Notes:
The resistor pack is currently included to help prevent too much current being drawn if there is an "accident" (either in the firmware, or the way a user connects things up). The alternative is to assume no mistakes are made, as has been done with the design of V3. The board is unlikely to have enough room to allow all the connections to be patched through using jumper selection!
The two (unprotected) "GPIO" lines are to provide access to two ADC ports, whilst at the same time supporting two serial ports (but not at the same time). Possibly the end-user aught to enable the ADC ports using jumpers on the board if room can be found. Or maybe we can also protect them to some extent (to be investigated).
If we recover the two PDI pins as previously described, then it would be nice to use them as the comms ground pins to make it easier to cable things up (i.e. when desiring to use twisted pairs for comms).
If I have not made any mistakes, then this would supply the following host comms configurations:
I2C and two GPIO or,
I2C and one asynchronous serial or,
One asynchronous serial and two GPIO or,
One synchronous serial and one GPIO or,
Two asynchronous serial or,
One SPI or,
4 I/O pins to do with what you like! Except for PA6 and PA7, all host connections are currently to be sourced from port C (although this could change in the future).
Thoughts, criticisms, etc? |
|
| Back to top |
|
 |
robokoi
Joined: 17 Mar 2010
Posts: 1
Location: Boston, Ma, USA
|
| Posted: Wed Mar 17, 2010 10:58 pm Post subject: connector assumptions? |
|
|
About the Hirose connector and the resistance to change. What's the driving force for keeping it? It seems from discussion that there's a split between those wanting to digitize any standard servo and those wanting to use higher voltage/amperage servos (say for robotics, that's my bent), which also determines the available pins for communication.
Is it the 2mm pitch? That the connector is snug or locks in? That the female end can be soldered end-on to the board? 2A/pin? It just seems like it's a large connector for the data/comms side, but too small for higher V/A usage. Since the cable has to handle max current even on data lines, it can be cumbersome when trying to route it around multiple joints or movement areas.
FWIW, I'd rather a more dense comms connector and a beefier power connector. As for locking connectors, if they're snug/snap-in, that should be good enough. The connector should no be providing strain relief. |
|
| Back to top |
|
|
kbb
Joined: 01 Jun 2007
Posts: 180
|
| Posted: Thu Mar 18, 2010 12:47 am Post subject: Re: connector assumptions? |
|
|
| robokoi wrote: | About the Hirose connector and the resistance to change. What's the driving force for keeping it? It seems from discussion that there's a split between those wanting to digitize any standard servo and those wanting to use higher voltage/amperage servos (say for robotics, that's my bent), which also determines the available pins for communication.
Is it the 2mm pitch? That the connector is snug or locks in? That the female end can be soldered end-on to the board? 2A/pin? It just seems like it's a large connector for the data/comms side, but too small for higher V/A usage. Since the cable has to handle max current even on data lines, it can be cumbersome when trying to route it around multiple joints or movement areas.
FWIW, I'd rather a more dense comms connector and a beefier power connector. As for locking connectors, if they're snug/snap-in, that should be good enough. The connector should no be providing strain relief. |
| robokoi wrote: | | any standard servo |
It is the physical size that counts in the phrase "standard servo": the vast majority of robots (such as those constructed using SES) are built using standard sized, but "powerful", servos. If someone wants to install an OpenServo in physically larger servo, an HS-755MG for example, then they have the option to attach some other connector(s). But for the majority, we need to be sure that the off the shelf board can be mounted satisfactorily in a standard sized case.
So first resistance comes from size: any choice of a different connector has to be compatible and sane with the mounting of the OpenServo board in a standard sized servo. Anything that takes up space inside is not good; anything that sticks out a long way is also not likely to be good. Think of trying to use a "racepak" power plug and socket to supply the power and you will see what I mean.
| robokoi wrote: | | That the female end can be soldered end-on to the board? |
Yep, that is good because board space is not wasted. Also note that an end user can always do away with the connector and solder wires directly to the board for the "captured lead" approach as used by a standard servo. Or wire up something different if they have more room.
| robokoi wrote: | | Since the cable has to handle max current even on data lines |
There is no significant current on the data wires, so they can be quite thin...
| robokoi wrote: | | The connector should no be providing strain relief. |
True, but if you imagine them in a biped or hexapod robot, you can see that there may be some strain/pulling: so anything that pulls out really easily may be an issue (a dab of hot glue sounds like a plan though)!
Another consideration is mechanical stability, the thinner the data "pins", then maybe the less mechanically stable they will be (robots can be a bit rough and tumble when they are moving)...
So we seem to be stuck with the Hirose as the standard connector, unless someone finds a better one. Not forgetting, that the maximum current that can be drawn through the board is likely to be limited to at most 4A unless special measures (discussed elsewhere) are taken.
To summarise how power things seem to be panning out at the moment:
The default build may have MOSFETs capable of handling a maximum power of between 6 and 8A (at 25 degrees C).
Up to 4A will be directly supported by the board and standard connector (either or both of which could turn out to be the limiting factor).
Above 4A, and up to 6 or 8A, the end user will need to add “busbars” and also an alternative power connection (hardwired for example).
Above 6 or 8A the end user will need to use the OpenServo as a "brain".
The greater the power, the more likely the end user will need to add heat sinks. As far as I can see, as soon as you go over 4 or so amps the servo is likely to be physically much larger: so having to make alternative arrangement to connect (power at least) to the servo shouldn't be a problem... |
|
| Back to top |
|
|
ginge
Site Admin
Joined: 14 Jan 2006
Posts: 1027
Location: Manchester, UK
|
|
| Back to top |
|
|
kbb
Joined: 01 Jun 2007
Posts: 180
|
| Posted: Mon Mar 22, 2010 7:44 am Post subject: |
|
|
Package sizes/H-bridge
I have been looking at the H-bridge and also keeping an eye on the physical size of things.
H-bridge
For various reasons (physical space needed, component type/sources and so on), an N-channel only H-bridge no longer looks practical. So I will be thinking about the NP bridge.
One option for improved power is the use of newer D-PAK packaged devices; they seem to have better P channels. However, they are also physically quite big so that may be a problem. I guess stacking could be seen as an option. I have a thought about a small improvement which I will try to prototype this week.
Package sizes
The XMEGA TQFP44 package is quite big compared to the OpenServo PCB (see attached, which shows a TQFP 44 XMEGA and a pair of D-PAK packaged dual MOSFETs); therefore it is possible that a production OpenServo would need to use the VQFN package XMEGA so that everything wanted will still fit on the PCB.
 |
|
| Back to top |
|
|
ginge
Site Admin
Joined: 14 Jan 2006
Posts: 1027
Location: Manchester, UK
|
|
| Back to top |
|
|
jharvey
co-admin
Joined: 15 Mar 2009
Posts: 348
Location: Maine USA
|
| Posted: Sun Mar 28, 2010 9:45 am Post subject: |
|
|
To recap, there is a new hardware platform being made that will run the V4 software. This thread started as a 3.1 hardware update, but now has some very significant changes, so who knows if it will have a different version number. It appears that the new hardware hasn't been fully defined yet, and it still being debated.
I'm a bit tight on time, however I'm tempted to start a schematic capture of the new board in KICAD. Do we have a fairly good idea about what we expect to have in this new board? A scanned pencil sketch would be just fine with me, then I can draft it up in KICAD.
I think a KICAD schematic will make a nice collaboration platform that any one can use. I think it will start locking down parts of the design, moving from a debated hardware platform, to a final ready to produce device. So feel free to encourage me to draft up a schematic. |
|
| Back to top |
|
|
kbb
Joined: 01 Jun 2007
Posts: 180
|
| Posted: Sun Mar 28, 2010 10:34 am Post subject: |
|
|
| jharvey wrote: | | I'm a bit tight on time, however I'm tempted to start a schematic capture of the new board in KICAD. Do we have a fairly good idea about what we expect to have in this new board? A scanned pencil sketch would be just fine with me, then I can draft it up in KICAD. |
If you read carefully above, you'll note that I have already done that.
Last edited by kbb on Sun Mar 28, 2010 11:36 am; edited 1 time in total |
|
| Back to top |
|
|
jharvey
co-admin
Joined: 15 Mar 2009
Posts: 348
Location: Maine USA
|
| Posted: Sun Mar 28, 2010 11:21 am Post subject: |
|
|
| I see the connector configuration. It appears that might be KICAD. Do you have a schematic drawn up in KICAD that includes the drive silicone and the AVR? If so, can it be downloaded such that I can help work on it? |
|
| Back to top |
|
|
kbb
Joined: 01 Jun 2007
Posts: 180
|
| Posted: Sun Mar 28, 2010 10:54 pm Post subject: |
|
|
| jharvey wrote: | | I see the connector configuration. It appears that might be KICAD. Do you have a schematic drawn up in KICAD that includes the drive silicone and the AVR? |
Yes, I have a schematic drawn up in KICAD that includes everything (subject to design changes, choices and verification of course). I will upload it to CVS shortly (at the moment the server is not letting me add it to the repository). |
|
| Back to top |
|
|
DavidCary
Joined: 24 Oct 2007
Posts: 12
Location: Oklahoma and Kansas
|
| Posted: Wed Apr 07, 2010 4:12 am Post subject: |
|
|
| ginge wrote: | | kbb wrote: | http://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus#Daisy_chain_SPI_configuration
4 pins... |
I can see a few major problems with this scheme. It requires knowing how many SPI devices you have in the bus, and you are basically using it as a shift register. You clock the required data in offset by the device ID. If you want to write the last device in the chain, say 8, you require (packets) * 8 cycles to get that data in.
It seems lack a really ugly hack. |
While I agree that the things you pointed out are annoying when using the daisy-chain SPI protocol, would you care to point out *any* other interface protocol that does not have the same flaws?
Is there *any* other interface protocol that does not require "using it as a shift register" ? (other than, of course, parallel protocols that use more than twice as many wires as daisy-chain SPI).
Is there *any* interface protocol that does *not* require the master to know how many devices are on the bus?
On boot-up, the SPI master can estimate "big" the daisy-chain SPI shift register is by clocking out a unique pattern and counting how many clocks are required to shift it all the way around the loop of all the devices back into the master's MISO pin. (This isn't guaranteed to tell you how many devices there are, but it can usually tell you when there *isn't* the number of devices you thought there were).
When there are 8 servos on a bus, is there any interface protocol that can update all 8 servos on that bus in fewer than (1 packet) * 8 cycles to get that data in?
Have you heard of the JTAG "bypass mode" ?
kbb:
The I2C data wire is sometimes driven at one end, other times driven at the other end, and other times passively pulled up during the turn-around time.
Each SPI wire is always driven from one end, and therefore requires zero turn-around time.
So at any given goodput and cable hardware, SPI is always going to work over a longer run of cable than I2C.
everyone:
I'm glad you are making actual progress, looking at real transistors and sketching out real schematics that can make real motors move noticeably faster, rather than haggling over minor protocol details that are not even noticeable from the outside like I do  . |
|
| Back to top |
|
|
jharvey
co-admin
Joined: 15 Mar 2009
Posts: 348
Location: Maine USA
|
| Posted: Wed Apr 07, 2010 9:16 am Post subject: |
|
|
| kbb, a while ago you mentioned you were doing a KICAD schematic capture. I don't see that in the CVS yet, is it there? |
|
| Back to top |
|
|
ginge
Site Admin
Joined: 14 Jan 2006
Posts: 1027
Location: Manchester, UK
|
| Posted: Wed Apr 07, 2010 9:21 am Post subject: |
|
|
jharvey,
that is mostly my fault... I can't for the life of me see why kbb can't use the CVS. We will get it fixed, even if I have to do the initial add.
Cheers
_________________
http://www.headfuzz.co.uk/
http://www.robotfuzz.co.uk/ |
|
| Back to top |
|
|
jharvey
co-admin
Joined: 15 Mar 2009
Posts: 348
Location: Maine USA
|
| Posted: Wed Apr 07, 2010 8:52 pm Post subject: |
|
|
| Not rush, I say it gets done when it gets done. Certainly keep the new soft developement as high priority, and keep up the good work. |
|
| Back to top |
|
|
ginge
Site Admin
Joined: 14 Jan 2006
Posts: 1027
Location: Manchester, UK
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
