I never heard of a service LM didn’t offer 
! Im sure if you arranged something with Jim, he could put the atom pro on an ABB you send him before purchasing an Atom. 
I know Jim would do it. He did it for me once before. However, I just can’t afford to lose a $60.00 chip. I am properly setup for anti-static protection now though, since I bought a new anti-static mat and wrist strap for my new robotics work area. I just don’t want to spend that kind of money on an Atom PRO right now even though I really like the chip quite a lot, and it did introduce me to the Renesas H8 chips.
8-Dale
Can I ask what went wrong the first time?
I had some bent pins on the Atom PRO chip. I was inserting it into the bot board and bent some pins. I hate machine sockets, so am glad the new bot board will have the proper sockets.
8-Dale
Hi Dale,
Well, I gave my wife the title of the “Robot Programming” book, so it’s as as good as on order for a Christmas gift. I don’t know who it’ll be “from” (wife, mom, kids…), but I look forward to getting it!
did you just break the pins on the Atom PRO? The module can probably be repaired. I’ve even put Microchip uP chips in BACKWARDS, and the chips didn’t appear to be damaged (I didn’t ship them, 'tho). I much prefer machined sockets. You might want to consider using a quality machined socket as a “carrier” for chips or modules. Put the uP or module in the socket. If the “carrier” (machined) socket gets broken or damaged, IT can be replaced!
I got some time to read the “Subsumption” (P. Anderson, where do I know that name from? No, not Pamela) document, but it sounds like they are just assigning priority to sensory inputs, and ignoring lower priority items. Not to say, as I might have implied earlier, the interrupt priority is used, interrupts, I believe are still allowed and possibly recorded. Put tasks are not enabled as a result of these interrupts. “Subsumption” is just a fancy word to describe assigning priority to tasks. Am I missing something?
If you still have the Atom PRO module, let’s see if we can get it working! Too expensive to give up on yet!
Alan KM6VV
If the pin broke off, you might be able to solder it back on very carefully.
Some pins got broken and/or bent. The pins are very fragile and I just can’t get these modules into the machine pin socket on the ABB. It’s too frustrating for me to deal with trying to insert these into sockets anymore. If I were to buy another Atom PRO, I would get it with a new ABB and ask Jim to put it on the board for me. Even my Basic Atom has a bent pin (one of the analog inputs) but I am not going to take it out and try to fix that.
I guess machine sockets are OK, but not for modules like the Atom chips. The new ABB will fix this problem and perhaps then I will get one of the new ABB’s and another Atom PRO to work with.
Subsumption is a priority scheme. The part I don’t understand is whether all tasks that have been triggered should be allowed to execute or if just the highest priority task should execute on each cycle. My subsumtion engine is currently setup to just allow the highest priority task to execute each cycle.
I can see possibilities if I were to allow all triggered behaviors to execute each cycle, from highest to lowest priority. I already have the tasks in the Motor_Control routine ordered from highest to lowest priority and would just have to comment out the “goto End_Motors” line for each behavior.
I wrote a routine to show the bits of Behavior_Status that are set. It prints the actual string name of the bit (like “Avoid” or “Slow”), so I can easily see what behaviors have been triggered. I got tired of trying to convert the hex values to something understandable, so I let WALTER do it for me. 
That is how it looks to me, but it works differently when all tasks can run asynchronously. I would do it quite different for the ARM MCU than I do it for this Basic Atom.
8-Dale
Hi Dale,
But ALL tasks don’t just get to run! They have to be “allowed” by a task flag. a set of conditionals, or maybe even a switch/case statement. So you set a task’s flag when it is to run, clear it when it’s done or no longer needed. But that’s the way to run tasks under a real time OS anyway. The trick may be how to smoothly transition from one gait into another, or maybe reverse direction or change headings.
Alan KM6VV
I don’t have the proper tools to do this sort of thing right now. That will change next month though when I get a new soldering station or maybe even a hot air station ($50.00 - $75.00 more than a Weller WES51). I am not sure which I should go with yet. The hot air station would be useful for desoldering and soldering BGAs and very tight pitch chips.
The new revision of the ABB will not have a machine pin socket on it. That will hopefully make it easier for me to get modules into the socket without bending or breaking pins.
I don’t know if this can be programmed properly for an Basic Atom or Atom PRO. I think doing that sort of thing would require some sort of RTOS or at least a real time kernel.
The sensors are all read in the main loop. I’m not sure how I would control which tasks are or aren’t allowed to run. I have a very simple priority model right now.
The software solution was much easier and it does what I need it to do.
I know this, and I have this all working. Conditionals in various parts of WALTER’s code set the appropriate bits to allow a behavior to run.
I also set WALTER up so the speed of each motor can be independently set within a behavior This should provide for some interesting behaviors…
In the arbitrate routine, I could somehow decide whether a task could be allowed to run based on the task bits already set and possibly a conditional if needed. Like, if the Avoid behavior needs to run, it would not be good to do the Slow_Down behavior also. However, Slow_Down and Wander (not yet implemented) could run with the Cruising behavior. Cruising is the default behavior and is always allowed.
Once I get the behaviors setup the way I want them, all I have to do is tweak some constants to adjust timing, speeds for backup, forward, turning, motor speed adjustment, etc.
This is one reason I decided to jump into the ARM world. More processing power, better interrupt access, and easier direct access to the hardware like with PICs. I have been playing with TNKernel, which is a sort of RTOS. I have gotten it to build but have not had much chance to actually fiddle with the demo programs. TNKernel does have a scheduling and priority mechanism.
8-Dale
Hi Dale,
Humm, not sure why. With properly pre-formed leads, quality machine tool sockets are generally easier. YMMV
Priority can be implemented with any language as long as there is a condition that can be tested. Simply test in order, and disregard the remainder when a condition is met. Do you WANT to do it under BASIC Atom? That’s another question. I believe I’ve seen you use condition flags, and test them, that and a particular order of testing is all that’s required.
(simplest) You simply have your tests in a list in order of priority, and do a call and return to service the desired function. When the call returns, jump to the end of the list of tests.
Then you’ve essentially got what I’m talking about and it’s all working.
Yes, basically. Set flags for the tasks that need to run, then allow the highest priority to actually run; I think that’s what they’re saying Subsumption is.
You might have an easier job of it on a wheeled vehicle then on a legged vehicle.
“Jump” is apropos! And taking on a RTOS And GNU should keep you busy as well! I didn’t see my PIC’s or ARM7 on the TNKernel site.
Working out what various “Behaviors” are first would be an asset to all interested in this level of programming. The paper identified some, and you have been working on a set of your own for a while. We know about several types of sensors available to us. What I think is needed is a set (library) of sensors and behaviors. They can then be developed individually, without affecting each other. Various sensors trigger or can be said to be “mapped” to one or more behaviors. This was stressed in the Subsumption articles I have read. Too bad Rodney Brooks’ “BL” (Behavior Language) isn’t readily available, although perhaps it would be considered a “crude UI” at this point. I think we need a way to “map” sensors and behaviors, and a few structures to pass to the “motion engine” of our programs, once the arbitration module has done its job.
Perhaps we could develop a set of sensor structures or flag bits, such that a behavior module would then “see” the sensors it needed. Likewise the behavior modules would set other bit flags to indicate that the behavior was appropriate at the current time. The arbitration module would then sort it all out. Remove a sensor or behavior module, that behavior simply doesn’t function; same for a sensor. Simple for a compile, could possibly even be done dynamically! And an RTOS could simply manage the functions by means of the task list. We should be able to do something similar!
But I’m still trying to calibrate all those lovely servos! And get the servo horns on correctly. I think I’ve done one leg about 3 times, but it’s all fun!
Care to document what servos you’ve got or can find code for? And you must have done considerable thinking about the behaviors you’ve identified or read about.
EDIT: … What SENSORS you’ve got…
I can envision a row of small toggle switches, allowing the user to enable or disable various sensors; behaviors, Asimov’s laws of robotics…
- A robot may not injure a human being or, through inaction, allow a human being to come to harm.
- A robot must obey orders given to it by human beings except where such orders would conflict with the First Law.
- A robot must protect its own existence as long as such protection does not conflict with the First or Second Law.
[/brain]
Alan KM6VV
This is exactly what I am doing in the Motor_Control routine now. I have the behaviors in order from highest to lowest priority. The highest priority behavior that is flagged gets to run, but nothing below it will. I use conditionals to set the bits for the behaviors in Behavior_Status, and the bits are tested in Arbitrate and Behavior_Response is set for the highest priority behavior that is flagged to run. Right now, I am setting the behavior bits in Behavior_Status in the routines that trigger them, but this might get hard to track at some point.
That is what I am doing. I short circuit when I get a behavior that needs to run, and go to the end of the routine afterwards. I have each behavior in a subroutine. I should send you my current code, which I have bumped to v2.0.0 due to the major rewrite to handle subsumption, or at least my version of it.
I believe I do! The priority scheme is working, but I still have to get the behaviors coordinated and get the right things being done at the right time. I want to get WALTER to make smooth turns and not have to backup so much.
That is what I am doing right now. However, it might be desirable at some point to allow more than one behavior to run per cycle. I need to be sure Cruising runs each cycle, which is easy - I just change the label the other behaviors branch to when they finish. In fact, I don’t even have to put a conditional on Cruising - just do it at the end of Motor_Control before the Motor_Command section.
Well, WALTER is a two-wheeler.
It will take quite awhile before I have the LPC2148 running WALTER around. I still need to get JTAG working with my development environment. I’m seriously considering Rowley Crossworks for ARM, and they have a Linux hosted version. I also found this cool Signalyzer Tool that has drivers for both Windows and Linux. 
It’s a JTAG debugger/programer as well as an I2C master, etc.
I am going to do this with the ARM routines and have already been doing it with my PIC stuff. I want to have good code that can be reused over and over or modified to suit a specific task as needed.
I pretty much have this now. For instance, the front IR Ranger on the pan/tilt can trigger the Collision behavior, but the left and right IR Rangers trigger the Avoid behavior. The PING sensor will be on the pan/tilt with the IR Ranger or may replace the IR Ranger there. The left and right IR Rangers will also be able to trigger a GoBetween behavior if they are both detecting something and there is enough clearance for WALTER to get through. They trigger the Avoid behavior of only one of them has detected something that is too close.
I have been particular attention to the DPRG article on subsumption. Journey Bot has always been one of my favorite robots, and SR04 is cool too. I am starting to understand what they have done and why now, and want to emulate that since it works so well. Of course, I will likely add my own unique twist to their work. 
I have thought of this. I want to get what I already have working the way I want it to before I go adding more stuff. There is not much room to add more now. I like the layered approach the DPRG guys are using. They have a 3 element structure for each behavior. I need to analyze this a bit further. TNKernel has all the pieces to handle the priorities and scheduling.
This is why I am looking at TNKernel. There is also eCos II. Both are FREE. There are already ports of TNKernel to the LPC2xxx MCUs though, so I am starting there. WALTER’s code has always been pretty dynamic. He can even turn off his noises if I want to implement a SneakFollow behavior.
That should keep you out of trouble for awhile!
I only have to HS-422’s right now. The same code would be used for any servo, especially if you are using the SSC-32. I can at least not have to worry about pulsing each servo I may hang on WALTER. Each servo needs to be calibrated to what is required for the joint it is in.
That would be very easy to do. I have a total of five sensor routines that are already done or need to be written. I’ve even already written the compass routine. The accelerometer won’t come into play until after I release v2.x.x of WALTER’s software. I’d have to wire up an ADC chip to get enough ADCs (3) for the accelerometer. I alread have places to trigger Tilting and CourseCorrection behaviors. I also need to write a Read_Encoders and Read_Accelerometer routines, but they also will not come into play for awhile. Everything is in subroutines.
8-Dale
Hi Dale,
From your responses, it sounds like you’ve already embraced Behaviors and Subsumption!
Oh, I made a typo, I meant “sensors” instead of “servos” (see Edit) in a previous post. We need to make up a list of the sensors and a library of routines (in C) to support them. Then you can run it on either of your processors.
The SR04 is a very successful robot. The Subsumption document is GREAT!
Do you have your motor stuff all in a “motion module”? We should be able to define an interchangeable routine, such that one could simply switch out this routine to go from legs to wheels. (API).
OK, instead of a row of little toggle switches, I might just put the selections of sensors and behaviors in a menu, on an LCD screen. Yeah, we can do that!
Alan KM6VV
Greets, Alan
Yes, I believe I have! I will be looking forward to doing this for the LPC-2148, where I have some real processing power.
I have a pretty good line up of sensors now, and there is really only one or two other sensor I really want. I have the Sharp IR Rangers, PING ultrasonic, Honeywell Compass, Analog Devices 3-axis accelerometer, and shaft encoders for both motors. I don’t know how well the code for the Sharp IR Rangers will translate to C. I have to get I2C working on the LPC-2148 before I can write code for the Compass and other I2C sensors. I am hoping this code will be as portable as possible, because I would like to use it for PICs/dsPICs also. At least C code should translate better between architechtures.
I know! That’s why I decided to emulate its subsumption engine as close as possible.
There is just one in place in WALTER’s code where commands are sent to the SSC-32. That is at the end of the Motor_Control routine. The behavior code just makes changes to the left and right motor speeds as required.
This would be doable with a small LCD display, for sure. That is another thing I want to interface to the LPC-2148. There is so much I want to do with the ARM board! I wonder if I can fill up 512K of flash… I will end up having a nice sensor library, which should be portable to other MCUs with the proper defines.
What is your development environment for ARM? I really dislike the Eclipse IDE. I am considering Rowley Crossworks for ARM. I am sending my ARM JTAG unit back to SFE to be replaced. I just need to get the RMA for it.
8-Dale
Hi Dale,
This should all run on your PICs!
That’s a pretty good line up. If done correctly, the C code should be perfectly portable! I need to get around to finding all of them for my own use.
No I don’t mean the calls to the SSC-32, your “MotorControl()” module needs to contain all that’s required to make your motion control system operate. It should take a TBD list of parms like heading, range, speed, etc. It calls a com() routine of some sort. That way, a different one, say for a legged 'bot can be substituted, with little or no effort.
I have a nice 64 x 128 APA COG LCD. 8 lines x 20+ characters. It’s on my ARM7 board. Display code already running!
I develop with the IAR compiler, which has it’s own IDE. Nice stuff; free for a 32K demo. the full boat, you can’t afford (neither can I). I might investigate the Rowley compiler.
Alan KM6VV
Yes, it should if I write the code properly.
I want to get some of the other I2C sensors like the SRF08 and especially the TPA01 thernal sensor for tracking heat sources like warm bodies. I also want to get the regular SRF05 untrasonic sensor, since it works a little different than the PING and I want my code to handle both types.
I have WALTER’s sensor routines for the PING and Sharp IR rangers setup so it can handle any number of those types of sensors. You just have to have the ADCs available for the Sharps and I/O pins for the PINGs. My scheme works very well!
I already have this setup in the Motor_Control routine. ALL the code for actually operating the motors is at the very end of the routine, so I can very easily pull it out into a new subroutine.
I will do that, since all I have to do is cut and paste the code into a subroutine and add a call to it in Motor_Control(). My code is very modular and it’s extremely easy to create new subroutines.
Very cool! What is the exact part number for that display and where do I get one?
This is one of the things that really frustrates me. I need the same tools that the “big boys” use, but cost keeps me from getting them. I was very happy with Alibre’s arrangement of allowing customers to pay monthly for a year to purchase their software. I would not have Alibre Design Expert if that were not possible. I need a good electronics CAD package also, and have located a nice one in EasyPC, but even it is almost $1000.00 for the unlimited pins package. They also have 1000 pin and 2000 pin packages at lower cost, but I hate limitations if I can avoid them. There are a few companies, like, RowleyAssociates ,who have personal and educational licenses for much lower cost than their regular professional licenses, and I hope more companies follow their lead.
8-Dale
Hi Dale,
Check out the PDF at this link, article on Hexapod Robot Subsumption on a microprocessor:
IsoPod board runs IsoMax, a Subsumption AFSM language.
Displaytech S64128H COG LCD
displaytech-us.com/whatnew.php
New Book:
Cambrian Intelligence
The Early History of the New AI
Rodney A. Brooks
mitpress.mit.edu/catalog/item/de … 2&tid=3862
Alan KM6VV
Very interesting. I will definitely give this a read when I can devote proper time to it. Right now I am busy working on W.A.L.T.E.R. and almost have his new deck designs completed too. I just have to decide on one more dimension - the distance from the edge of the wheel wells to the center of the motor mounts.
Oh boy, new toy!
I will be checking this out also. I read at a rate many never believe when I tell them, and I have not taken any speed reading/comprehension courses at all. I take in new information very fast, and can usually apply it almost immediately.
8-Dale
I have completed the design of the new body for W.A.L.T.E.R. (again!). These are actually going to be made as soon as I can generate 2D CAD drawings and send the material off.
New Body (3D PDF).
I will hopefully get this done early next month.
8-Dale
I’ve decided to jump into wireless with W.A.L.T.E.R. and am getting a Bluetooth DIP module from Spark Fun. I plan to add a small breadboard area to W.A.L.T.E.R.'s new body where I can add various new circuits I want to work with.
I am planning to try using HSERIAL to connect with the Bluetooth module so it can run in the background. I hope this will allow me to see what is happening inside W.A.L.T.E.R. when he is rolling around.
8-Dale
Ya, but too bad hserial doesn’t work…
Sorry, I guess it’s time to stop complaining about the atom…