PING))) with Mesmic code?

ScottH61 · 2008-04-11 00:41

Can anyone please show me how to run my Boe-Bot with both a PING))) for object avoidance, and a Mesmic accelerometer acting as an anti-tip over sensor? I have them both hooked up, and can run programs for either one, but when I try to combine them, I get way confused.

I have these connections:
Ping))) servo on P14
Ping P15
Mesmic X on P4
mesmic Y on P5

It would help if the code was documented a bit, so I could learn what was going on, but if not, I will eventually muddle my way through it...

I really appreciate any help anyone can give!

Scott

Zoot · 2008-04-11 01:29

Can you post the code you are currently using?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST

1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php

ScottH61 · 2008-04-11 03:06

The code I started with was the Ping))) example 'RoamingWithPING-Simple-v1.0.bs2' I found on the Parallax site. I have attached it to this post.
I also had found the code 'Advanced_Tank_Bot.BS2' which is also attached. I just can't keep it straight in my head as to how to combine the two.

Thanks again for your help!

Zoot · 2008-04-11 07:25

At first read, my inclination is to tell you to take the core subroutines from each and combine them into something new -- if you want your 'bot to deal with multiple sensors in a coherent way, you may find it is better to have a game plan and real architecture in your 'bot code for adding/deleting/changing sensor routines and the responses to those sensors.

That said, though, if you want some simple results, I would start with the Get_Sonar routine from Roaming with Ping. In a way, this routine is the main "decide what to do code":

GetSonar:
  LOW Ping
  PULSOUT Ping, 5
  PULSIN Ping, 1, rawDist

  IF (rawDist < 600) THEN
    IF (sweepcount < 750) THEN
      GOSUB Turn_Left
    ELSEIF (sweepcount > 750) THEN
      GOSUB Turn_Right
    ELSE
      GOSUB Back_Up
    ENDIF
  ELSE
    GOSUB Forward_Pulse
  ENDIF

RETURN

I would take the second half of this sub and move it to your main loop. Leave just the "reading" of the sonar in the sub. Then add in the sub for reading the memsic and add the extra decision making to the main loop. For example:

'pseudo code as an outline:
1. Read Sonar
2. Read Memsic
3. If memsic says "tipping over" then stop (or whatever)
4. If sonar < obstacle then turn based on sweep angle
5. Goto 1.

Obviously, I'm leaving work here for ya

-- I would start by getting the memsic code into the Roaming program and make sure you have pins and vars assigned properly and that the subroutines run correctly and give you good values THEN start doing stuff with the read info. Build it up in pieces. I.E., the first round of your program might just be:

1. Read Sonar
2. Read Memsic
3. display values
4. goto 1.

This way if you have problems as the program gets more complex you will be able to rule out problems with each "module" (like reading the sensors) as you'll already have debugged them in their "simple" version.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST

1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php

ScottH61 · 2008-04-11 17:20

Thanks for the pointers! I'll see what I can do with your suggestions. I appreciate your replies!

Scott

ScottH61 · 2008-04-17 23:00

Ok, I have looked at a lot of code, and pulled bits and pieces (and whole routines) out, and tried to combine them to get something that works. I haven't commented the code (see attached) yet --- shame on me... but it seems to be fairly straightforward, but it's still not working correctly. It Ping))) part works, but the beeper and the accelerometer parts don't do anything. I do get the DEBUG for "CheckLevel), but tilting the Boe-Bot has no effect when the program is running. In fact, the the "CheckLevel" subroutine starts the BoeBot going backwards, then will go forward from then on. I'm terribly confused, and have given myself a huge headache trying to work this out. I would appreciate any help that anyone can give! Thanks in advance!!!

Oh yeah, I have a subroutine to check for Bumper whiskers, but I don't actually have any whiskers installed on the Boe-Bot... I set the values to '1' instead of '0', because if I have them set to '0', the Boe-Bot continually runs backwards... I have not built the bumper as of yet, but I'll get around to it one of these days....

Zoot · 2008-04-18 03:59

It's straightforward but it's not working for ya, eh?

In any case, some of it is pretty straight forward and at quick glance looks OK, but some of it is a bit involuted for me to parse out in a quick read. Have you made sure it's not possible to call more than 4 GOSUBs in some of your escape routine near the bottom? You can not call more than 4 "nested" GOSUBS in a row without a return or the Stamp interpreter will "lose it's way" back. (i.e., the main program calls a sub, which itself has another gosub within it, which itself has another gosub...you can only do that 4 times then one of them *must* return or you will overflow)

