Some amazing video of Vstone Robovie-M

Yeah, I've downloaded just about everything I could find on the web. They variety is impressive as is their capabilities. I've currently got about 700 Megabytes of video and pictures on the various robots.

Sounds good to me.

Do you have any pictures available?

That's what I'm worried about mine. I'm only using 40 oz-in servos at this time. I'm planning on running them at 7.2 Volts which should increase the torque up to about 60 oz-in but I'm still worried they'll be too weak. If so, I'll upgrade to better servos.

I can already see the need for my own "Rev B" but I want to finish what I've got so I can work out all the new measurements and such for Rev B.

Yeah, I think that's how my next one will be. I just thought that the Robo-Vie looked so cool and had some good design features, so I decided to do that as my first one.

Currently, I have a servo controller controlled by a laptop. I'll probably be using an AVR-based controller. I'm currently working on a board that will use a Mega32 controller with extra flash memory.

Cheers, Ed L

Reply to
Ed LeBouthillier
Loading thread data ...

Unfortunately, FORTH is only as ugly as the programmer makes it, with the exception of using stack based manipulations, which are never fun to read until you become an expert.

The neat thing is that 12 servos don't even phase an Isopod.

Mike

Reply to
Blueeyedpop

Ed,

If you are looking for new servos. I these for only $14.95 a piece.

formatting link
Perhaps a little slow, but over 100 in/oz of torque @ 4.8 volts seems like a really good price. Up the voltage a little and they might work with your project very well. I'll be using them on my project. S06STD Specs: Size 1.60" Long x 0.79" Wide x 1.69" Tall Weight 1.69 oz 60° Rotation Speed 0.33 seconds @ 4.8v (0.27 seconds @ 6.0v) Torque 100 oz-in @ 4.8v (111 oz-in @ 6.0v) Operating voltage 4.2 - 7.2 volts DC Max Operating current Bearing type Self lubricating Bronze Connector type Standard 3 wire Futaba plug with 10" wire lead Included accessories 6 different servo horns, mounting screws/hardware

Tim Dale

Reply to
Tim Dale

Your biped is looking good. After I finish my hexapod and get a little experience in programming Atmel AVR chips I am going to attempt to clone your clone. It is the coolest bot I have seen. Hopefully you will be willing to share some of the code since I too will be using an AVR :-) Keep up the good work, it looks like you'll have an awesome bot soon.

Tim

Reply to
Tim Dale

Only 13.95 in quantities larger than 10! That's pretty impressive.

Cheers, Ed L

Reply to
Ed LeBouthillier

