OpenServo V4 (was OpenServo V3.x hardware update)

Discussions relating to development and use of the OpenServo hardware.

Moderators: jharvey, Secondary Admin, Admins

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

Post by jharvey » Mon Feb 07, 2011 5:26 pm

I guess a first question would be, what are your skills? Do you know KICAD or are you willing to learn KICAD?

RasmusB
Posts: 4
Joined: Sat Dec 15, 2007 12:13 am
Location: Södertälje, Sweden

Post by RasmusB » Mon Feb 07, 2011 6:31 pm

Yes, I know kicad. I use it for hobby projects as well as some work related stuff. Everything from simple amplifiers to fpga based waveform generators. :-)
I have some experience of microchip and atmel microcontrollers, and at work I have access to equipment for smd soldering and rework, and a pcb mill.
/ Rasmus

Robotaxonomist
Posts: 4
Joined: Fri Feb 11, 2011 5:58 pm
Location: Boston, Massachusetts

Post by Robotaxonomist » Fri Feb 11, 2011 8:02 pm

I was just wondering, would it at all make sense to make one pin either the pot input or a second I2C input for the encoder? Very few people are going to be using both an encoder and a pot, I suspect. Does this work from an IC & schematic point of view?

Robotaxonomist
Posts: 4
Joined: Fri Feb 11, 2011 5:58 pm
Location: Boston, Massachusetts

Post by Robotaxonomist » Fri Feb 11, 2011 8:10 pm

Oh; since you were talking about KICAD... How is the Mac version of that?

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

Post by ginge » Fri Feb 11, 2011 10:40 pm

There are so many pins on these things it is often easier to add both I2C and pot. You can possibly use both at the same time. Start up and sample absolute, and then switch to encoder incremental.

Robotaxonomist
Posts: 4
Joined: Fri Feb 11, 2011 5:58 pm
Location: Boston, Massachusetts

Post by Robotaxonomist » Sat Feb 12, 2011 4:28 am

I just mention it because of the concern about lack of board space. The through-hole or pad where you solder the pot down might as well be the same one you solder the encoder to, so long as no one has an interest in using both at once. If it’s not a matter of the pinout, maybe you can use adjacent pins, both on the same trace, and just activate one and deactivate the other.

BasicFox
Posts: 59
Joined: Sun Mar 15, 2009 2:45 pm
Location: Belgium

Post by BasicFox » Fri Jan 27, 2012 11:06 pm

Robotaxonomist has a point, you can save even more space if you don't use trough hole pads, you can solder a flat cable directly onto the bottom side of the PCB, something like this:
http://search.digikey.com/us/en/product ... ND/2416317

BasicFox
Posts: 59
Joined: Sun Mar 15, 2009 2:45 pm
Location: Belgium

Re: OpenServo V4 (was OpenServo V3.x hardware update)

Post by BasicFox » Sat Jan 28, 2012 4:27 pm

ginge wrote: * more gpio on header
* analogue input on header
* gpio on main OpenServo board
* external 5v power input (debatable)
This would be problematic when we use the same connector as in v3. Do all that wiring by hand. Maybe it's good to split up the connectors:
power connector (6-7.4V) soldered on the powerPCB
These are very common and can handle 8A
http://be.farnell.com/camden/ctb9308-2a ... dp/1717022

Another connector for the 5V and IO, something like this:
http://be.farnell.com/multicomp/4409as- ... dp/1565548

If we position the important pins (GND MISO SCL MOSI) in the beginning then its possible control the servo with 4 wires:
http://be.farnell.com/te-connectivity-a ... /dp/149032
all we have to do is cut off the left or right side of it.

It will also look neater than all separate wires.

douglas
Posts: 66
Joined: Thu Nov 01, 2012 8:34 pm

my 2c worth

Post by douglas » Fri Nov 02, 2012 2:33 am

Hi,
I have ordered some v2 open servo boards to play with (I am using Vigor VSD-11YMB HV winch servos that deliver up to 40kg/cm for a hexapod) to play with and then found this forum.
I am looking at modifing V2 to add multi-drop RS485, hot plug, auto-discovery of servos (I wrote a bunch of AVR code a while ago to do this for another project, including funtions to uniquely assign an identifier to a AVR CPU, etc).
I like the idea of the H-bridge in a single component, especially as some have a built in temp sensor and maybe to change the potentiometer to a hall effect sensor.
I am looking to try and fit this onto a double sided board as 4 layers seems to cost a lot to make; If I have to stack two board then that is fine for my purposes; but if 4 layers proves cheaper than it doesn't worry me.
Cheers
Douglas.

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