Second, make sure your two main sensor routines are giving you correct values based on dist. measured, tilt. Ensure that those are rock solid THEN start using those values (as you have) to make your decisions.

Third, don't run bumper check until you have whiskers installed and running properly. That routine will give you strange results and may be a big source of strange behaviors.

Fourth, as a matter of style and need you might nuke all the debug "text..." statements at the start of your subroutines. Debug strings take up a lot of code space, but more importantly, they are SLOW and take time to send even if you are not hooked up to a PC via serial cable. Note that in my "conditionally compiled" version the long, slow debug statements only appear in the version where it is presumed the 'bot is hooked up to a PC for debugging.

To wit, the edited version here should just give you debug values for your sensors w/o running the 'bot. If that's good, then you can at least rule out inaccurate readings. Note that I used conditional compilation -- it's like having two versions of the same program in one -- one version doesn't move the bot and shows sensor values in the debug window; the other doesn't have the debugs and essentially runs your program as it was.

Lastly, indenting code and even the most rudimentary comments in the code can make it *way* easier for others (and yourself in twelve months) to read. Not that I added any comments either ...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST

1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php

ScottH61 · 2008-04-18 06:26

Thanks for the help, Zoot! You really give me a lot to think about. I ran your code, and I get PING responses, but nothing from the accelerometer. I *think* I have it wired correctly... let's see.... for the ones that don't work, I have:
Pin 1 = open
Pin 2 = tp P5 (Yout) - Through a 220 ohm resistor
Pin 3 = to Vss
Pin 4 = open (or Vss)
Pin 5 = to P4 (Xout) - Through a 220 ohm resistor
Pin 6 = to Vdd

Beeper = + to P8
- to Vss

Running your program that shows just the sensor data, for the X/Yraw: and X/Ycal:, I get numbers that look like this:
YRaw: 2540
YCal: 25
XRaw: 2675
Xcal: 26
and they don't change when I tilt the bot....
I know I should have the DEBUG statements in my code, but I put them in there to see if the actual subroutines were being called.

I borrowed most (ok, all) of the code I used, and one of them was the 'Advanced_Tank_Bot.bs2' program, and I wasn't sure what to do about the part of the code in it, which reads (in part):
Main:
Do
Gosub Check_level
Gosub Read_IR_Sensors
ON irBits Gosub Forward, Go_Left, Go_Right, U_Turn <

this bit...

so I modified to to check my imaginary bumpers. This was the only thing that I saw that was telling my bot to go forward.

Well, now it's late, and I am getting more confused, so I'll stop here, and see how clearly I can think tomorrow.

Thanks again for your help!!

Scott

P.S. I'll clean up the code a bit... take out the DEBUGS, and indent it to make it easier to read...

Zoot · 2008-04-18 18:31

Well, get the memsic returning meaningful readings. I don't have one here myself to test this out on.

BUT -- unless I'm missing something, the last version of your code has different pin assignments compared to what you mentioned in your post from last night!!??

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST

1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php

ScottH61 · 2008-04-19 06:27

That's entirely possible... I've been running myself ragged these past few days, and I just can't seem to catch up. I think that I'll pull all the wires and components off of the bot, and using my code, plug them all back in again using the code as my guide. Maybe that will solve a couple of my problems. Then I'll get my bumper switches built and installed...

Thanks once again for your help!

ScottH61 · 2008-04-24 16:40

Ok, I've taken everything off of the robot, and re-installed it. I tested each item and made sure everything worked OK. I changed the pinouts in my program to match the ones that I used for testing, so they should all be correct. No problems with any sensor tested individually, but when I run *my* program, the accelerometer still doesn't work. I think it may be the X and Y threshold values, but I have no idea what to set them at. Attached is the 3rd revision of my program, as well as the program I used to test my accelerometer.

This is giving me a headache.

Zoot · 2008-04-25 00:05

At first glance it looks OK. You say you're getting good vals with the test program?

If that's the case, then I would sent the conditional compilation flag to showonlysensors. Run it hooked up to the PC and check what X/Y vals you get when you tilt the 'bot different ways. Then (re)set your thresholds accordingly. You also might need > AND < to cover different tilt directions i.e.

YThresh   CON 25
XThresh   CON 25
Xzone CON 10
IF ( ABS (Xaxis-XThresh) > Xzone ) THEN ...
' above checks to see if tilt is at least Xzone units HIGHER OR LOWER then some "level" threshold...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST

