OpenServo.com Forum Index OpenServo.com
Discussion of the OpenServo project
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

OpenServo V4 (was OpenServo V3.x hardware update)
Goto page 1, 2, 3 ... 12, 13, 14  Next
 
Post new topic   Reply to topic    OpenServo.com Forum Index -> Hardware
View previous topic :: View next topic  
Author Message
ginge
Site Admin


Joined: 14 Jan 2006
Posts: 1030
Location: Manchester, UK

PostPosted: Fri Mar 13, 2009 1:25 am    Post subject: OpenServo V4 (was OpenServo V3.x hardware update) Reply with quote

Hi All,

I think it might be time to start looking at getting a new hardware revision out of the door with the current feature requests.

Current Feature requests:

* Encoder support (now testing in software)
* better/bigger pot mounting holes
* more gpio on header
* analogue input on header
* gpio on main OpenServo board
* external 5v power input (debatable)
* bigger servo mounting holes/lugs

Can anyone add to this list before I put the needed headers in place?
This is a fairly minor change, so I would consider this feature set a 3.1 release.

Cheers all

EDIT: Please Note that this thread has morphed into a detailed discussion regarding an OpenServo version 4.
_________________
http://www.headfuzz.co.uk/
http://www.robotfuzz.co.uk/


Last edited by ginge on Tue Mar 30, 2010 12:25 am; edited 1 time in total
Back to top
View user's profile Send private message Send e-mail Visit poster's website Yahoo Messenger MSN Messenger
jharvey
co-admin


Joined: 15 Mar 2009
Posts: 359
Location: Maine USA

PostPosted: Tue Mar 17, 2009 8:40 pm    Post subject: Reply with quote

I just did a little multi vendor comparison for the BOM I found in the zip download. I found 8 mfg parts had exact match Newark numbers, and I found 3 that appear to be digikey only items. They may have some acceptable subs, but I didn't look into it quite that much. I found near matches for all other components.

Any how, it looks like there could be a $4.50 cost savings per board. If all parts are ordered from digikey, in qty 1, it would cost about $17, and if we ordered most components from Newark, it would cost close to $13.5.

Of course I'm assuming that higher quantities would share a similar ratios, and I'm ignoring the $20 fee from digikey because I'm sure real orders would have enough qty of exceed the digikey min.

I can post my alt vendor BOM if it's wanted. However I don't currently know where to post it.
Back to top
View user's profile Send private message Visit poster's website
ginge
Site Admin


Joined: 14 Jan 2006
Posts: 1030
Location: Manchester, UK

PostPosted: Tue Mar 17, 2009 11:15 pm    Post subject: Reply with quote

Nice, please post!

You could add it to the wiki... just create yourself and account and uoload the file.

Cheers
_________________
http://www.headfuzz.co.uk/
http://www.robotfuzz.co.uk/
Back to top
View user's profile Send private message Send e-mail Visit poster's website Yahoo Messenger MSN Messenger
jharvey
co-admin


Joined: 15 Mar 2009
Posts: 359
Location: Maine USA

PostPosted: Wed Mar 18, 2009 11:23 am    Post subject: Reply with quote

I've posted it to here

http://jaredharvey.com/openservo

Feel free to mirror that data, or better confirm it, then add it to the real BOM as an alt vendor.

I plan to also do a search with octoparts to see if perhaps the price can come down further.

Also, it appears that the price is the negligible for the 10k 1% and 10k 5%, so I'll just use the 10k 1%, ect.
Back to top
View user's profile Send private message Visit poster's website
jharvey
co-admin


Joined: 15 Mar 2009
Posts: 359
Location: Maine USA

PostPosted: Wed Mar 18, 2009 4:44 pm    Post subject: Reply with quote

I just did another alt vendor colum in the bom spreadsheet, using octoparts to find the vendors. It appears that Quest is a great component supplier, also it claims the components for qty 1 would cost $9.83 down from the pure digikey order at $17.04. A $7.18 savings in qty 1.

I've uploaded a new bom, replacing the one I had up there. In this one I've also included links to the octoparts pages I found the pricing on.

The octoparts bom is an exact mfg number match to the orginal bom. No subs.
Back to top
View user's profile Send private message Visit poster's website
ahoeben



Joined: 20 Jun 2008
Posts: 20

PostPosted: Mon Mar 23, 2009 9:58 pm    Post subject: Re: OpenServo V3.x hardware update Reply with quote

ginge wrote:

* analogue input on header

If by analogue input you mean the possibility to have an external pot like I suggested, then yay! Wink
Back to top
View user's profile Send private message
robotjay
co-admin


Joined: 01 Aug 2006
Posts: 225
Location: Nebraska, USA

PostPosted: Wed Nov 11, 2009 12:33 am    Post subject: Reply with quote

Would it be possible to use the 3 holes for the pot connection to double as quadrature encoder inputs? This eliminates the need to add yet another hole/pad to our already cramped board.