Post by jharvey » Fri Nov 02, 2012 11:07 am

Hello and welcome along.

There has been some talk about a V4, that might end up ARM based. Have you see the Discovery and combined it with the CooCox? It's a $12 step through your live code development platform. Very powerful for nearly no $. Any how, this allows for some really nice features, and ARMs are the most popular embedded processor out there. As for the 485, I may have part of another project I can share to help out. I'll look into it. Do you have a schematic for how you plan to implement 485?

Also look for OpenEncoder (OE) it is and was a magnetic encoder option for OpenServo. It allowed full rotation with absolute position control.

douglas
Posts: 66
Joined: Thu Nov 01, 2012 8:34 pm

Post by douglas » Sun Nov 04, 2012 8:17 am

I have been thinking about this CPU: STM32F103T6U6A
as:
(1) it is not very expensive
(2) Already set up as a motor driver (emergency stop, etc)
(3) has a CRC generator (good to confirm the received command is not corrupted), and to add a CRC to sent packets
(4) has a brownout and WDT timers
(5) in the LQFP48 package seems to be the same size as the CPU used in OpenServo V2.1
(6) has a built in temperature sensor
(7) Can run at 8MHz without an external crystal
Note: I already have an Olimex ARM-USB-OCB JTAG device.

For RS-485 I am considering the SN75HVD12D as:
(1) It is fault tolerant (open and short circuit)
(2) Supports Hot Plug
(3) Is nice and small (SOIC-8)

I will put together up a circuit in Eagle PCB over the next few days for comments...

Cheers
Douglas.

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

Post by jharvey » Sun Nov 04, 2012 9:28 am

Any chance I can convince you to try KICAD?

Also if you can implement the STM Discovery connector, it's much lower cost and simpler to use than the Olimex JTAG.

Also I've used ST1480ABDR for 485 before. Might be worth considering, might be the same chip, different MFG. Key difference is price.

douglas
Posts: 66
Joined: Thu Nov 01, 2012 8:34 pm

Post by douglas » Sun Nov 04, 2012 9:09 pm

I will have a look at KICAD over the next day or so, as well as the STM discovery connector.

One thought; everyone seems focused on getting everything into the servo itself, what would happen if we left the pot (or hall effect sensor) and motor in the case and centralised *all* the electronics.

The ARM processor is more than capable of handling all the PWM in software, perhaps go for a digital Hall Effect sensor (AS5132, using RS-485 with the chip select and clock common to all servos and the data uniquely going back to the CPU, therefore each servo would contain 2xRX and 1(or 2) TX interfaces, e.g. ISL81387IBZ)?

That leaves two wires for the motor, and 5 for the remote hall effect sensor; the net result is that we would use in terms of I/O ports on the ARM:
1 x Chip select for *all* servos (1xRS-485 driver)
1 x Clock for *all* sensors (1x RS-485 driver)
1 x Data in *per* sensor (1x RS-485 receiver)
2 x motor wires with the H-Bridge held centrally.

So for a 3DOF hexapod = 18 servos, which gives:
1 x Chip for the servos (1xRS-485 driver)
1 x Clock for the servos (1x RS-485 driver)
18 x Data for the servos (18x RS-485 receivers)
36 x motor wires with the H-Bridge held centrally.
Total 56 I/O ports, plus a UART to allow the unit to be talked to.

The something like a LM3S1601 or ATSAM3X8CA?

We may end up with a large PCB, but it would work with any servo as size is no longer an issue.

Interested in comments....

Cheers
Douglas

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

Post by jharvey » Mon Nov 05, 2012 10:01 am

Long leads in the POT will lead to an increase noise floor of the sensor signal, inducing an error. Also long PWM motor leads with motor currents and voltage spikes will emit more RF which will get into the pot signal. You generally want to keep these lead lengths minimal to have a more accurate device.

douglas
Posts: 66
Joined: Thu Nov 01, 2012 8:34 pm

Post by douglas » Mon Nov 05, 2012 10:11 am

Good points,
I am devising a prototype using an Atmel ATSAM3N00AA-AU CPU and MC33887APVW to drive the motor for in servo use and hope to post a schematic by the weekend.
Cheers
Douglas

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest