Single openservo board multiple servos?.

Discussions relating to development and use of the OpenServo software/firmware.

Moderators: jharvey, Secondary Admin, Admins

Post Reply
camaro89rs
Posts: 2
Joined: Thu Oct 29, 2009 4:23 am

Single openservo board multiple servos?.

Post by camaro89rs » Thu Oct 29, 2009 4:31 am

Hello,

First I wanted to say awesome work on the open servo project guys. Sorry if this has been asked before, I have searched the forums to great depth and I dont see anything posted on there.

I am looking to use openservo's for a 3DOF hexapod robot. Would it be possible to gut out 3 servo's and wire them all to a single openservo board, this would accomplish 2 things for me.

a. Keep the cost down as one ATmega168 will run a leg instead of one per joint.

b. Ease of making the board (could possibly do it through hole instead of SMD). and possibly ease of changing servo chassis incase I burn out a servo.

I had a couple of thoughts and looked at the code, but had some basic questions. Is there already an effort by anyone for this?.

I was thinking of using a single atmel connected to 3 different H bridges using 3 different PWM channels (maybe a IC based H bridge instead of discrete components) coupled with the A2D channels. If I were to dump the voltage sense and temp sense (I dont think these are present in 2.x), shouldn't I have enough lines to run 3 servos?.

I noticed that even at its full code base, when compiled only ~32% of Flash is used...

I plan on using these with 3 MG995 servos -> yeah they are pretty bad with the stock firmware, but after opening one I have come to the conclusion that the motor and gears arent bad but the circuit is mediocre.

Thoughts?

Thanks

jharvey
co-admin
Posts: 362
Joined: Sun Mar 15, 2009 12:06 pm
Location: Maine USA
Contact:

Post by jharvey » Thu Oct 29, 2009 9:02 pm

I believe you don't have the resources for doing three with one here. I seem to recall the OSV3 only has two or perhaps three extra unused pins. You'll need more that that to add a second set of IO for motor control, and another AN for the POT feed back ect.

Also I believe the firmware is pushing it's boundries at the moment. I understand it's only been mildly looked at in terms of compressing and leaning out, so the code that is there may be able to be made smaller to allow for the new code you would need.

I would suggest simply using three seperate OSV3's and rely on the I2C bus. I seem to recall that you can get up to 16 devices before bus latency starts to be come an issue.

camaro89rs
Posts: 2
Joined: Thu Oct 29, 2009 4:23 am

Post by camaro89rs » Thu Oct 29, 2009 9:16 pm

jharvey wrote:I believe you don't have the resources for doing three with one here. I seem to recall the OSV3 only has two or perhaps three extra unused pins. You'll need more that that to add a second set of IO for motor control, and another AN for the POT feed back ect.

Also I believe the firmware is pushing it's boundries at the moment. I understand it's only been mildly looked at in terms of compressing and leaning out, so the code that is there may be able to be made smaller to allow for the new code you would need.

I would suggest simply using three seperate OSV3's and rely on the I2C bus. I seem to recall that you can get up to 16 devices before bus latency starts to be come an issue.
Shouldnt the V2x code have more space?, I think the pins are unavailable because there is a temp sensor and a voltage sensor pin. It looks like only 2 PWM pins are being used, since the 168P has 3 PWMs (OC1A, OC1B, OC2A, OC2B, OC3A, OC3B) even if I were to use 2 PWM pins per channel for the H bridge and one ADC channel (since ADC 4 & 5 are I2C pins) (4 ADCs are usually available if I ignore the voltage and temp sensors?).

Since PWM channels are hardware controlled, the software cycles are not being used for that right?. unless the math required for curve profiling is too slow to run for 3 servos..

jharvey
co-admin
Posts: 362
Joined: Sun Mar 15, 2009 12:06 pm
Location: Maine USA
Contact:

Post by jharvey » Thu Oct 29, 2009 10:54 pm

I seem to recall the V sensor is used for EMF measurement, that correlates to torque if used in the newer firmware. If you don't mind sacrificing the ability to measure your torque, I think your right that a modified version could be made. By not compiling the code for those sections, I think that would get you the memory space you are looking for as well. I seem to recall that most of the math functions could be called and the return values could be handled such that you can update a different PWM reg.

I don't see why it couldn't be done at first glance.

ginge
Site Admin
Posts: 1031
Joined: Sat Jan 14, 2006 2:34 pm
Location: Manchester, UK
Contact:

Post by ginge » Sun Nov 01, 2009 5:04 pm

you could also save a lot of space by disabling the curve motions, the extended alerting functions, the interrupt code and the syncronised motion methods.

You caould also sacrifice the bootloader to get another 2k out of it.

In all, the core OpenServo code takes up very little space, and it is the extra features that require the additional space.

The curve functions do require a lot of calculations. The code is written to use floating point math as this was a tradeoff for the nasty fixed point math overflows that were happening.

I think you could possibly get two motion cures to run in the 10ms window, but to get threee calculations you might have to change the heartbeat values to 20ms or so.

Other than the above issue, there shouldn't be a lot needed to alter the code to run 3 basic PWM channels.

Post Reply

Who is online

Users browsing this forum: No registered users and 0 guests