In my mind, it would be a simple matter to route an unused digital i/o pin to the +5v pad for the potentiometer. That way, simply turning that pin on would give a potentiometer +5v. For encoder input, the same pin's direction is reversed, and the analog pot pin is switched back to digital. The only caveat, is that the encoder still needs a way to get +5v (or whatever it's required voltage.) The required voltage could easily be sucked directly from the battery input. This at least keeps us from having to drill another hole through the board.

Your thoughts?
_________________
"Nothing is fool-proof; For we fools are ingenious and will find a way."
Back to top
View user's profile Send private message Send e-mail Visit poster's website
rotdrop



Joined: 15 Dec 2009
Posts: 16
Location: Germany, Ruhrpott

PostPosted: Mon Feb 08, 2010 11:07 am    Post subject: Reply with quote

I would suggest to replace the Atmega168 by the Atmega328p which is pin-compatible to the 168 and doubles the memory resources (RAM/ROM/EEPROM).

From my experiences with a Hitec 645 MG servo I would also like to mention that having a slightly (fraction of a millimeter ) narrower board would make it easier to install it into the servo housing. See also Jared Harvey's contribution to the wiki concerning an MG995 servo. Modifying the servo case of the 645MG to make the OSv3 PCB fit into it was somewhat time consuming. The board itself would more or less fit into the cut-outs for the original controller board but for some of the surface mounted parts which are mounted pretty close to the edges of the OSv3 PCB.

Are there any plans to release a v3.x hardware update? And possibly to sell assembled PCB's via RobotFuzz?
Back to top
View user's profile Send private message Visit poster's website
jharvey
co-admin


Joined: 15 Mar 2009
Posts: 359
Location: Maine USA

PostPosted: Mon Feb 08, 2010 9:43 pm    Post subject: Reply with quote

While more RAM and such internal resources are kind of nice, I don't think we are hitting those boundaries at this point. I like robot Jay's thought about the changing things around for that +5. I think it's easier to get a via for +5 then it is to get a via for the GPIO pin that's being used by open encoder.
Back to top
View user's profile Send private message Visit poster's website
ginge
Site Admin


Joined: 14 Jan 2006
Posts: 1030
Location: Manchester, UK

PostPosted: Fri Feb 12, 2010 8:27 pm    Post subject: Reply with quote

If we want to push OpenServo forward, I think we need to take a step back. Current the v3 has lots of features, that no one is using, or can use. The amount of extra components to drive the Back EMF is staggering. And although it works, it has a lot of flaws. I won't detail them here as I have already gone over the issues. Sufficed to say, if we went back to a simpler, cleaner design, we should make the whole project more accessible again. We will once again be back in the realms of something that you can actually build with commodity tools. As it stands OSv3 is complex and insanely small. Not good.
We also have a problem where the schematics and PCB designs are designed in a commercial PCB editor. This has meant we have a wonderful PCB, but we can't open the diagrams to change. We should look at rectifying this.
I think the software side of things is pretty stable. It would be nice to have better PID, but there is no magic bullet on this one.

Personally I see something like this working:-

* Drop the EMF support. It is nice to have but so unreliable and hard to account for it is useless. we can use fast reading off the 12bit encoder for better resolution.
* Include support for the OpenEncoder as a default. Use the hardware I2C for faster data aquision. (depends on below)
* Move away from I2C as the main protocol, but support it still.
* Use the HSUART to do RS485 or another multidrop serial
* Have two sockets on the PCB
* Use a socket that is easier to source
* Reduce the size of the PCB to fit all servos
* Produce (is possible) a new pcb that works for both mini and normal servos
* Make the pot holes larger, and share them with the encoder functionality.


I don't think any of this is a huge problem for us. If we went back to a simpler hardware design, we could put that space to better use with a stronger H-Bridge or more GPIO connectors (the amount of times I wish I had a gpio pad for an LED...)

It may seem counter productive to go with the simpler system, but in the long run it makes the project a lot more accessible and open.

Your thoughts....
_________________
http://www.headfuzz.co.uk/
http://www.robotfuzz.co.uk/
Back to top
View user's profile Send private message Send e-mail Visit poster's website Yahoo Messenger MSN Messenger
jharvey
co-admin


Joined: 15 Mar 2009
Posts: 359
Location: Maine USA

PostPosted: Fri Feb 12, 2010 9:33 pm    Post subject: Reply with quote

The EMF support is mostly to measure torque right? Or are there other feaures this offers that I'm not remembering. Measuring torque can be done with another current sensing technique. Hall comes to mind, mostly because I don't like the resistor approach. I would like to see the ability to measure torque, but I suspect most don't need it.

About the connector, I found the two mounting screws interfere with the connector socket when I ran screws all the way through. I don't like having a connector on the device. I feel that vibration will be a long term problem. I like the orginal strain relief design. But I don't like the non-locking connector at the end of the 3 wire pig tail.

If it were going to be re-designed, I would see some benifit in allowing the reuse of the 3 wire pig tail that we are currently tossing. Are there any good bidirectional multi drop communication busses that use one wire, with power and ground availble?

Also the AVR is known as expensive. Perhaps I would ponder an ARM processor while I was at it.