1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php

ScottH61 · 2008-04-25 00:40

I'm in the middle of trying to sort it out now. I ran the test program for tilt, and got GREAT results. When I run my program (with the showonlysensors set to 1, and not commented out), I don't get much of a change in the outputs - certainly nothing like I see when I ran the test program. Below is a sample output while I was tilting the bot in all directions. (+ and - 90 degrees in both axes), and the motion of the wheels doesn't change in the slightest.

Xraw:02808
Xcal:00028
PingRaw:01925
PingCal:01925
Yraw:02712
Ycal:00027
Xraw:02454
Xcal:00024
PingRaw:02095
PingCal:02095
Yraw:02596
Ycal:00025
Xraw:01914
Xcal:00019
PingRaw:02461
PingCal:02461
Yraw:02305
Ycal:00023
Xraw:02056
Xcal:00020
PingRaw:02955
PingCal:02955
Yraw:02165
Ycal:00021
Xraw:03088
Xcal:00030
PingRaw:03150
PingCal:03150
Yraw:02166
Ycal:00021
Xraw:02934
Xcal:00029
PingRaw:02534
PingCal:02534
Yraw:02500
Ycal:00025
Xraw:02905
Xcal:00029
PingRaw:03218
PingCal:03218
Yraw:02365
Ycal:00023
Xraw:02816
Xcal:00028
PingRaw:00752
PingCal:00752
Yraw:02561
Ycal:00025
Xraw:02619
Xcal:00026
PingRaw:00758
PingCal:00758
Yraw:02546
Ycal:00025
Xraw:02602
Xcal:00026
PingRaw:00758
PingCal:00758
Yraw:02572

ScottH61 · 2008-04-25 00:47

Just for clarification, When I said "the motion of the wheels doesn't change in the slightest.", I mean that I've run the program with the showonlysensors set to 1, and commented out... I know I won't get any wheel rotation with the showonlysensors set...

Zoot · 2008-04-26 15:53

OK, leaving aside the Xcal and Ycal, how do the raw values of what you posted above compare to the raw values when you run the test program? What I'm driving at is if the span of read values is indeed good in the raws above, then your cal values don't have enough resolution to be useful. But if the raws above are very different than what you get in the test program, then something else is going on.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST

1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php

ScottH61 · 2008-04-26 16:29

I modified the code for the Mesmic test to display XRaw and YRaw, and on average, I get these return values:
XRaw YRaw
level: 5000 5000
nose down: 5000 6300
nose up: 5000 3800
rolled to right 90 degrees: 6300 5000
rolled to left 90 degrees: 3800 5000

So I'd say you're right... but I don't know what is amiss, or how to go about fixing it. Yet. I'm not giving up!

I've attached the modified Mesmic Test, just in case I've done something wrong, and I'm not getting correct Raw returns...

Zoot · 2008-04-28 22:43

Have not forgotten about this thread -- had a work deadline to meet.

So... when you run the "test" program, you get the values described, but when you run your own program, with "showonlysensors" set to 1, you don't?

Use my revised and attached version of your program. This has been changed to "scale" the memsic readings to microseconds, like the test program. In looking both programs over, I can't imagine why you would NOT see the same "raw" values in the test program and this new version of your program. Pins look the same, the rest looks OK.

For now, disregard the cal values, etc., until you know you've got good readings from the memsic into your program.

Also, see my other comments regarding these lines:

      IF (XAxis =< XThresh) THEN GOSUB BackUp

If "level" is between tiltup and tiltdown, then you would want something more like:

      IF ABS (XAxis - LevelValue ) > DeadZone THEN GOSUB BackUp

The above would have the backup happen if you are tilted more than "deadzone" units below LevelValue OR more than "deadzone" units above LevelValue

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST

1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php

ScottH61 · 2008-04-30 17:34

No problem... I know that you read other posts besides mine, and I know you have your own projects that come first!

I am getting good readings now with the showonlysensors set to 1 now!!! When I comment 'showonlysensors' out, the bot won't back up when it's tilted, so now I need to work out the other parts of the code, and see if I can figure out how to work in your other ideas for the 'deadzone'. I need to get some ink for my printer now, so I can look at it on paper. It's easier for me to follow when I can see it all at once.

Thanks again for all your help!

Zoot · 2008-04-30 18:14

