Am I blowing my stack or just losing my mind?
TinkersALot
Posts: 535
Stingrayers,
I have a wierd behavior that I'm trying to get my head around.
Whenever I load the SensorHeads.spin file as my "top file" then I have two servos on the top of my stingray that behave according to the code.
But, when I load the PingsOnAStingray.sip file as my "top file" then the servos go crazy and will either peg to one extreme or just jiggle like jello in a hurricane around the center point. So, something is getting blasted (is it the stack because of additional variables declared in this file?
What is the heck is going on here?
I have a wierd behavior that I'm trying to get my head around.
Whenever I load the SensorHeads.spin file as my "top file" then I have two servos on the top of my stingray that behave according to the code.
But, when I load the PingsOnAStingray.sip file as my "top file" then the servos go crazy and will either peg to one extreme or just jiggle like jello in a hurricane around the center point. So, something is getting blasted (is it the stack because of additional variables declared in this file?
What is the heck is going on here?
zip
25K
Comments
The problem is this:
When the code in SensorHeads.spin (which uses Beau's servo control code) is used as the "top level program" it works just fine and the servos pan back and forth and do all that I'd expect them to.
But, when SensorHeads.spin is used as an object from PingsOnAStingray and the same motion test routines are called, the servos go crazy. It is as though something that the servo objects depends on is getting trashed simply because another file is introduced. The only thing I can see is that PingsOnAStingray has some additional variables declared, so I'm wondering is somehow the servo object memory is getting zapped in ways I do not yet understand.
As to what I am trying to accomplish, let me see if this helps:
I have a stepper mounted to the top deck. This is a "sensor head" that currently has an IR sensor and a compass module. The idea I am pursuing is to emulate some old "hero jr" behaviors (looking for people and seek and follow motion). My idea is to scan forward space by slowly panning the servo left and right. At each location, pause and take an IR reading. If IR sensor triggers, then take a compass reading and return servo to "center". Then rotate the platform until the compass reading of the platform matches the compass reading that the servo was at when it had an IR trigger. Then once oriented, travel in that direction (here using pings for obstacle avoidance).
I figure this a big enough objective for some opening salvos in stingray programming.
The second servo is also mounted on the upper deck, but its role is currently undefined. I may mount an LED flashlight on it or maybe an old sighting "laser" off of an old air gun "just for kicks" until it grows another more "serious purpose".
Thanks for your interest!
TinkersALot
If I run the Sensorheads program by itself, the servo's move like I think you intended. But when I tried running running Pings on a Stingray program they did just sit there and vibrate back and forth.
I tried increasing the stack by a whole lot - but same thing. I don't see anything right off thats causing this. If I happen to spot something, I will post back. If you figure out whats causing this let us know!
At least now (based on this evidence) I am confident that I am not losing my mind (at least as far as this front is concerned).
It is very strange behavior though - and surprising too.
Gadzooks! I cannot believe I did something like that!
So maybe I am losing my mind after all [big dumb grin] or else I really must remember to stop coding in my sleep....
In all honesty though, I can not say "THANK YOU" enough for seeing what I could not (I have a postulate that I apply to my foibles like this, which is: the dumber an error is, the harder it is for me to see it.
I don't know when I'll be in your neck of the woods (I am in Nevada City, California), but I sure as heck owe you a tall frosty mug of the king's brew!
Image34 : Shows my current location of the battery pack. Having it in the lower deck just does not work for my full sized hands. So, how lucky is it that the many useful cutouts on the upright panels fit the holes for the battery holder?
Image37 : Shows the upper deck. Since this is a three-deck stingray, the upper deck becomes completely available for "whatever". I quickly realized that the built in bread-board would get quickly consumed, so I added another breadboard to this deck. This bread-board is serving as the "expansion bus" for the controller board (on the middle deck). A0 - A7 are brought up to this deck with 14" servo cables, that are then connected to 90 degree pin headers.
Image40 : Since the controller board is hidden, I decided to add a power bus bar that brings out the Vin, 5V, and 3.3V power busses. This is a standard radio shack 6 position bus bar and it mounts to cutouts on the middle deck just to the inside of the wheel.
Image43 : This shot shows the upper deck with the "sensor head" that currently holds a PIR and compass sensor. Also shown is the "other sensor servo" that currently has nothing attached. These servo's are boe-bot PING mount assemblies that "just happen" to mount well to the bolts holding the stock breadboard. You can also see the "expansion bus" bread board on the top deck.
On the front, you can also see how I elected to mount the front-facing pings. I like having them on the front uprights because it frees up more upper deck space, but I always worried that these pings would fall victim to any collision between the stingray and "whatever." So, recently I was able to get some ping mounts. I mounted these to the front panels with 1"x1.5" inch angles I picked up from a local hardware store. I plan to outfit the the uprights on the lower deck with spring-backed bumpers/switches as another means of "object detection."
With the very big leg up provided by ratronic on finding a bug I could not see - I think I'll keep busy for a while working on the programming of this device. I've got a ways to go, that is for sure. Eventually, I hope to have a number of "behavior modes" in this devise that will be selected by a keypad that I think I'll mount on the back upright panel (opposite the battery holder).