Power Conversion Questiions

[seal killer]

All--

(Hi. I am a newbie.)

I am an electronics novice. However, I can pretty much read a schematic and I built a lot of stuff when I was younger, including a few robots. (Think 30 years ago.)

It is time for me to get back into the robot building hobby. There is so much more available now than before! It is amazing.

My current design will be large (50 to 250 pounds), slow (walker with 8 legs) and I would like to off-load all the processing to a PC or a network of PCs via wireless link. (I am looking at Robot Electronics RF04/CMO2 combination with the GPIO14[ for I/O.)

Here is my question. It looks like I will definitely need 5v for logic, 6v for motors, and MAYBE 12 volts for . . . something. Can I just use a couple 12 volt batteries in parallel and hook a 5 volt DC to DC switching converter to them AND a 6 volt DC to DC switching converter? I cannot figure out a reason to run the leg motors--which will be very low rpm and include encoders--from a converter. Therefore, my plan is to power them directly from the batteries.

I would really appreciate any thoughts you may have for me.

--Bill

[Admin]

Sounds expensive 

Lets see, 8 legs, 3 motors each, thats 24 motors . . . Each motor will be like $50 . . . that equals . . . a lot.

As for your battery question, it really depends on how much current your components will draw. You must use a 5V voltage regulator for logic, and you can use any battery you would like for it. I recommend a small 6V NiMH battery.

For the motors, you do not need to regulate voltage and you should run it directly from the batteries (the exception is with servos). Depends on the voltage rating of your motors, but I recommend getting a 7.2V NiCad or Lithium battery.

As for wireless links, search this forum for 'wireless', 'blue tooth,' 'easy radio,' and 'laptop.' There are several posts you may be interested in.

And a side rant:
Try really hard to make your robot weigh as little as possible. Weight is very important with legged bots . . . Use carbon fiber, plastics, etc - avoid all use of metal if possible.

[seal killer]

Admin--

I am here to learn and I have already learned a bit! (Power the motors directly, as I suspected.)

My motor source is currently Banebot. I bought one of their RS545 motors (MP-36256-545, 12v, 61 rpm, $41.30). It is far too much motor for even my heavy machine . . . which will not weigh anywhere near 250 pounds. The truth is, I do not know how much it will weigh at this time. Nor, at this highly experimental, learning stage do I feel a need to know how much it will weigh.

I have two more of Banebots' motors coming. Both of these are on the other end of the scale; two FF-050 series (MS-16118-050, 6v, 126 rpm and MS-16574-050, 6v, 26 rpm). My structural parts will be mostly aluminum. I will turn all the joints on a lathe. (A side note: My machine's leg joints will all be driven by screw drives. My amatuerish guess is this will allow me to use very small, gear-drive motors since there will be additional "gearing" via the screw drives.)

I will search this forum for the wireless links you suggested. I will also post something soliciting comments on the RF04/CMO2 combination, on which you did not comment. Coupled with the GPIO14, which provides 14 input/output pins (and other "must have" stuff) and is daisy-chainable over the I2C bus up to 8 units, it seems ideal for my purposes. (Other than what I REALLY wanted: A wireless version of the Elexol Ether IO 24! I wrote them and suggested they offer such a device. They wrote back and said they had been thinking about it. Since then, they have quit answering my e-mails.)

I know I can learn a lot here as this forum does not seem to be oriented to any one microcontroller series or language, or other "main" thing.

In reply to your (gentle) "rant": It seems to me that the more legs the less one must worry about weight. Obviously, the more legs the less power required of leg motors. There is an (indirect) inverse relationship between number of legs (or wheels!) and the amount of weight the structure will support and the power consumed by individual drive motors. Of course, the larger the machine, the more total power will be required to move it a given distance. My machine, which is all in my mind at this time, will be powered by 12v, lead-acid garden tractor batteries. That way, I get lots of amps, easy recharging, and zero learning curve due to familiarity of use.

