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.
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.
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.
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.
Just kidding, I had no idea this would go this far. I have no desire to dig real deep in the specifics of FSM or Subsumption. It’s something I have played with in the past using Pbasic (Not Mbasic) and may some day get more serious about it.
(2) BrainStem controllers (new in box).
(2) Moto 1.0 controllers (new in box).
(4) S17-3A-LV-HBRIDGE modules (new in antistatic bags).
(1) Acroname CMUCam2+ (new in box).
(1) DevanTech Thermal Array (new in bag).
(1) DevanTech Compass (new in bag).
[8] DevanTech R241-SRF10 Sonar Rangers (new in bags).
(1) S22-USB-SERIAL-INT-CONN (new in bag).
(1) S13-SERIAL-INT-CONN (new in bag).
There are other assorted items (mainly brackets and mounts) that I’ve not listed. I’m ready to barter/trade/sell. Any takers?