Well, cutting a VERY long story short, all the Acroname Moto 1.0’s, BrainStems and other assorted goodies don’t work the way Acroname states on their website. I’m looking for a fully autonomous rover, one without a tether, without having to rely on wireless communications with a PC/Laptop computer for it’s ‘smarts’. Acroname states that all their products function in an autonomous fashion, which I now find out isn’t the case unless you are willing to shell out $695.00 + shipping for their Stargate X-Scale MPU. This then makes their Moto controllers, cameras, and BrainStem units nothing more than ‘accessory’ items. I’m lost and without direction with this project. I spent enough with Acroname already and don’t feel like giving them any more money. Especially since they advertise their product line as something it isn’t. I am looking for alternatives to the Stargate X-Scale MPU. I’m even looking at using the PIC 16F877A or something along those lines. I have Parallax Basic stamps but I’m concerned that they will remain incompatible since only the BS2p40 handles limited I2C communications. Can anyone lend a hand to help me sort my problems out? I really appreciate any and all comments. Thanks for your time!
Were you able to do anything with the solutions cubed link I told you about. They should have a module that can easily handle the motor control and quadrature encoder issues you have been dealing with. 8)
Thanks as usual for your reply. The answer is yes, I did look at the Solutions Cubed alternatives. I even own two Motor Mind B units, since my controller of choice at one time was the Basic Stamps. This is the the thing that is driving me to the brink of insanity at the moment. Acroname’s Moto 1.0 controllers function exactly like the Solutions Cubed controllers. They offer the PID control, EEPROM set points, and encoder/tach features. However, Acroname stated that the BrainStem units interfaced directly to the Moto 1.0 controllers via I2C communications and would process all the encoder data directly via the BrainStem module. After many emails to Acroname, they came right out and told me that it wasn’t possible. I was told that the amount of data that would have to be processed would exceed the capability of the BrainStem controllers. I’m only looking for simple navigation, not mapping or anything involving high level mathematical computations. But it’s clear from Acroname that the BrainStrem cannot handle much more than ‘reflex’ actions. Meaning that if a sensor changes state, the BrainStem can react to that and with the proper (read) X-Scale MPU can change the state of the various other hardware to avoid objects, etc. I’m totally lost at the moment.
The Hammer looks like the winner! At $159.00 + shipping it’s a steal. Since I am a LONG time Linux user, that is a big plus. I’m sold! Thanks to both of you!
I don’t know that an '877 is going to take you very far, but an 18F part might help. The “Star Gate” you mention IS quite powerful! Dale and I are discussing ARM7 and ARM9 boards as well as PIC boards, but the Intel uP on the Star Gate board would appear to be above that!
Are you sure you don’t have a little room for some small “TEA” routines on your board? It DOES seem like Acroname’s plan is to run these Brain boards as lower level boards in some sort of hierarchical architecture. I believe you can talk I2C to your Brain board(s), so maybe try an 18F4620, or one of the newer 30F parts. I’m starting with a $15 bare board that takes the '4620. I’ll stack them when I need more.
If anyone looks at the activity on the Acroname forums (or lack thereof) it kind of sheds some light on the interest level in their product line. I wonder why
Thanks for the reply. According to Acroname support, no amount of TEA programming would allow for the type of control I’m looking to do with the Moto 1.0 controllers. The BrainStems according to Acroname just aren’t designed to do much without a higher level controller in place. Clearly Acroname should be more specific about the way the BrainStems function on their website. They leave you with the impression that they do more than they are capable of on their own. I guess for simple stuff they are great, but take your project to a higher level and they simply aren’t worth purchasing. I was thinking about ‘networking’ the BrainStems and Moto 1.0 controllers, but alas, I read a few documents on the Acroname website that said too much traffic over the I2C interface was a bad thing. Guess it leads to device contention, or maybe data loss. Perhaps the interface just isn’t fast enough to process data at the rate it would be coming in. On the other hand the lack of documentation regarding TEA programming is quite sad. I’m great with Basic Stamps and PIC’s in general, but TEA programming is not my strong point. I know it appears to be C like in syntax, but with a twist. Again, the documentation regarding TEA programming on the Acroname website is just too general to be of much help (especially at higher level stuff). Everything seems to be ‘example’ based, and is modeled after the projects that Acroname has developed. I really don’t want to give up on this project. But maybe I would have been better off spending my money on hardware other than Acroname’s. I probably should have done more research first.
That’s truly too bad! It’s always hard to see what’s needed at the start of a project. But it does sound like they need to do a little better job in the write-ups. Nobody, that I know of, has done (and released) anything really “higher” in robot controls (other then commercial, and you’d really have to pay for that).
I suspect that running EVERYTHING over I2C is just too much to handle. I’m hoping to be able to spread my reactive (Subsumption) modules out over one or more boards, with limited inter-board communications.
I almost hate to see TEA or some other such “new” language spin-off of C. Embedded C works fine for our applications. I even started to research a described “Subsumption” language for robots, but it turned out to be Forth, and I couldn’t find much at all for the definitions of the state-machine “subsumption” parts they apparently added. I do state machines all the time, and even the AFSMs I found out. I’ve got books coming (Christmas?) that might give me a better view of what Rodney Brooks (MIT) had in mind. If you’re interested, join us in the IK group.
Subsumption is not a language; rather it’s a programming technique. Same with FSM, it’s a completely different way to program using any language.
One example of FSM requires knowing how long it takes for x-amount of program lines to execute and then take that number as a base number which will be the amount of time it takes to send a pulse to a servo. As an example, if a servo requires a pulse every 2uS to make it move, your code needs to take 2uS to run, eliminating the need for a “pause 20”. This frees up the bottleneck and you can actually run several tasks in one sweep so long as it does not exceed 2uS. It’s a lot more involved, but in a nut shell there’s the basic idea. For me it’s to complicated and mind bending for my taste.
SUBSUMPTION is VERY MUCH a LANGUAGE, as well as a programming technique!
Well, maybe a dead language, but it was written by or for Brooks about 10 years ago. And as I mentioned, there is a FORTH-like language that it appears might be attempting to resurrect it; but I’m not a FORTH fan.
And there are plenty more references to “Subsumption Languages”.
Subsumption appears to be built on FSMs and AFSMs (Augmented Finite State Machines).
FSM has NOTHING to do with “knowing how long it takes for x-amount of program lines to execute and then take that number as a base number which will be the amount of time it takes to send a pulse to a servo.” This is simply the way the Atom 'Bot code was implemented to avoid sending out commands to the SSC32 too fast. This is NOT an example of an FSM. Maybe call it “balancing tasks”.
An FSM can be hardware or software. It is basically a set of states that an aspect of a program or hardware can be in. An example of an FSM is the stoplights on the corner. The various “states” the lights go through are an often quoted example of an FSM.
A state machine would be (IS) a good way to implement the sequence of finite points a leg might go through to complete a cycle of motion in response to IK calculations. Move the foot up, move the foot forward, move the foot down, move the foot back, etc. See an example in the SSC32 manual.
There is nothing terribly “different” about writing an FSM in software. It’s just a deterministic way of controlling the program so that certain events are always in a known, highly predictable state. Yes, you should be able to write an FSM in any language that has a conditional or case/switch statement. It’s a fairly small, but significant aspect of good (deterministic) control programming.
To implement an FSM in software, use a case/switch statement in a function (subroutine), keep calling it. Each time it is called, determine if conditions have met to change the state of the function, and if so, advance to a new state which will ALWAYS be in the case/switch (increment or change the variable of the case/switch statement). Possibly DO something in the new state. Return to the caller, wait for the next time (usually set up by a regular interrupt at a pre-determined rate) that the function (routine) is to be called.
I don’t want to argue but if you read my original post in regards to FSM, I said it was ONE example! I have read this stuff a long time ago and understand the general concept.
And Subsumption is NOT a language. The article I read discussed Subsumption using Pbasic - Pbasic is the language used to write subsumption modules. Also the link you posted:
“*This invention allows term subsumption to be used with existing commercial rule-based shells by translating a term subsumption representation directly into conventional rules and allowing subsumption definitions to be encoded in a “rule-like way”. *”
What this said is you are using an existing language (basic, C++, visual basic, etc…) and coding a sort of embedded language. So we are both right in a sense. There is no Subsumption language, you have to code it in.
Correct. Subsumption is but one type of programming architecture for behavioral based robotics. There is no specific programming language attached to subsumption. It’s just one of many different ways of doing things.
I haven’t even begun to scratch the surface of behavior based (or reflexive, in Acroname’s terminology) robotics. It’s a facinating area, and I want to do much more with it as I learn more.
I have tried to use it with Pbasic and got it to semi work but it got complicated with the PING sensor and my custom sound sensor board. I quit trying to get it to work to any satisfactory level because the SSC-32 offloads much of the work of the MCU, which I felt it was just easier to stay within my ability to program using conventional methods.
When used properly (talking about using FSM), you can take a slow BS2 and make it virtually multitask several things at once. I think I will try to use Subsumption to some degree, but definitely not FSM. The best part of Subsumption is the modules; you can add new behaviors without having to go back and change your code throughout your program, and you can reorder them if you want!
I wish I could program like you but I just can’t think logically which is what a person needs to program well. I also am very poor with math.
Yes, FSM is a method of programming. What’s NOT correct is your supposed example taken from the Atom BASIC code.
I’ve SEEN the user interface for the program; there is a Subsumption
Compiler written for the 68K.
*“The subsumption compiler compiles augmented finite state machine (AFSM)
descriptions into a special purpose scheduler to simulate parallelism
and a set of finite state machine simulation routines. This is a
dynamically retargettable compiler that has backends already for a number of processors, including the 68000, the 68HC11, and the 6301. The subsumption compiler takes a source le(sic) as input, and depending on the target machine either produces an assembly source le(sic) or an encore(sic) data structure that can be assembled by some other assembler.”
“The subsumption compiler can then be used to compile to the various targets. Some enhancements were made to the original subsumption language in order to support the behavior language.”
I HAVE done some research on this topic, and I try to get my facts straight. Still a LOT to learn, 'tho. I’m expecting some books for Christmas. I did find a better (PDF) “User Guide” for the “Behavior Language”, I’ll post it in the files.
The Subsumption Language is probably more like 20 years old ('86).
The SSC-32 doesn’t has any bearing on subsumption at all. Yes, the SSC-32 keeps things positioned and refreshes the servo positions at the required rate. However, this has no bearing on subsumption, one way or the other or getting it to work. The SSC-32 is an effector, not a facilitator. The SSC-32 does not do anything it is not specifically commanded to do.
I am having difficulty buying this, sorry. Not even a Basic Atom (or even Atom PRO) can do anything that even remotely resembles true multitasking.
I can not define two tasks to execute concurrently on any of these MCUs. The very best I could hope to achieve is very fast round robin processing. I have not spent enough time with an Atom PRO to know exactly how fast it can process or how far I can push it. However, I do know how far I can push a Basic Atom, and I am very close if not rght at its limits with my “Subsumption Engine.” What I have is not a true model of subsumption though, because I do not have any true multitasking capability in the Atom MCUs. I have a main processing loop that hopefully gets around to everything fast enough to react to sensor triggers. I think I am just asking the Basic Atom to do too much right now.
Subsumption is defined by FSMs and/or AFSMs, so I don’t see how you can avoid them. There must be triggers that activate each behavior you want to define. These triggers have to be, by definition, finite. That sounds like an FSM to me.
I believe I am a reasonably competent programmer, in a few different programming languages. However, there are some things I would like to be able to do, such as graphics programming, that I just can’t get my brain to wrap around. BUT, give me a tool like subsumption, and I can do some very cool things! Programming my “Subsumption Engine” on the Basic Atom has given me a small taste of what is possible with more processing cycles, if not true multitasking. I have modeled what I have done so far on what has been done by the guys of the DPRG.
Once I get a good handle on how to program my two LPC-2148 ARM7 boards, I am going to be doing a lot more work with subsumption. I may even try doing some stuff with subsumption and an Atom PRO at some point, but am leaning away from that path at this time.
Now that I have also discovered the Hammer (ARM9, full Linux capable) MCU, I am even more excited! I can see a full blown embedded Linux system being put on even the smallest bipeds such as the BRAT. I have already started a dialog with one of the fellows at Tin Can Tools (makers of the Hammer).
Programming my “Subsumption Engine” on the Basic Atom has given me a small taste of what is possible with more processing cycles, if not true multitasking. I have modeled what I have done so far on what has been done by the guys of the DPRG.