Or rather than a redesign, ironing out what we have is also a great way to go.
Back to top
View user's profile Send private message Visit poster's website
ginge
Site Admin


Joined: 14 Jan 2006
Posts: 1030
Location: Manchester, UK

PostPosted: Fri Feb 12, 2010 10:45 pm    Post subject: Reply with quote

Tricky one. Especially from a small revision point of view. The issue here is that doing a small incremental revision means investing in 1000 more units. Do we expect to keep the 3.x design around for at least 2 years? It costs quite a bit to purchase that amount of servo boards.

Switching to ARM is an attractive approach. We should do a general cost analysis on how much this will cost vs the current design. I would be able to do the port as I have worked with the ARM architecture.

I will ponder on that one further.

EMF is used for measuring the speed of the motor but has the side effect of reducing torque. The EMF requires that the power to the motor is switched off periodically in order to sample the freewheeling voltage. Turning off the voltage in this way causes torque reduction.
_________________
http://www.headfuzz.co.uk/
http://www.robotfuzz.co.uk/
Back to top
View user's profile Send private message Send e-mail Visit poster's website Yahoo Messenger MSN Messenger
robotjay
co-admin


Joined: 01 Aug 2006
Posts: 225
Location: Nebraska, USA

PostPosted: Sat Feb 13, 2010 6:37 am    Post subject: Reply with quote

ginge wrote:
The amount of extra components to drive the Back EMF is staggering.


I whole heartedly agree. The prospect of sensorless control of the servo was very appealing, but it just doesn't work the way we wanted it to, for a myriad of reasons.

ginge wrote:
* Have two sockets on the PCB


Do you mind clarifying why you want to do this? I personally would like to see 2 sockets to make for easier daisy chaining, but maybe you've got something else in mind...

I like your list of changes, especially the idea of re-purposing the I2C hardware. Having each servo effectively be an I2C master is intriguing.


I have a couple suggestions of my own:

* We should drop temperature sensing for similar reasons as BEMF.

* I recommend that we optionally isolate the power busses to the motor and MCU. We've all used our own various hacks to do just this anyway, let's go ahead and formalize it in the design.


Talk to you soon,
Jay
_________________
"Nothing is fool-proof; For we fools are ingenious and will find a way."
Back to top
View user's profile Send private message Send e-mail Visit poster's website
ginge
Site Admin


Joined: 14 Jan 2006
Posts: 1030
Location: Manchester, UK

PostPosted: Sat Feb 13, 2010 2:41 pm    Post subject: Reply with quote

robotjay wrote:

Do you mind clarifying why you want to do this? I personally would like to see 2 sockets to make for easier daisy chaining, but maybe you've got something else in mind...

You got it in one Smile

robotjay wrote:
I have a couple suggestions of my own:

* We should drop temperature sensing for similar reasons as BEMF.

Hmm.. I quite like the temperature sensor, and for the sake of two resistors I would prefer it stays. I actually use that feature to compensate for the fadt I overvolt the servos by throttling when getting hot.

robotjay wrote:
* I recommend that we optionally isolate the power busses to the motor and MCU. We've all used our own various hacks to do just this anyway, let's go ahead and formalize it in the design.


Can you clarify? I haven't done anything fancy with the power bussses on my v3s as I don't suffer from brownouts.
Additionally I am testing some code this weekend to hopefully lessen the drain problems when the PID clamps down.
_________________
http://www.headfuzz.co.uk/
http://www.robotfuzz.co.uk/
Back to top
View user's profile Send private message Send e-mail Visit poster's website Yahoo Messenger MSN Messenger
robotjay
co-admin


Joined: 01 Aug 2006
Posts: 225
Location: Nebraska, USA

PostPosted: Sun Feb 14, 2010 2:56 am    Post subject: Reply with quote

I've always thought that the temperature sensor was measuring ambient air temperature. But after re-reading the datasheet, it turns out that the sensor actually measures the temperature of the PCB trace leading into it. This would make the sensor much more valuable than I thought. That being said, can't we still get similar results by regulating the current through the windings of the motor? Do you see a performance increase by overvolting and throttling? In the end, the sensor is small and cheap, but I tend to be a minimalist. If you want to keep it, I won't have anything else to say about it. Smile

robotjay wrote:
* I recommend that we optionally isolate the power busses to the motor and MCU. We've all used our own various hacks to do just this anyway, let's go ahead and formalize it in the design.

ginge wrote:
Can you clarify?


I still get the occasional brown-out, even with a capacitor on the motor. Mostly when the motor starts at or near a stall condition. But maybe I should focus more on the root cause, instead of band-aid solutions.

Regardless, I still like where we're going with this discussion. Talk to you soon.

-Jay
_________________
"Nothing is fool-proof; For we fools are ingenious and will find a way."
Back to top
View user's profile Send private message Send e-mail Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    OpenServo.com Forum Index -> Hardware All times are GMT
Goto page 1, 2, 3 ... 12, 13, 14  Next
Page 1 of 14

 
Jump to:  
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