OpenServo.com

kbb · Joined: 01 Jun 2007 Posts: 180

Whilst for now I am concentrating on using the existing V3 board, here are some additional thoughts/my input on the next version (V4?)...

Temperature sensor

I believe this appears useful as it allows for an automatic shutdown to be implemented in the firmware if things are starting to get too hot... and it does not take up that much space on the board, therefore I would vote for it to be retained.

Brown outs

I have not had any brownouts (that I am aware of!) since the crowbarring issue was fixed in the firmware; as long as the battery has a reasonable charge or I am running off a PSU - however, maybe this will change once the biped starts to walk properly (currently it can “stand” and “sit” on its own, but other biped tests are not really putting a significant load on the servos). There doesn’t seem to be a problem with a single servo, even with extreme test loads on high power servos (for example: including HS-645MG and MG996R).

Power supply

I would potentially still like to see some kind of improvement. Better isolation? For example: a diode and cap (as a reservoir) to isolate the regulator, I know it means the battery volts need to be bit over 6V as things stand (I am using 7.2V PSU and 7.2v “racepaks”). Maybe it could be optional via a user installed “link”/“jumper” (see “Option pads” below)... possibly even an n-way split (regulator via VBATT, regulator via diode-cap from VBATT, regulator via diode-cap from separate supply or via separate +5V supply).

“Option pads”

If possible some unused pins or other functionality should be brought out to spare pads on the PCB, thus allowing experimenters to easily connect other things... This would even be a way to allow for the “other comms method” option that was suggested - for example: RXD/TXD or the TWI pins can be brought to the external connector by installation of “links”. If there are spare pins in the connector, then this is one way for end users to choose their functionality (GPIO, ADC and for on).

Changing the MCU architecture

I cannot currently see any clear gain to changing the architecture of the MCU, especially as it will probably make it harder to support “legacy” users (those already using V3 boards who do not want the expense or hassle of changing) and also impact other areas (for example: boot loader, changes to dev tools, recoding and so on). But maybe someone has some ideas?

However, changing up to the Atmega328p would provide advantages in terms of memory space for the future, with potentially only a few minor issues and possibly allow better support of the legacy users. Cost wise the Atmega328p appears to be 25% cheaper than the Atmega168 (I had better check that again)...

Dropping the EMF support

I have to agree with Barry. Whilst the idea was nice, sadly the realities are that it hasn’t worked as desired. I know I have spent a lot of time on it (code wise), and I suspect Barry and others have too... dropping it to leave space for the “links”/ “jumpers” options and a better sized board seems like a useful gain.

“we can use fast reading off the 12bit encoder for better resolution.”

When I skimmed the docs, I though the 12bit resolution applied to 360 degrees of rotation, so for “normal” servo use the practical resolution is reduced?

Changing the protocol

Currently happy with I2C. If we rely on the 5V interfaces, then different protocols can be added using the “links” option and writing the appropriate software.

However, adding “RS485”, for example, seems trickier as it would require additional onboard hardware if the servo was to be seen as a true RS485 device. However, one could forgo this and probably implement some compatible protocol locally amongst the servos or other devises connected to the same “bus”, or place the buffer and level shifting hardware externally. I.e. 485 is an electrical connection standard not a data protocol.

Board size

It is a tad wide and a tad deep: all the servo’s I have tried it in need careful paring back of the case structure to get them back together again with the OS board inside. There always seems plenty of free space down towards the pot, so maybe a two piece board is workable. But beware if the encoder hardware takes up a lot of extra space compared to the pot.

Design document

I think it would be useful to have some form of design document set (or spam-protected WIKI pages) that can be updated as things progress and so that everything is available in one place.

ginge · Posted: Tue Feb 16, 2010 1:39 am Post subject:

Hi Kevin, thanks for contributing to this

ginge · Posted: Tue Feb 16, 2010 1:55 am Post subject:

I'm going to summarise and add:

These pages are interesting from a research perspective. They detail all information added from contributors regarding the path of OpenServo.

http://openservo.org/Software_Feature_Requests
http://openservo.org/Hardware_Feature_Requests

I have the ball rolling with a wiki page:-
http://openservo.org/Future_Development

Cheers,
_________________
http://www.headfuzz.co.uk/
http://www.robotfuzz.co.uk/

kbb · Joined: 01 Jun 2007 Posts: 180