I guess beauty is in the eyes of the beholder. I tried varoius different ways to write the Fourth code, and downloaded NUMEROUS examples from any site I could find in hopes of finding some "nice" looking Fourth code. There is no nice looking Fourth no matter who the programmer. The thing is, it's so simple when you are looking at a small code sample. It's only later when I have hundreds of lines of code that I realise that it has become ugly and difficult to read and follow (and that's the code I am actively writing, not something I have come back to a year later!)

My take on it is simple: Source code is for PEOPLE. Processors understand bits, you know 0's and 1's. C, Fourth, Basic, Java, etc. and even ASSEMBLY are for PEOPLE. The whole purpose of a programming language is to give a PERSON a more human language to tell the processor what to do. The compiler or assembler takes the human language and translates it into the processors language.

If the code you write is difficult to read or understand, then you have completely missed the boat.

Source code should be BLATANT, never "clever" (look! I managed to get this

100 line function down to 17 compound lines with 7 funky conditional nested for-nexts, some recursion, and 13 entry points and 5 exit points!). Yeah, real clever chief. I hope I never have to debug it. Clever code tricks are really great, but difficult to follow. They make you slow down and take the time to trace the code. Just make it blatant, so you can see what it does immediately and simply. I promise the processor will not judge your code, it has no appreciation for cleverness, and other programmers that follow you will not appreciate your cleverness either (when it takes them an hour to figure out what your clever routine does). I dare say, you will probably not even appreciate it very much a year later when you have to go back and visit it for some reason.

So to that end, the Fourth is out.

That is what drew me to the ServoPod in the first place. It's also a total bonus that it can be programmed with a simple text editor and a serial terminal program. No $pecial hardware or software tools. I'm still a fan of the xPod hardware, but the Fourth language just does not cut it for me. I'm sure there are some who find it a beautiful Language, but then there are people who think it is a beautiful thing to hang from hooks embedded in their flesh. It takes all kinds. More power to them all. The world would be a boring place without the great variety of interest and style.

--Steve

Reply to
Steve Bates

Are you in North America? If so, what state?

Yes, I have a few. I just don't have a good place to post them. Plus, I tend to spend most of my free moments working on robots and find I have little time left to post my pics (or even take pics to that matter). When I have some up, I'll post here.

I'm actually on Rev C. My Rev A was just one leg and was made out of plastic. It was too "soft". The positions were not repeatable and it would "give" a little under load. Worthless. So I immediately went to Rev B using .050" aluminum. I designed a "servo shell" with mounting holes and pivot points at strategic locations and had a local metal shop make some. I'm still using them in my Rev C, but in Rev D I have a much better design for those. I got a CNC mill to make more precise parts, and a vice mount metal break in order to make accurate bends. It's all going good now!

I've been back and fourth on the top twist or bottom twist. Either way, there is a lot of off-axis torque on that joint, and even with the ball beraring servos, it still needs an additional large diameter bearing. The Robo-Vie (and your version) look like just a washer. I got some "thrust bearings" from "Small Parts" and I'm gonna give them a try.

Yeah, I'm going to an AVR seminar in a couple of weeks. After the seminar, I will be able to pick up an AVR JTAGICE on the cheap.

--Steve

Reply to
Steve Bates

California.

That would be great.

The right tools definitely help.

Eventually, I'll want both top and bottom twist. I want to try to get 14 DOF's on the legs. That's what humans have and I think for some kinds of "natural" motion, it will be necessary.

No, both the Robo-Vie and mine use AXK thrust washers. It's absolutely necessary (as you point out). Look at the last pictures I posted. Right at the joint between the flat sole and the machined aluminum piece is a grey line; that's the thrust bearing.

It doesn't really matter which processor you use; each has their benefits and problems. I personally like the AVR's but I have to admit that some of the newer model of PIC's are nice. Additionally, there are some good capabilities on the lower-end models of PIC's as well.

Cheers, Ed L

Reply to
Ed LeBouthillier

I found an even cheaper source for servos.

formatting link
has the same servo listed below for only $10 or for $11.25 you can get it with Ball Bearings. I found my new servo supplier :-)

Tim

screws/hardware

Reply to
Tim Dale

Wow, that's cool. I might have to update to those if they have such higher torque and fit in the same package.

Cheers, Ed L

Reply to
Ed LeBouthillier

To me, the only really difficult stuff is the stack stuff. Other than that, I just use a LOT of english readable names, and try to factor things into useful chunks.

I shy away from the stack, unless I am running into speed issues.

Still, if the Forth is killing you, there is still Small C

Reply to
Blueeyedpop

My Forth has improved from what I wrote twenty years ago, but I can pick up my code from 20 years ago and read it with ease. The most important thing it to use factoring into very small routines so that most Forth words are one or two lines long. Run-on code is pretty common in most languages but is considered horrible in Forth.

Yes indeed. The advice from Forth's inventor is to write code that is brutally simple. So simple that errors are nearly impossible. That is why most definitions (functions) should be one liners.

That was exactly the stated purpose for the invention of the computer language FORTH. Of course it has changed a lot in the last fourty years. More people know make more effort to make their code as blantant as possible.

