OpenServo.com

[mpthompson]

Cliff,

Thanks for the detailed response concerning the logic voltage supply. You raise a very valid concern about trying to force a one size fits all solution.

This week I've been going through the process of quiting my day job which has made my week less than stress free. In any case, I now have more free time to devote to the OpenServo and other projects. I'll be looking at the materials you provided in more detail and respond to the specific issues you are looking for feedback on.

-Mike

[Cliff]

Barry,

[mpthompson]

Cliff,

Concerning the dimensions of the ver. 3 board. To fit into the Hitec HS-475HB and the HS-645MG servo case, the board dimensions should be should be no larger than 17mm width by 20mm length. These servos are sold by Lynxmotion and work well with their servo brackets.

Pictures of the HS-645MG OEM PCB can be found here. Notice the motor wires are soldered directly to the FET outputs and hot glue used for additional support. The motor wires are not through-hole.

To fit these dimensions you may want to consider losing the ears on the board that wrap around the motor and just making a straight edge. Unfortunately this gives up some real-estate for the motor wire holes. Perhaps motor pads can be put on the top of the board where the words ""Open"" and ""Servo"" are currently silkscreened with the motor signals routed using a via through to that side of the board.

-Mike

[ginge]

Well considering it was 2am when I wrote that, I was short on explanations and ideas. I have managed to snatch 5 minutes to articulate:-

Mike hit the nail on the head:-

[mpthompson]

Cliff,

I have some comments on signal changes you may want to make to your design. When I first created the ATmega168 OpenServo hardware I chose to use the 16bit Timer1 for PWM generation with PWM outputs on OC1A and OC1B (pins 13 and 14). However, in the software I'm only using that timer in 8-bit mode which is a waste of the Timer1 resources. It would be better to switch PWM output to use 8-bit Timer0 with PWM output on OC0A and OC0B (pins 10 and 9).

This would free up the 16-bit counter for more precise measurement of time spans such as a servo pulse width that I'll describe below.

Therefore, my proposal for the MCU to H-Bridge signals are:

PD0 (pin 30) - Reserved for UART RXD
PD1 (pin 31) - Reserved for UART TXD
PD2 (pin 32) - EN_A to H-Bridge
PD3 (pin 1) - EN_B to H-Bridge
PD4 (pin 2) - SMPLn A to H-Bridge
PD5 (pin 9) - PWM_B to H-Bridge
PD6 (pin 10) - PWM_A to H-Bridge
PD7 (pin 11) - SMPLn B to H-Bridge

Notice that Port D of the ATmega168 is dedicated to H-Bridge control and the PD0/RXD and PD1/TXD pins are reserved for future use as a serial port in other ver. 3 derived designs.

With these changes PB1/OC1A (pin 13) and PB2/OC1B (pin 14) would no longer be connected.

Another change you might consider is to route the ICP1 (pin 12) to the external connector. This pin is the input to the Input Capture Unit associated with Timer1 and would become the pulse input for RC control of the ver 3.0 OpenServo. With Timer1 freed up by the changes above we can use the 16bit Timer1 to very accurately measure the 1 to 2 ms pulses. Right now we use 8bit Timer2 as a makeshift 16bit timer using interrupts which isn't ideal for pulse measurement.

I hope this is useful. Let me know what you think. I'll continue to look things over and make more comments as they occur to me.

-Mike

[mpthompson]

[SOI Sentinel]

While I'm not working on an OpenServo implementation at the moment, I thought I'd chip in on a few things.

1) I might be misunderstanding this one. The CAN idea to use the transciever is interesting (I have not seen an 8 pin all in one CAN chip yet). However, remember that CAN transicevers have their in/out serial, but have a two wire differential bus on the other side. As this is not a real CAN implementation (unless you implement it in software) you might end up echoing back your information to your controller. You also don't automatically get all the nice buffering, error checking, and routing capabilities of a full CAN controller.

I'd check the capabilities of the UART, but you'd probably have better luck with an RS485 implementation.

2) My own plans for something like Open Servo quickly diverged in the power sector. I decided to put in a central power switcher to provide logic power. Motor power would be disconnected and share the ground plane. Logic power would be buffered but not regulated at the driver boards, and I was considering a small voltage reference so I could communicate back to the smart switcher to adjust voltages up and down to compensate for line losses. Motor power would have a separate connection. Overall, this was similar to what IIRC ginge is doing, staring his power. However, I could kill motor power and keep the logic live for other uses this way.