I am a high-level programmer by trade (OK. I USED to be. Since I have been in the business for well over a quarter century, I have joined the dark side and am in management) and am fascinated by the idea of terabytes worth of bit-state joint position tables available over a wireless link. I am also a somewhat successful GA programmer. ("Somewhat successful" means that I have written GA programs that work and actually solve "problems.") I would like to couple the bit-state joint position tables with some GA programs and see what happens . . . other than my movable components wearing out very quickly!)

But, here I am to learn, not teach. Hopefully, you and others will do the latter for me.

--Bill

[Admin]

The reason why I dont recommend a lead acid battery is they generally have low current output.
Looking at the MS-16118-050 motor, it says .3A no load current and 1.8A stall current. Lets say each of your motors
only draws 1 amp, thats 24 motors x 1 A = 24A. A lot! You either need to put a lot of batteries in parallel, or use lithium polymer batteries. Check the current output rating on the battery you use . . . I am a big fan of a minimum learning curve too, but just know that lead acid weighs a lot more and outputs a lot less when you design your robot. I used 2 motorcycle batteries on my very first robot (which failed miserably), and I refuse to use lead acid again 

Yea you are right about more legs means less force carried by each leg. Also to note, you only need to design one leg, and can just make 8 of them using mass manufacturing techniques like CNC. The effort of making eight legs is about the same amount of effort in making one . . . And how many motors you plan to use per leg? I assumed 3, but perhaps 2 instead?

You may want to consider using servos as they already have built in feedback position controllers. Otherwise, if you get a regular DC motor, you then need to incorporate a leg joint angle sensor with PID control. Hitec is now making some really nice powerful 7V servo motors. Check the partlist http://www.societyofrobots.com/robot_parts_list.shtml

Sorry . . . I didnt comment about the wireless parts because I am not that experienced in them myself and dont want to say something stupid. Dunk, if you read this, this is your cue!

Since you are a seasoned programmer, I was curious of the algorithms and sensors you plan to use. I encourage you to keep us updated with your project!

[seal killer]

Admin--

Again, I learn! I live to learn.

I DID NOT KNOW that lead acid batteries provide relatively low amperage. I thought just the opposite. Thank you for saving me a configuration/design mistake at the very outset. (Initial mistakes are the most expensive, not necessarily in terms of cost for me, but in terms of TIME.)

I am not embarrassed to say that I really know nothing about PID controllers. (If you divest yourself of all the ego possible to get rid of in the first place, you are in an ideal position to admit your mistakes and ignorance and therefore, learn.) From what I can tell a PID controller is a device which supplies a firmware-based negative feedback capability to your machine. A PID controller also may utilize an error history to refine its feedback. Is that anywhere close?

I am an inventor with awarded USPTO patent(s). There will be five motors per leg due to something I am planning to patent that will enable far more NATURAL movement of the leg. The chance of a successful patent is fairly low. The chance of a successful patent if I describe it publically one year or more of the patent FILING date is ZERO! I hope to get some time to build a full scale leg model (the model will be simple and look almost nothing like the actual leg) that will allow me to test motors (and sensors). I will post pictures and videos of that model here. However, I will take them such that the potentially patentable part is not obvious or actually covered up. If and when I do so, I will re-explain to everyone and make full apologies at that time.

I have looked at Hitec in the past, but will look at them again thanks to your guidance.

I am a very seasoned programmer, but I think I am living on my past laurels! I REALLY need to start cutting some code again since I have discovered that it is NOT like riding a bicycle! I would like to write everything in VB6.0 or some version of BASIC because those are the last languages I used. However, if ABSOLUTELY necessary, I can write anything in pure binary. (Ha! I guarantee you that it will never be absolutely necessary, though! <g> )

