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 
Respectfully,
Michael G. Jessat
Acroname calls it reflex architecture, which would actually fit quite nicely into a subsumption behavior based software package.
Both the Brainstem GP 1.0 and Moto 1.0 modules support I2C.
8-Dale
Hi Alan,
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.
Respectfully,
Michael G. Jessat
Hi Michael,
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.
Best Regards,
Alan KM6VV
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.
priorartdatabase.com/IPCOM/000109487/
dli.iiit.ac.in/ijcai/IJCAI-91-VOL1/PDF/073.pdf
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.
en.wikipedia.org/wiki/Finite_state_machine
web.mit.edu/6.111/www/f2006/hand … /lab3.html
Not complicated at all. In fact, it’s a very clear, concise way of writing code. I find FSMs and AFSMs VERY TASTY!
Alan KM6VV
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.
Here is where I learned about FSM and Subsumption:
bluebelldesign.com/FSM_explain.htm
Here is the first sentance on that page regarding FSM:
*" A Finite State Machine, abbreviated FSM, is a method of programming. " *
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.
8-Dale
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. 
Certainly seems like you want to argue!
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.”
1990 Rodney Brooks “The Behavior Language: User’s Guide”
ftp://publications.ai.mit.edu/ai-public … IM-1227.ps
Search for “Subsumption compiler”. About the 3rd hit. It seems to be pretty hard to find info on the original subsumption language.
"The Behavior Language is sometimes referred to as the “New Subsumption Language”.
Perhaps you’d rather call it the “Behavior Language”.
of programming. "
What an FSM is was never in question. What is wrong is your example of an FSM, and your instance that there is/was no subsumption language.
Alan Marconett*
Wow, I did not know about this. Does it actually qualify as a computer programming language?
Hi Dale,
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).
8-Dale
Excellent! I will look for the new files later. If there were not always a lot to learn, would robotics be as interesting and fun as it is?
I did try to find some references to this, but all the ones that look promising seem to be buried in the bowels of the IEEE. 
No membership, no access apparently.
I did look, but apparently did not find the reference you found. Can you provide a direct link?
I did, and thanks. I have not tried importing the DXF yet, but I can definitely create a 3D model from the dimensions in the JPEG you sent. I was not able to get any dimensions from the last DXF I tried importing, but I may not be doing something I need to do to get dimensions to show.
8-Dale
Hi Dale,
Yeah, It’s a challenge! But that’s what I like!
Yeah, I run into roadblocks as well. After you’ve come up with a lead on an IEEE or MIT document, sometimes you can get the title of the “controlled” document, and find it somewhere else.
Don’t know if this will work:
This is my best so far:
ftp://publications.ai.mit.edu/ai-publications/pdf/AIM-1227.pdf
“Behavior Language” is also a good search.
It’ll be interesting to find a way to IMPORT DXF files into Alibre!
Alan KM6VV
any of you ever looked into multi-threading / concurrency for this sort of stuff to make subsumption easier to program?
Yes, I have. This is one reason I need to be using different MCU for this.
8-Dale
That’s the basic idea, one needs a “baby RTOS”. A periodic interrupt is used to call a set of functions (subroutines), each of which basically acts like a thread. No preemption, no priority to speak of, all the functions run at basically the same “level”, and could be said to be concurrent. There is no OS to speak of, and the list of tasks is static (basically a list of function calls).
On top of that, USART, I2C, and some “ready” flags from sensors or other devices run in an interrupt handler to set flags for data that is ready to be processed.
The part that I’ve yet to work out (or see documented) is a good structure for the task flags and variables that control the inhibiting of tasks, i.e., the ability to subsume subordinate tasks. I also want to be able to run the 'bot under different “attitudes”, i.e. changing the way the 'bot responds to stimuli. Plus who know what else! I’ve a lot to learn about Subsumption. Luckily I found out that the FSRs I’d been writing for a long time appear to be at the heart of the Subsumption modules. AFSRs as well! …But I don’t claim to have all information needed yet!
I believe there is already a framework or syntax for generating Subsumption modules, it started out as the “Subsumption Language” some 20+ years ago, and quickly was absorbed into what became the “Behavior Language”. This paradigm is still popular today, and Subsumption today is often referred to as a “programming technique”.
Apologies to Michael, this thread seems to have possibly been overrun with talk of Subsumption, FSRs, and all that.
Alan KM6VV
Hello All,
I want to take the time to personally thank each and everyone of you who replied to my post. You have all given me more insight into my problem(s). As was previously stated by myself and other respondents, Acroname should be more clear about what their products do and don’t do. But it is glaringly clear based on the lack of traffic on their forums, and the amount of unanswered questions within those forums that they aren’t the best choice for hardware or support. I’ve decided to abandon the use of all Acroname hardware in my project(s). It simply isn’t worth the effort or heartache I’m facing at the moment. All that money spent could have been better applied toward hardware that actually works as advertised. Guess I’m down to parking another failed project on the shelf 
. Thanks you all again, I appreciate the help.
Respectfully,
Michael G. Jessat