If you are getting good readings, then next step is get some good thresholds. Hold the bot level and get readings. Then tilt it one direction (say forward) to about where you would want the escape behavior to trigger. Get the reading. Now do the same thing in the other direction (say backward) and get the reading. To make some totally meaningless numbers up:

forward too far -- 1250
about level -- 1100
backward too far -- 900

In the interest of simplicity, call the +/- threshold 175

If you are more than 175 units higher than level (~1275) then you are tilted too far forward
If you are more than 175 units lower than level (~925) then you are tilted too far backward
In between, you're OK to roam.

So your logic would be:

LevelY CON 1100
LevelYThresh CON 175
IF ( ABS (YAxis-LevelY) > LevelYThresh ) THEN BackUp

But for testing do this, as a conditional compilation when only showing sensors:

IF ( ABS (YAxis-LevelY) > LevelYThresh ) THEN
  DEBUG "TILTED TOO FAR Y", CLREOL, CR
ELSE
  DEBUG "Y OK", CLREOL, CR
ENDIF

And the same for the X axis, of course. This way you can just see if your constants are good and if the 'bot is triggering the "I am not level" response when it should.

If that's all working how you'd like, then plug the logic back into the actual behaviors. The idea here is that if your 'bot is still not behaving at that point, you know that you have logic or code or movement problems, without wondering if you're getting a good "level/not-level" flags from your sensor routines.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST

1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php

ScottH61 · 2008-04-30 23:40

Wouldn't I need something like TiltXHigh, TiltXLow, TiltYHigh, and TiltYLow values depending on whether I'm going up a hill, or down (or left or right...)? I'm not sure how your example would determine that.

What I got for values though are something like this:

LEVEL Max Tilt Fwd Max Tilt Back Max Tilt Right Max Tilt Left
YRaw 4980 5680 4280
YCal 49 56 42
XRaw 5025 4400 5650
XCal 50 44 56

Maybe I'm just confusing myself further and (trying) to think too much?

ScottH61 · 2008-04-30 23:41

I had that all formatted out so it was easy to read, but the forum took all my extra spaces away... sorry about that....

Zoot · 2008-05-01 01:17

OK, coupla things. First, yes, you are right, my example doesn't provide for a different < and > threshold. Second, the Xcal and Ycal are too far scaled down to be useful. Ideally, you could just resuse the same temporary input word (for reading pulsin), then scale to byte sized values (to save space) -- if you wanted. But since you already have Xaxis and Yaxis set aside as Words, I would just use the scaled to us values, and not the Cal.

If I have your X and Y switched here, sorry.

'        Level Fwd Back
'YRaw 4980 5680 4280
'        Level Right Left
'XRaw 5025 4400 5650

Yfwd   CON 5680
Ylevel CON 4980
Yback CON 4280

Xleft   CON 5650
Xlevel CON 5025
Xright CON 4400

' insert code here read in Yaxis as Word, scaled to us, but no /100 or anything (presuming above are vals in us)
IF Yfwd <= Yaxis OR Yaxis <= Yback THEN
   DEBUG "Help! I'm tipping!", CLREOL, CR
ELSE
   DEBUG "Steady on!", CLREOL, CR
ENDIF
' insert code here read in Xaxis as Word, scaled to us, but no /100 or anything (presuming above are vals in us)
IF Xleft <= Xaxis OR Xaxis <= Xright THEN
   DEBUG "Tilted too far to the side!", CLREOL, CR
ELSE
   DEBUG "Level side to side...", CLREOL, CR
ENDIF

You can get fancier too -- for example, you could adjust your speed depending on how close to Xlevel you are, or take different actions if tipping one way or the other (depending on your other sensors). But if something like the above is at least giving you good readings, then you can hitch the readings to your behaviors (backup, turn, etc).

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST

1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php

ScottH61 · 2008-05-01 06:13

Wow.... You sure give a guy a lot to think about. I'm sure my programming skills aren't anywhere good enough to incorporate this into what I have already (your last version you posted). Mostly, I'm not sure where I need to put your suggestions, or what I need to take out of the existing program.............
Maybe I should stick to the simple stuff... *sigh*
I mean, I can follow programs pretty well, but troubleshooting and combining them? I suck.

I'll keep at it though... I can't stop now after all your help......... You give me something to shoot for!
This will likely just take me forever to complete... maybe even longer.

Zoot · 2008-05-01 12:55

Well, don't thank me so quickly for my help -- I don't think I'm being terribly helpful