My algorithms will be fairly simple since I will depend on terabytes of learned postions stored in tables as bit on/bit off entries. When my network of desktop PCs discovers an error in machine position caused by driving the machine via a table, they will simply update the appropriate table(s). My plan is to "teach" (this is not as tough as it might sound) the machine how to perform all discrete, fundamental movements, store the sensor positions in a bit table and then access that table either in its entirety or partially to recreate the movement/position called for by low level motivation logic and/or real-time sensors. (It will be a house machine, as well; at least initially.)

My sensors will initially be very simple: Bit bumpers are easy for me because I employed such things almost 30 years ago. The only modern stuff I have used is an SRF08. Since my household environment and my machine design and concept only requires 6 inches, or even less, of "notice", I need to become familiar with IR on IC2.

What I REALLY need is to figure out a way to employ a LOT of bit sensors. I am fairly certain I can do just over 100, but I would really be happy to be able to do much, MUCH more, both input and output. All ideas are welcome!

Remember, I am a novice and need to be treated that way or I will not learn . . . fast enough.

--Bill

[Admin]

Whoa thats a lot of motors!!! 

It might be hard devising a controller that can do 8*5 = 40 motors . . . And then you need like 40 encoders!!! I strongly strongly recommend only using servos to save you the control pains. You will probably either need two microcontrollers and/or use a shift register IC to multiplex your D/O (digital outputs, required for controlling hardware through software) . . . A microcontroller usually doesnt have more than 20 D/O. With 40 motors and 40 quadrature encoders (bi directional) thats 120 D/O . . . with servos you just need 40 D/O.

For PID, I wrote something up here:
http://www.societyofrobots.com/programming_PID.shtml

I think you might want to scale things back for a bit and build a simplified prototype first. Your project sounds very hard even for me. For example, make your project to just build one leg. Forget the rest of the robot. Just get one of your 5 motor legs to work just like you want it. It's a much easier task. Build several versions till you perfect it, then try to build the rest of the robot. This way you will know the exact weight a leg can lift, how much each leg would weigh, exact current requirements and control D/O you need.

A leg with 5 motors will be just like an arm with 5 DoF (degrees of freedom). You should look up technical details on how robot arms are built. My next tutorial will probably be robot arm related so you might be in luck.

As for trying to implement that many sensors . . . that is actually an area of state of the art research right now. Exactly how do you implement 100 in a functional manner? Maybe easy . . . but what about 1000, or 100k? The human nervous system has millions . . . Ive been working on a theories to attempt it, but havnt quite figured it out yet . . . Most hobbyist robots dont exceed 5 sensors . . . I think the most I have used is 11. g'luck! 

[dunk]

hey seal killer,
so the link you sent: http://www.robot-electronics.co.uk/shop/USB-I2C_Wireless_Link2039.htm
looks very promising for the way you want to do things.

i actually used the same EasyRadio modules they use to build a set of very similar modules.
i connected one module to my PC serial port and the other lived on my robot attached to a controller which acted as i2c master.
in this way i was able to build my bot in a modular fashion. one controller for power management, one for servo controll, one for sensors, etc.
this approach would also be ideal for your project as you could have multiple modules for motor controll and sensor input, etc.

the i2c bus allows for 127 device addresses (even if the bus it's self wouldn't be capable of supporting that many without some sort of amplification....).

i'm not sure why the GPIO14 module on that site will only allow 8 devices (probably they only allowed for that many addresses in the firmware) but it's easy enough to make your own i2c I/O controller if you are willing to dive into microcontroller programming.
here's a link to some sample Microchip PIC source code that could easily be adapted to work as an IO controller: http://ww1.microchip.com/downloads/en/AppNotes/00734a.pdf

if you were to buy a PIC programmer,
a copy of this book: http://www.amazon.co.uk/PIC-Practice-Introduction-Microcontroller/dp/0750648120/sr=8-1/qid=1158855225/ref=sr_1_1/202-1476890-6412640?ie=UTF8&s=books
and a few PICs (you want to get the ones with a built in SSP port to do i2c in hardware),
you would have the ability to build your own controllers to add to your i2c bus in no time using some of the sample code on Microchip's site.

note: that the i2c bus has a master device controlling the bus (the CM02 in this case) and multiple slave devices (the GPIO14 here).

so, i've allready completed a similar (although far less complicated) project of my own in this fashion so if you have any questions, ask away and i'll see if i can help you.

good luck!

dunk.

[seal killer]

Admin and Dunk--

Thank you for the great advice.

Admin, I do plan to model a leg; probably two since they will be joined by a hip. The leg itself will not resemble the final product very closely, but it will allow me to experiment with the five motors, encoders, and any other I/O I need.

Back in the "old days", I built machines using bumper sensors and two serial ports were MORE than enough. Today, if I had a 1000 bits of I/O, I would use a thousand and want 500 more! (On a completely theoretical note, how about some form of DMA to create a 1k bit I/O transfer directly to RAM?)

Like dunk says, the I2C bus may hold forth a lot of promise for an application like mine . . . assuming I can become an electronics expert or something close to it.

I will read your PID link. Thank you.

dunk, I am not sure why the GPIO14 module will only allow 8 addresses. Even I know that the I2C bus has provision for 127. I have been looking at the BASIC Stamp 2p40 module. It appears to have real possibilities in a more complex scenario. I do now know enough about them yet to know whether there is a way to "network" them in a fashion that will allow me to communicate wirelessly with a PC or a network of PCs (the latter being my desired goal).

--Bill

[seal killer]

Admin--

This I/O deal is REALLY a big issue, isn't it? There needs to be a thing that will allow you to have not hundreds, or even thousands, but as MANY AS YOU WANT I/O ports. Each port should have an interrupt dedicated to it to eliminate the need for polling. Maybe it would be called the Super Controller or the I/O Machine. It should be mobile and rugged so it could live on-board. Of course, it has to be wireless to communicate with everything in the world, including the network of PCs dedicated to the machine it controls.

Of course, you could kinda emulate this by giving each port its own ip address and ether-enabling them. The machine's sensors would each have an ethernet port, or ports, and form a "RAN": Robot Area Network. (Gee. I should forget everything else I wrote and just copyright that acronym! <g> ) But, the acronym "RAN" conveys what I am trying to describe better than the words I've used previously.

Let's invent it.

--Bill

[seal killer]

Admin--

Gee. I think the "RAN" idea is simple. All we need are ethernet enabled serial ports using an RJ11 connector. A compact 24 port switch (for starters) might have to be designed. One of the switch ports would be connected to an 802.11g or i wireless module.

You probably have one laying around.

--Bill

[seal killer]

dunk and Admin--

Man! I am glad I got back here before you hammered me on that ethernet RJ11 thing! I have been out of the shop for WAY too long!

B&B Elecctronics builds custom serial stuff. I wonder if they would talk to me? Eventually, EVERYTHING is going to have an ip address and our little I/O problems will disappear as if by magic. But, I want it now.

--Bill

[Admin]

Eh, but then you got the problem of a 100 ethernet transceivers to fit inside a single robot . . .

[seal killer]

Admin--

Yes. I know. But an ethernet transceiver can be made much smaller. I think the problem would be the switch one would need to truly connect a very large number of ethernet modules to the backbone. As I have mentioned/implied, one day your watch will have an ip address, along with everything else.

I am in the very midst of a HUGE tile project. (I did not know what mortor even LOOKED like prior to tackling this project!) In the meantime, I am doing product research and trying to learn enough electronics to build this machine, which I hope to make look cosmetically like a baanth. (I forgive you and everyone else in advance for not knowing what a baanth is.)

I believe I have found a very good motor source at Banebots. I received two 16mm motors rated at 6v, 126 rpm, 126 oz-in stall torque, and 26 rpm, 535 oz-in stall torque, respectively. Before I make a decision between the two, I will take a look at their 276 rpm, 50 oz-in motor. After that, I will build a full-scale leg-hip-leg model to test various motors. Fortunately, the motors that will do the job are all in the same series, but with different gearing, therefore they are all the same size (within 0.2 inches). STANDARDIZATION RULES!