Yes, and when the processor's language itself is Forth this can make the complexity of the compiler/assembler almost trivial and greatly increase the blatant nature of source, greatly decrase the complexity that a programmer has to deal with, and greatly increase performance. I do realize that you were talking about a Forth implemenation on a more conventional processor, but it sounds like your Forth code is your problem.

Forth has been described as an amplifier. Code good ideas they become better. Code bad ideas they become worse. It is very easy to write terrible Forth code by just trying to write in a style appropriate for some other language.

Yes. One should always be able to read their own code. Sometimes someone else code can be quite good, but difficult to read by someone who does not understand the language.

Cleverness is fine as long as it get explained somewhere for the less than clever reader. Blatant, brutally simple code is the ideal.

Surely you are not talking about Forth code? Rules of thumb there recommend one or two line functions, not 100 line functions, one conditional per definition not funky nested conditionals. Recursion is sometimes used when it can simplify things. Multiple entry and exit points are not a problem when one sticks to one or two line definitions for the most part.

Writing a 100 line application function in Forth is definately abuse. If someone abuses the language the results will be predictable.

Surely you are not talking about Forth. One reason for writing one or two line Forth words (functions) is to test them incrementally and more on to the next word confident in having debugged up to that point. The idea of writing an application word with 100 lines and with deeply nested funky conditionals, recursion, and lots of entry and exit points is very very bad. Don't even think it. Write a line, debug it. Move on. Make it blatant and simple and easy to read.

Right, some languages encourage functions that fill a page or even multiple pages. Forth doesn't. Make it blanant. Make definitions this long. Make it simple. That's what works.

Exactly. That is the idea behind Forth. If anyone tries to write Forth in run-on style they will have trouble reading and debugging their code. Don't do that.

If they know the language and the problem domain then the code should be pretty obvious. If it is not completely obvious there should be some comments explaining anything clever.

Since Forth is extensible the meaning is based on previous definitions so application code taken out of context will make no sense. It is easy to do that with most languages but easiest with extensible languages.

It should be as readable as natural language twenty years later. It should be fairly readable to someone who has little experience with the language. If well written even your manager should be able to read application code with little context. To do that you have to choose very clear names for the words. The style of programming that is required is significantly different than it is with languages that use run on names and run on code but which are designed to work that way.

Forth is not for everyone. Forth requires a different style of thinking and coding than many other languages. It requires that a programmer be responsible as there is little to stop them from writing bad code if they know no better. The freedom and control that it offers require responsiblity and are not for those who will abuse the freedom.

Forth is used a lot in robotics because it is a good fit. It is used a lot in embedded systems because it is a good fit. It has been used in lots of spacecraft and sent out of our solar system because of the small footprint, high performance, reliability, and its flexibility in dealing with the unexpected problems in the most hostile environments imaginable. It is used in many system on the Space Shuttle. It is used in many miliary systems that carry a very high risk if they don't work right. It is used in the auto industry, entertainment industry, and is in lots of consumer devices that people own but don't think of as computers.

Forth can be a dissaster in the hands of someone who doesn't understand it or doesn't know how to use it. Best that they should avoid it and do what they prefer and what works for them. Any Forth hater can prove to themselves that Forth is bad by writing bad code. Learning to write good code takes a little bit of effort. It can be difficult for people who are trying to impose ideas and style from other things in a way that is just plain nuts in Forth.

The other side is that Forth can do truely amazing things in the hands of someone who understands how to use it. People who want the power and freedom that it offers tend to love it. It offers unparalleled ability to debug and use new hardware. For robotics and embedded systems it has enourmous power. One downside is that there are many more programmers available for coding in other languages which is one reason that it isn't used more.

Many big companies that use it like to keep its use a secret because it is one of their advantages over their competition. Most people know that anyone who claims that it is useless or unreadable is usually just talking about their own terrible code.

Best Wishes

Reply to
Jeff Fox

My Forth is some of the worst I have seen. I usually keep things grouped to

8 lines or so per function, with my main function being up to twice that. I am reasonably good at factoring the problems out though, but like to group similar operations together too often.