3) I'm always a little concerned about using pin headers in a high motion environment. They'll work fine probably, but my choice is more along these lines for logic at least.

C-Grid/SL

While it IS more difficult to solder than a board mount, I personally like a short lead as flexibility options are a little better versus an onboard plug.

I originally wanted to pursue OS boards fro the 645MG and the 805BB, but I've decided to take my $40 and see what I can find in the surplus or new market for a gearmotor and pot for that price and hopefully see increased torque or speed. This also releases me from trying to fit the exact dimensions of the servos.

[Cliff]

Mike,

Thanks for the dimensions. The 20mm length will not be a problem, but the 17mm width will get interesting (doable but painful). 17.5mm would be much easier than 17mm - can I ask you to measure the 645 case again? I noticed that the board was scored and broken, instead of routed and it is not unusual to make the boards undersized, because the edges are always rough from the break. Also, could you measure the diameter of the motor?

I'll probably try to keep the ears, because I think it is poor practice to lap solder the motor leads to the PCB. I think the motor leads can fold down between the motor and case and then a short loop can come back up to the through holes in the ears. The other reason I want keep the ears is to provide every last possible square mm of copper surface for getting heat out of the FETs.

On the Atmel pin-out: I followed your development of the RC/PWM mode and was greatly relieved when you found a way to do it without rewiring. I understand your desire to make OpenServo as widely useful as possible, but I really think that mode should take what's leftover and not serve to limit OpenServo's use in serious robotics. Using timer 1 for FET PWM may be a waste because only 8 bits are currently being used, but if we want to control motor voltage when using a battery voltage that is higher, those extra bits will allow low maximum duty cycle PWM without loosing control resolution. Is it worth give up control resolution for a better RC/PWM mode? I don't think so - but I'm willing to hear the argument.

Reserving the RxD an TxD pin is fine, although I can't think of a reason - except for the CAN thought going around. I need to read up on CAN, but at first glance it seems like it has an awful lot of overhead, impacting both the effective data rate and code to support it. Just looking at the packet overhead, it looks like for short messages at a megabit/S, it would not keep up with I2C running at 400 Kb/S.

As to the other pin changes, I need to study the layout - I'll probably be back with a counter proposal.

On the +5V on the connector, I when back and forth, and settled on leaving off for two reasons. The first reason was the desire to come to the OpenServo connector with grounds for both the I2C signals, so that they could be twisted pairs. If the I2C signals were coming from a break-out board, the break-out board could have a capacitor between the +5V pin and ground, which would make the 5V wire as effective as the ground wire in keeping the I2C signal clean - but I decided I could not assume the presence of a break-out board with a capacitor. The second reason was the need to include a diode or jumper pads, which would only be used infrequently for start from scratch programming. As tight as the board is, I didn't think was worth the small benefit. I also thought about a separate logic supply, but unless the logic is completely isolated from the motor supply, there really is no benefit. Completely isolating the supplies is not doable for this board, given the space constraints, using any devices that I could find. Again, I can be converted, but I'm not there yet.

Thanks for the feedback, keep it coming.

Cliff

[mpthompson]

Double checking, the measurements of the HS-645MG OEM PCB look to be 17.5 mm by 20.5 mm as measured with a vernier caliper (calliper for Barry ). There is a very small amount of wiggle room so an 18 mm by 20.5 mm board might fit, but it may need some filing. Keeping it at 17.5mm would be safest. The motor is 17 mm is diameter and the edge sits 21 mm from the PCB edge connector (0.5 mm of space between the PCB and the motor).

Also, the HS-645MG case does have a depression in the case that fits around the PCB and the case would need to be modified to fit the ears as you have them. The modification wouldn't be too easy because the motor is hot-glued in place and there isn't a lot of room to fit an X-acto knife in to cut the plastic. There is also a plastic tab in the back of the case that matches a small cutout on the back of the PCB, but this is where the case would be modified anyway for the larger OpenServo connector.

For motors with larger current draws, would it be possible to glue heat sinks on top of the FETs rather than just relying on the PCB to dissapate the heat? The heat sinks would be inside the case, but perhaps air holes could be put in the case for convective cooling of the heat sinks in extreme cases.

Right now I'm contemplating assisting Jim Frye of Lynxmotion on the design of an OpenServo based controller for his super-sized servos as discussed in another thread. For better or worse, RC pulse control will most likely be the primary means of controlling that servo (using the SSC-32 they sell) and the I2C connection will be for secondary control. The servo will also likely have serial control as well. Therefore I do have an interest in making sure some effort is put into measuring pulse widths as accurately as possible and reserving the RX/TX lines. I think it might be useful if we standardized on a common pin usage between OpenServo based servos, but it isn't critical.