When I get to my other machine later today I'll take a crack and incorporating this into your current code. Actually, can you post your most *current* version of the code?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST

1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php

ScottH61 · 2008-05-02 15:47

Actually, the latest code I have is the one you last attached for me... I messed around trying to incorporate your suggestions and ideas, but got way confused, and it didn't work at all. The only part I had in there that I'm sure would have worked were the constant declarations, but I never even bothered to save that. What you told me made sense, but I just couldn't work out the correct structure/ formatting to make it work. I know I need the +/- threshold constants, so it know which way it's tipping, but there I get all mixed up....

I have attached your code again to this, so you could get it easier, I did rename it though...

And yes, I do need to thank you. I do appreciate your help, and eventually, I hope I can learn this stuff. But at the very least, you've practically written my entire program, and for that I'm grateful!

Zoot · 2008-05-20 21:29

I bet you thought I forgot ...

been pretty busy with work, etc. last few weeks.

I've been looking at and mulling over this code. I think it will be quite tricky to integrate both the memsic and the Ping scan code. Both are fine perhaps standalone, but I think that a different kind of setup would make it much easier to integrate both.

That said, I still think you should get just the Memsic parts working OK, then work on program logic, then insert Ping code. The latter is easier because it's just distance and is already calibrated (i.e., it's easy enough to say "if distance is less than 20 cm, then turn" as opposed to figuring your constants for tilt -- plus the fact with your tilts you've got FOUR possibilities to contend with -- tilt forward, tilt back, tilt left, tilt right).

So... the question now is -- (and here, I feel like you owe you one because I haven't been particularly helpful) -- do you want to take a crack at the code yourself with some guidance, or should I hack the code into something worth testing?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST

1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php

ScottH61 · 2008-05-20 23:20

Zoot,

No problem at all! I know that you get very busy with more important things. I've been way busy at work myself these past couple of weeks, and have been battling an illness as well. Not much fun. Anyway, I haven't had time to do a thing with the bot since my last post. I don't think you 'owe' me a thing... you've been great help, even if I haven't been able to get it working yet. You've given me great ideas and have taught me quite a bit too. If you want to take a stab at making something that I can test, then I'd be happy to accept it! I think that I'd get a LOT farther on it than if I tried to get it working.

Of course, I'll still be looking into it as well, but I'm nowhere near as good at it as you are...

Thanks heaps!!!

Scott

Zoot · 2008-05-21 17:57

OK, check out the attached. I cut out most of the program so you can focus JUST on making sure the tilt values are correct, the ping distance is correct, and that basic sensor values (i.e. tilted too far, object in front of 'bot, etc) trigger some basic escape behaviors.

Note that I took out all the material for "scanning" the ping and such -- I think if you get the following working to your satisfaction then we can start adding more features back in. I also made one to change to "foward" and "backup" so that you can pass the "number" of pulses to these routines from the main program (this makes the routines a little more flexible).

Run it with just sensors and double check that I plugged in correct "set points" -- where the 'bot is tilted too far in a given direction -- for your tilt measurements. Ditto the ping measurements. Note that the setpoints are constants at the top of the program.

Then, if you run the bot with the showonlysensors = 0, I would *expect* the 'bot to behave something like as follows:

- if tilted too far forward: stop, makes sound, backs up longer than your "normal" backup, turns around
- if tilted too far backward: stop, makes sound, go forward longer than your "normal" forward, turns around
- if tilted too far left/right: turn other way
- if object is 8" or less in front, stop, make sound, backup briefly, turn around
- otherwise, drive forward
- I would expect some "stutter" at times in the motors -- this is because depending on actual Ping and Memsic measurements, it is likely that you won't a servo pulse every 20ms -- however, when turning, backing up I would expect smoother motion
- you will want to adjust the times in the pulsout routines (the number of pulses sent for a turn, backup, etc) AND the setpoints so that the 'bot responds to the memsic and ping when you want AND turns/moves the approx. amount you want.

Then, we can return to getting your scanning and bumpers code back in and perhaps reworking so you have a real subsumption engine and can refresh your pulses. See, the one issue with a setup like this is that it's purely "ballistic" -- say a tilt is detected, the program then drops into backing up and turning around. What if the sonar is too close *while* it's turning around? What about if it's tilted 2 ways at once? What about getting servo pulses every 20ms no matter what? There are some pretty clever ways to do all that (and they are much more variable and code efficient), but we can get there (hopefully) in time.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST

1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php

PING))) with Mesmic code?

Comments