jharvey · Posted: Wed Feb 17, 2010 12:40 am Post subject:

I seem to recall you can increase your accuracy by adding noise to it. Such that if your signal is between two ADC values, lets call them 1 and 2, and your value is 1.2. Your ADC will read 1. If you take 10 samples and add random noise to those samples, at times the noise will raise the sample such that it reads 2, not 1, and the rest of the time it will read 1. Then average the readings should produce a reading of 1.2 not just the 1.

Just a mild brain far. It might be easier to do something like that, then changing the brain.

kbb · Joined: 01 Jun 2007 Posts: 180

Moved here from: "OpenServoV3 and OSIF, servo problem"

ginge · Posted: Sat Feb 20, 2010 2:53 pm Post subject:

hmm my original post is now here: no idea what happened there!

I have just seen the XMEGA range from atmel are now reasonably priced. In fact, the XMEGA32 is now comparable in price with the atmega168

It gives us some amazing gains compared with the normal atmega range. here is what I have worked out so far:

1x 12-bit ADC with 4? channels

2x TWI modules

2x SPI modules

higher res PWM + more channels?

DMA - we can transfer the ADC result directly into the result registers with no interrupts

It also still uses TQFP44 package, so we know it will fit and it relatively simple to solder.

I'm going to investigate this more, but here is the link to the farnell page:-
http://uk.farnell.com/atmel/atxmega32a4-au/mcu-8-16bit-xmega-32k-flash-44tqfp/dp/1748557
_________________
http://www.headfuzz.co.uk/
http://www.robotfuzz.co.uk/

ginge · Posted: Sat Feb 20, 2010 3:00 pm Post subject:

kbb · Joined: 01 Jun 2007 Posts: 180

I have been looking at the various MCUs and architectures. The ATXMEGTA32A4 looks like a good choice to me. It seems a bit odd that the cost is lower than the ATmega168/328, even if we look at the 64K ATXMEGA64A4. The 64K looks like a drop in replacement for the 32K, so there is an upgrade path if needed.

Is a 12 bit ADC sufficient for everyone’s needs? Based on the V3 based servos I have here, that would equate to a resolution 0.05 degrees of pot rotation.

The most practical way that the resolution could be increased is with a separate ADC chip. From a cost point of view, the sample rate decreases with increased resolution. Noting that the ATXMEGTAxxA4 has two TWI buses and two SPI busses, there can be an onboard comms method for “upgrades” (e.g. add a higher res ADC chip via the “option pads” solution) as well as retaining the host comms. No bit-banging required!

ginge · Posted: Mon Feb 22, 2010 12:03 am Post subject:

jharvey · Posted: Mon Feb 22, 2010 1:20 am Post subject:

About hardware, I'd like more drive capability. I put a note on the wiki, but perhaps if we drove it with an equivalent of the VNP20N07 set as an H bridge of course. I found that these little servos are just to small for what I wanted to do with them. More current ='s more power.

I know there are inductive drive combo chips out there, like those that drive fuel injectors. Are there equivalents for an H bridge? I'd bet there are, but I haven't had a chance to look yet.

ginge · Posted: Mon Feb 22, 2010 6:49 pm Post subject:

It isn't a bad idea to get some meaty FET driver in there, but I wonder exactly how much more current you can push into a small servo. I have melted a couple by supply too high a current and voltage.

I assume an inductive bridge doesn't waste the field current as head when forward flowing through the diodes? TO be honest with you, I thought for a pure inductive bridge to work, it requires an AC motor... is this not the case?
_________________
http://www.headfuzz.co.uk/
http://www.robotfuzz.co.uk/

jharvey · Posted: Mon Feb 22, 2010 7:49 pm Post subject:

eh? I don't follow.

kbb · Joined: 01 Jun 2007 Posts: 180

jharvey · Posted: Tue Feb 23, 2010 1:37 am Post subject:

Hmmm, perhaps the brain board could be the normal OpenServo board, capable of driving standard sized servo's. It would need to include some vias or similar attachment options for a separate power upgrade board.

I think it can be expected that more power will cost more. I suspect that most people will be looking at this as a hobby servo option, however the PID algo's inside, make this attractive as a general purpose control board.

I know the layout is currently tight, but we are also talking about simplifying it. So perhaps that will decrease the cost of real estate, and make room for some vias that could be used to attach add-on modules.