I'm certainly willing to honor your wishes regarding the desire to not include a 5v input as you are doing the work for this flavor of the OpenServo. I've never been a fan of the diode or jumper. People who need/want a 5v input it will probably add it back in anyway -- as I'm sure Barry will do.

Something to keep in mind is what will be the best way to program this servo from scratch. I typically make small adapter boards that privide me a standard 6 pin ISP connector. In this case the adapter would need a way of applying power as well to the servo for flash programming.

-Mike

[SOI Sentinel]

Separated power supplies are one of my personal needs, more because I want to get rid of the heat dissipation of an onboard regulator if I can and I'm looking at 12V gearheads for my designs due to the high torques, speeds, and worries about melting casings on the heavy analog servos.

CAN is a serious PITA to do if you don't have an integrated CAN controller in your MCU. Atmel CAN MCUs are 64 pins and up. Addon controllers are usually at least 20 pin parts themselves, PLUS the additional transciever... you're not shoehorning that into a standard sized case. Trying to software simulate it is extremely time consuming as it's a collision avoidance schema.

CAN was designed for environments where multiple parts need to get the same data, and the environment is NOISY. The transcievers can operate with something like a 40V potential differential between nodes and can operate through 250V spikes. There's a lot of CRC and routing hardware there that you don't necessarily need for short messages. CAN also is limited to 8 bytes of payload plus the 11 or 29 bit header (depending on the version of the protocol). CAN is also designed for longer distances. 1Mbps has a chain length of 40m and somewhere over 100 nodes (did I mention it also needs termination?). The low end comm rates can go kilometers.

For basic openservo that's meant to be popular, I highly dissuade the use of CAN. I'd rather see an I2C -CAN MCU master built into the power/data distribution boards if someone wants to go that route, as then you could have distributed control of groups of servos.

And if you're going THAT far, I'd personally take the Atmel equivalent of a PIC 18F66J60 Ethernet MCU and build a servo-ethernet bridge controller.

If you wanted an alternate, I'd suggest a RS485 transciever. I took a peek at the 168's datasheet and it looks fully capable of async and sync transfers. The 485 transciever would provide a buffer and driver to allow longer distances. 20MHz operation would allow transfer rates of 2.5Mbps. It would operate pretty much like I2C for program and control purposes but should provide the better distances and noise immunity of true differential signalling.

[poor-robot]

Forgive my assault - I tend to focus on potential issues more than the quality of the design. Overall it solves a lot of the concerns I had with the second gen design and looks solid. One thing I'd like to add at some point is a little bit of transient protection, but your connector choice is a great step forward on that front.

One choice I noticed that doesn't affect the layout: 100K pull-up resistors are going to give you a really slow turnoff on the P-FETs. I wouldn't go much over 2K unless your slow turnoff is intentional. You won't notice the extra 2 mA when the motors are running.

One other minor thing is you're using a non-ratiometric temperature sensor with a low-accuracy voltage regulator. I'm not sure how important accuracy is in this situation and whether you're just looking for 70C or thereabouts before shutting down, in which case there is no issue.

As far as communications, why not RS-485? It's just differential UART and you specify whatever overhead you want. CAN has a ridiculous amount of overhead, additional circuitry, and cost associated with it for most applications. We use RS-485 at my work and it is much more reliable than I2C over distance/motor proximity. There is no room on the current board, but maybe in the future. The one downside about heading to 3.3V is smaller RS-485 transceivers that operate at 3V are rare.

The necessity of a four-layer board hurts the design a bit. They are expensive in small quantities. The alternative is smaller parts, which cost the same, but are much harder to work with. I've hand-built with QFNs but I don't like to do it. Maybe I'll look into some smaller parts this weekend.

[ginge]

Hi,

First off... CAN.

After reading the protocol specification and reviewing what would be needed to showhorn this together I think it is a dead loss. The implmentation would have to be done in software and not robust. SOI was correct, and from the forums and pages I see him knocking around in, very knowledgeable about CAN. SOI, thanks for for feedback. I will think no more about CAN.

I still would like the RX and TX lines to be exposed to the edge connector, I have something in mind for those, and it would make for a useful GPIO/TTL serial debugging output. RS485 is an interesting idea, and something that can be added to the firmware at a later stage if the pins are exposed -- research needed.

If it is decided that the RX and TX is not going to make it to the final board I will probably do as Mike suggested and get my own derived version fabricated.

Poor-robot:
Welcome, and thanks for the feedback. I am curious as to which connector you would like to see on the OpenServo. I am looking for a robust latchable low profile connector and wondered if you had something in mind.
I agree that 4 layers is a shame, but at this stage a necessary evil. Most people will go to a fab shop, or RobotJay to get hold of the board, which means they might as well get 4 layer. Fabricating an OpenServo in your home shop is painful. Believe me, those tiny vias are a killer, I would not recommend it.

Interesting stuff!

Barry
_________________
http://www.headfuzz.co.uk/
http://www.robotfuzz.co.uk/

[poor-robot]

As far as connectors go, I really like the Pico-Blade series from Molex. They are not latchable per se, but offer a good notch/friction fit and are a 1.25mm pitch SMT heater. You could potentially put one of each side of the board. I think the four-conductor version is somewhere around 10mm wide including shroud. We use the 8-pin version in a brushless motor control application.

http://www.molex.com/customer.html?supplierPN=532610471

If the serial RX/TX lines are brought out then they would provide the opportunity to go to RS485 later because you could use the same lines for A and B.

My concern over four layers isn't primarily from a home-built perspective. I stopped making my own boards some time ago out of laziness and my own inability. Four layers still cost significantly more in smaller quantities in my experience. You could get, what, maybe fifty OS2 boards crammed into a DSS panel from Olimex for under $40. Say $1 per board. The PCBExpress setup is a $250 minimum that comes to $12 per board even with Cliff's panelization work. The price comes down eventually but you have to drop about $1000 on a board order first. I realize it's a racecar but I don't think the desire is for a McClaren F1. Is it?

Cliff, earlier in the post you were looking at ways to add fets for control of the low-side h-bridge fets. As you said it would solve the issue of what voltage to regulate to. Check for SC-70 or SOT-563 packages such as: http://www.diodes.com/datasheets/ds30448.pdf These give you two N MOSFETs in a much smaller but still manageable package.

A couple of other things I noted on further review:
Couldn't you eliminate the two analog switches and simply route the other EMF signal to ADC6? That could really help the board space situation.

What guarantee do you have that the back EMF isn't going to exceed the input range to the ADC to a point where damage could be caused? A zener there could help prevent that possibility.

The general practice I've seen is to PWM the low-side fets because of their superior characteristics. It may not matter here, just one thing I noticed.

[SOI Sentinel]

Ginge - I'm not an expert, I've just been working on plans for a self-routing control system based around CAN for a long time, so I'm well aware of the advantages and limitations imposed by the standard. The design that started this is still a ways off for me, but MUST work and be fault tolerant. It's currently based on a self checking parallel CAN bus design that should avoid failure due to physical separation of the bus segments (multiple-redundant fly by wire). I am still known as the batty mechanical engineer by my peers.

poor-robot: I posted a link to the C Grid/SL connectors I favor. Larger wires, yes, but also higher current capacity in those wires.

Four layer boards: I personally plan to do my initial prototyping of any designs through Sparkfun's new 4 layer protoboard service. It's now $10 setup plus $8/sq inch for that version. If I decide to make a few, I'd probably end up going directly to Gold Phoenix. This Chinese Fab is the same as what Sparkfun uses, after all. Pricing looks halfway decent, but I haven't added up all the options yet:

http://www.goldphoenixpcb.biz/special_price.php

While back EMF is a nice option, I'm still a bit skeptical on its use in anything but a continuous rotation servo used to drive a wheel.

Low side FET PWM is a much easier method of doing PWM. Yes, they are lower RDS and often times faster, but it's more the ease of activation and not needing to charge-pump them like a high side FET that makes them the preferred choice. However, most modern controllers will PWM the high side FET of the same half-H bridge, too. This is done so that the diodes are not engaged while the motor is free wheeling. This apparently greatly improves drive efficiency and reduces FET heating, but may not be as effective with lower amperage motors than I usually deal with. It's not possible to do without having individual control of the FETs, and somewhat tricky to do without dedicated hardware and/or motor drive PWM as all you need is one software lockup and you're doing a battery check.

[poor-robot]

Sentinel - the link doesn't work for me. I can find the series of connectors but I'm not sure the exact setup you're suggesting. From your comment I think it would be wires directly off the PCB and the connector would be at the end of a short pig tail?