Then again, my assembly, BASIC, C,C++, Java, LabView are also some of the worst I have seen as well.

Forth is definately not for everyone.

One thing I always thought was its major strength and its major weakness, was once you start "mucking" with it, it really isn't Forth anymore. It is a custom language specific to the task at hand.

If you can keep that in mind, and write your words to be specific to the tasks you are performing, your code can be "prettier", but if you try to plow a course straight to your final goal, you end up with a useful end function, with altogether too specific words in between.

The opposite of that, in my opinion, is overfactoring, which although I have seen rarely, can be amusing when trying to recycle words written for one purpose into another.

Mike

Reply to
Blueeyedpop

I agree with you on that.

"Mucking" with it is not recommended. You are right that the idea is that Forth is the metalanguage that you start with, you use Forth and extend it towards a well considered application specific language in the process. If done well you end up with a nearly ideal language to describe and solve your problem, it should read almost like English at that point. All strenghts are also weaknesses.

You have to learn how to make a consistent whole, something that isn't layered as system, forth, your own language, your solution. Thinking in that kind of layering is a carry over from environments that try to segregate functions and programmers and limit the scope and understanding of programmers to specific layers. Anyone who approaches Forth in that way will be making obstacles for themselves. Those things are both the strength and weakness of other approaches but don't match well to Forth.

Bad factoring is easy to do. Overfactoring is nearly impossible. Think of factoring as something analogous to Ziff-Huffman compression. The idea is to reducde the complexity to the true effective complexity of the problem rather than dealing with the raw complexity. The idea is to express and solve the problem with the simplest description possible. The hardest part of doing it is throwing out all the ideas that people tend to carry in with them from other languages and end up simply expanding the problem that they want to solve by adding constraints rather than removing them.

Best Wishes

Reply to
Jeff Fox

Lynxmotion appear to be bringing out their own biped as well.

See......

formatting link
BPS Robot Specs

No of DOF per leg = 5 Servo motion control = local closed loop Height (as pictured) = 9.5" Width (as pictured) = 7.5" Ground Clearance = 5" Weight (without batteries) = 29.7 oz Range of motion per axis = 180 degrees Accuracy of motion per axis = Servo controller dependant (usually .72 degrees) Servo voltage = 6 vdc

formatting link
I'm sure it'll be expensive though.

Allen

Reply to
Allen Foster

Yeah, I've seen that before. I really like the look of the Robovie-M; I alos prefer the higher degrees of freedom. The thing I like is the "humanoid" aspect of these robots. But it's all preference.

Cheers, Ed L

Reply to
Ed LeBouthillier

Mine has improved also, but I have never seen a single example what I would call "nice looking" fourth.

We sing the same words but to a different tune. The stated purpose is my mantra.

Indeed, I was talking about a more conventional processor, but even a native fourth processor is ultimately a CPU having basic opcodes (or words if you like), registers, memory, I/O etc., which are stored, retrieved and processed as bits. And yes, my problem is indeed Fourth it's self. I don't hate Fourth, I just think its ugly. Some people like red, some like blue. Which is better?

Replace the "Fourth" in the above quote with any language you like. The goal of software in general is to take small atoms of functionality and use them to amplify ideas into a usable form. Bad ideas are just bad ideas. That's why we call 'em bad.

Yes, and sometimes someones code is just bad and difficult to read by anyone, even those who understand the language.

No, at this point I'm in the middle of my soap box, spouting generalities that apply to most languages.

No, still spouting. You are oversimplifying here though. The real bugs we have to debug are rarely things that are in a single line. Each new word my be a simple one-liner, but in a large dynamic system, the problems may be more subtle interraction based issues. We are beating around the bush of the whole concept of objects. Small independantly testable chunks that you can use to build bigger chunks.

Some of the worst examples of Fourth I have seen appear to be someones "C" converted to Fourth. It just don't work like that.