I have discovered that the screw drive I will use is, in its commercial form, called a ball screw. Examining the literature has given me some simple ideas to make my screw drive much more robust, although it will not be a ball screw.

The ethernet idea is a true pipe dream at this time. (Too bad!) However, I will build this thing even if I have to cheat to do it. It will make my wife happy.

--Bill the baanth builder

[Admin]

Haha make your wife happy? 

Man, my gf was lecturing me last night about how much it would mean to her if I built her a robot and gave it to her as a gift . . .

[seal killer]

Admin--

Haha make your wife happy?

Sure! Who do you think pays for all this stuff?

--Bill

[dunk]

haha. wow. i have a girlfriend who would like nothing more than a house without robots and computers.
she doesn't seem to understand it's just not a room without at least one computer in it....

so i got to thinking, programming a microcontroller to make an i2c I/O controller may be an over complicated way to do things.
so i went searching for ready made i2c I/O controllers.
there are indeed a few on the market.
the problem is most of them you can only assign a limited number of i2c addresses.

philips do a range:
http://www.nxp.com/acrobat/applicationnotes/AN469.pdf

and microchip:
http://www.microchip.com/ParamChartSearch/chart.aspx?branchID=11034&mid=11&lang=en&pageId=79

so most of these have a limit of 8 addresses or less (selected by 3 input pins).
to use these devices on the sort on the sort of scale you are talking about i'm not sure 8 I/O chips would be enough.
the larger ones do 16 I/O ports each.
not really the sort of large sensor network your looking for.

so what options?
there is one i2c I/O device i found that can have up to 64 addresses. its the PCA9501 on the philips datasheet.
the only problem is it's only available in surface mount packages with teeny tiny pins.
not the easyest thing to experiment with.
you would need to either start making your own printed circuit boards or have them made for you. (i have never done either myself so i can't really comment on them.)

the other option is back where i started:
program a microcontroller to do the job.
with a microcontroller you can give it any i2c address you want.
this option also has it's own leaning curve.

there may be a product out there that does everything you need.
ie, lots of available addresses, lots of I/O pins and no complicated programming. all in an easy to use packege.

ok, rant over.

let us know where you end up going with this. you have me interested now.

dunk.

[Admin]

Or you could use a shift register IC, where you only need 3 pins to control up to 64. A microcontroller with 9 D/O can control 64 x 3 = lots.

[dunk]

yes indeed.
found this application note from Philips last night that describes just that:
http://www.nxp.com/acrobat/applicationnotes/AN036.pdf

for those who can't be bothered reading it, the pdf describes how to take a bus of 64 inputs (switches in their test app) and clock them into one bit pin on a microcontroller and send the output on the I2C bus using shift registers. it describes the same process for outputs too.
although it describes only 64 bit input and output, there is no reason this technique wouldn't work with lot's more I/O pins.

not the simple "one chip per module" solution i was thinking of but definatley a solution that would work.

note that this pdf doesn't make for the easyest reading but once you work out what the 74HC165 and 74HC595 shift register IC do you can skip to the
circuit diagram on the last page.

also note that this pdf describes using philips microcontrollers. i have never heard of these being used by a hobbyest. it would probably be easier to use either Microchip PICs or Atmel AVRs. but then, hey, Bill's never used any microcontroller right? so might as well jump in at the deep end....
(seriously though, if you want to follow the microcontroller route i'd recommend either Microchip PICs or Atmel AVRs. both have their advantages but for the beginner i'd say PICs have the slight edge as they have been around longer so there is far more example code on the internet.)

dunk.

[seal killer]

dunk and Admin--

Well, the shift register really seems to be the way to go. So, I bought some training stuff from Parallax (hardware and software) and will mount that learning curve even at my advanced age. The schematics appear fairly simple, even to me.

--Bill