That would be nice. Comments. I once came in behind a programmer who actually wrote comments. Easiest project I ever did. Far too often, the comments either do not exist or are fairly useless. These are usually the same ones who do the funky nested multiple entry-exit point stuff.

I was once hired to fix a bug in an application where the programmer had quit. He left the code compilable, but had run it through some application that stripped out all of the comments and white space, then turned all of the variables and function names into sutff like this "El5y47b3fbhui". The compiler did not care, but the total source code was around 250,000 lines of totally unreadable garbage. What an ass.

You are singing my song. Again, I have never seen any Fourth example that fits the above bill.

This can be said of most languages.

In what way is the Fourth language particularly flexible id dealing with unexpected problems? You were on a roll, but this part is starting to sound like propaganda fluff.

So are many other languages.

Could not agree more. Again I think this is generaly true of any language, even spoken languages. Anyone who is a lover/hater of a thing can convince themselves of its goodness or badness. I would love to see a sample of some "good" Fourth code. Not just a few lines, but a whole application. Even I can make a few lines of fourth look good. My premise all along has been that it looks great in the short haul, it's the long run where it gets ugly.

Any language.

In what way does it stand out here? How is Fourth particularly able to use new hardware? Is there someone producing ready made Fourth "drivers" for new hardware as it becomes available? If I have written perfectly readable wonderful Fourth to work my sonar range finder hardware, how is that going to help with my USB end point hardware?

I readily admit that my Fourth code looks bad, that's why I began searching for a sample somewhere, anywhere, that demonstrates that there is a good way to write Fourth. Not having found a single good example, I have begun looking for alternatives for use with my ServoPod. In the mean time I have a very small set of Fourth words that just takes serial in and control some servos. All of the smarts are off-board. To have a DSP running such pathetically small and simple code just hurts me. The DSP could be doing soooo much more. I figure that it's just waiting REALLY FAST.

Rather than imply that I rant because my own code sucks, why don't you show us a sample of some good Fourth. Shut me up with real evidence instead of cheap shots. I have only come here seeking knowledge...

Cheers,

--Steve

Reply to
Steve Bates

I guess we are just talking about two completely different languages. I was talking about Forth. You keep talking about Fourth. I never heard of that language until I read your posts. It sounds dreadful. I will go out of my way to avoid the language "Fourth" that you rant about. I would recommend that you avoid it too. If I want to know more about your dreadful Fourth language I will know who to ask.

Best Wishes

Reply to
Jeff Fox

Ok, I'll give you that I misspelled it. I know I'm the first person to ever misspell anything on a news group posting.

However, your reply is a total cop out. Another cheap shot. You make lots of claims about the fabulous nature of "Forth", yet you refuse to back them up with anything. My original post simply states that I think Forth is an ugly language that gets difficult (not impossible) to follow when the source code gets large, not that it is inherently a bad language. I don't claim that it is impossible to write good Forth, just that I have never run across any. Show me an actual example. I can appreciate that you may not feel you have the time or inclination to educate me, however you are the one who chose to reply and make various claims.

If I want to listen to more vacuous and unsubstantiated claims about the "unparalleled" capabilities of some language I'll know who to ask. Do you work for Microsoft by any chance? They also seem to have a knack for making claims about the fabulous and unparalleled capabilities of their software without ever actually producing anything that even vaguely resembles their claims. (my own attempt at a cheap shot)

Did I misspell anything this time? If not, there are probably a few grammar errors you can attack.

Cheers,

--Steve

Reply to
Steve Bates

Let me add myself to that wish list. I'm not personally involved in computer animation, but do help in the design of some animatronics. I know there is a lot of frustration in programming the movements. The process is anything but intuitive.

There are plenty of software packages for animators to help make a character walk well. But, getting that joint rotation information into a format you can use for an animatronic figure seems to be a big challenge. Somewhere I've seen a robot-simulator package... but it didn't seem to have any ability to output to a real robot.

Joe Dunfee

Reply to
Smiley

PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.