PDA

View Full Version : MAWD - ARLISS Team NH



Dylan Landry
04-06-2011, 11:46 PM
Andrew and I are now just finishing up testing the one that DEBUGS "Got to Movement". We are about to test the one with the Movement subroutine and we will report our findings on both shortly...

Mark Kibler
04-06-2011, 11:54 PM
Dylan,

Can you change the title of the thread to MAWD - ARLISS Team NH so it's even easier to find?

I just ran the program I mentioned before and it hangs up (stops recording altitude) at 2,022 feet, even after the vacuum stops (altitude = 0.) Here's what I said before:

---------

I compiled a "framework" for a working version of our program. It's a combination of various program pieces, and I think all the subroutines we need are there. These "pieces" include:

1) The program code that initializes the BOE and that makes all the sensors work (from last year's ASP).

2) The movement subroutine (also from a previous version of the ASP program.)

3) The new "MAWD get" subroutine that PJ compiled.


Results:

When I run this "framework" program it works:

1) In the vacuum chamber it measures and records everything it's supposed to, including altitude. HOWEVER, the altitude stops at 2,022 feet, even when the vaccum chamber turns off. It DOES NOT stop writing data when the altitude reaches "0" like last year. That could be a good thing since we want the ASP-BOT to move and record data after it lands.

2) The program does NOT activate the servomotor (which is attached to PIN 14) when the altitude returns to "0". Maybe that's because the altitude doesn't return to "0"-- it stops at 2,022 feet.

Mr. Kibler

Dylan Landry
04-06-2011, 11:57 PM
PJ,
Andrew ran both mawdsimulation2 and 3. We got successful results in both. We were able to have the counters go to their max's, increase when corresponding # were inserted, and just overall success. Although we have one question..

What was the key difference between both? The differences we were able to point out were...

mawdsimulation3 had two extra commented out VARs at the top that were commented out, and was missing comments that were in mawdsimulation2. Aswell as a return was added at the end.

PJ Allen
04-06-2011, 11:59 PM
Right. I changed the GOTO to GOSUB and made for a RETURN in "Movement" because I thought there were to be several iterations/calls to "Movement". You guys had GOSUB..RETURN, so I put the simulator that way too.

PJ Allen
04-07-2011, 12:02 AM
So, to be simplistic, that's how things should go. Right?

Dylan Landry
04-07-2011, 12:03 AM
So it seems that the logic of the program is correct, because we have proved it with your program. Now we just need to address it in the whole finalized program. Does it seem logical to add the program you have just written PJ, in to the actual main program with the actual ASP-Bot and see if it still works? Out of the gas chamber of course.

PJ Allen
04-07-2011, 12:09 AM
That's the goal.
Basically, substitute my subroutines for yours.
Disconnect the MAWD from the MAWDin Pin (P-whatever it is.)
And add that DEBUG line into the * Main DO..LOOP *, so everyone can see what's transpiring.
Someone will still manually enter data and see it gets to "Movement."
Hopefully the DEBUGs won't push your remaining Stamp memory.

PJ Allen
04-07-2011, 12:15 AM
Oh, and I didn't completely answer your other question.
The big difference from the very first was the addition of MAX to the increment expressions. That way they freeze at specified MAX, they won't "roll-over".

Mark Kibler
04-07-2011, 12:20 AM
Stamp Men: PJ, Dylan, and Andrew ~

I'm bowing out and waiting on the sidelines at this point. I've done enough talking already and you guys seem to be speaking the same language. I'll wait until I hear back from you with a program to test on the ASP-BOT. Then I'll report back to you here on the forum.

Roger Dodger?

Standing by, over and out,

MK
:cool:

Be sure to count the sheep, PJ.

PJ Allen
04-07-2011, 12:21 AM
10-4, Mark

Dylan Landry
04-07-2011, 12:30 AM
I have made the changes to the program....
The space consumed by the program was a little too much. Thus I took out the section of the initialization message that thanked certain people so the program can run. Although as I word of caution, the program might display onto the GUI in a strange sort of spacing. By this I mean that the DEBUG statements for the MAWD might occur mid-way through a sample. But this is no HUGE issue... For now anyways.

PJ Allen
04-07-2011, 12:39 AM
Yes, I'm not a wiz with those formatting commands.

So, first it should run "on the bench", as I call it.
Then it should run in the bell jar.
Then the MAWD_get routine should be changed back to the original and the MAWD re-connected to the Stamp input. Keep the DEBUG in the Main: dO..LOOP
Then you should change "Movement" to incorporate your servo routine.
Once that's working 100% then you can remove the DEBUG from the Main: dO..LOOP and you have your flight-ready example.

All of the characters and spaces in DEBUGs take up memory, if you want to abbreviate to make room, then do that. [If you change "Go to Movement" to "Yes!", you'd save memory.]

Dylan Landry
04-07-2011, 12:45 AM
Well it seems like we have a LOT ahead of us in the next few days. Thank you for all of your help! We really couldn't of even progressed this far without you.

Mr. Kibler, would you be able to conduct the tests for the program on the ASP-Bot as PJ specified? On the bench of course. It would be great if you could report the findings like you have before.

PJ,

What would the point be to run it in the Bell Jar with the controlled Altitude program section in there? It would behave just as it would on the bench. As I believe it would.

PJ Allen
04-07-2011, 12:51 AM
Dylan,
in re. DEBUGIN in the bell-jar:
It'd make me feel better. Smacks a bit of redundancy, I get your point. If the MAWD would work/run on the bench I'd make that jump. Humour me.
If you make that jump and it works out, don't tell me. :)

PJ Allen
04-07-2011, 12:54 AM
If it works in the bell jar with DEBUGINs but runs off in the weeds with the MAWD then we'll know that's an issue.

Mark Kibler
04-07-2011, 01:36 AM
Mr. Kibler, would you be able to conduct the tests for the program on the ASP-Bot as PJ specified? On the bench of course. It would be great if you could report the findings like you have before.

Dylan,

Here are the results of your program "on the bench" (bench tested outside the bell jar). Also see the attached screen shot. You might want to comment out the DEBUG statement that appears in the "sample #" column. That's where the program stopped running.

Here's what appeared on the GUI:


Initializing...


ARLISS - A Rocket Launch for International Student Satellites

ARLISS Team New Hampshire - June, 2010

Temperature, humidity, carbon dioxide, and altitude data logging program


sync tries: 2
disk tries: 1

Time (sec) Sample# CO2(mV) CO2(ppm) Temp(C) Humidity(%) Altitude(ft)

10:10:10 1enter 5digit altimeter data

Program stopped running after the word "data".

-------------------------------------------

Note too, that you have two ARLISS DEBUG messages. One could be deleted to save space.

Standing by,

MK

PJ Allen
04-07-2011, 02:24 AM
Mark,
It's not stopping, it's waiting. It says "enter 5 digit altimeter data" -- so enter the 5 digits of altimeter data, like in the simulation, because it's still simulating at this point.

Please jot down this sample profile:
00000, 00500, 00900, 01000, 01001, 02000, 03000, 04000, 05000, 06000, 06500, 06800, 07000, 07500, 07600,
06000, 04000, 02000, 00500, 00000, 00000, 00000, 00000, 00000, 00000, 00000, 00000, 00000
(cross off each value as you are prompted, it's increasing altitudes till apogee where it begins descent and finally hits the ground.)

** With the ninth 00000 it should result 'Got to Movement' and with each 00000 thereafter. It's going to bounce back all of your sensor data too.

PJ Allen
04-07-2011, 02:45 AM
I wouldn't be surprised if our "status DEBUG line" throws off the sensor data formatting.
Be ready for that. That'll get set right, afterward, when the "status DEBUG line" can be taken out.
We need you to look past that and stay the course.

sylvie369
04-07-2011, 09:10 AM
Phew - I see you guys have done a LOT of work in the couple of days since I was last able to look. I'm afraid I'm on a tight schedule these days - supervising 15 young women trying to design and run their first experiments - and I can only expect to look in every once in a while.

Do I take it that you've figured out the mysteries of MAWD data? Each altitude report is five bytes of digits followed by a CR and a LF. If the altitude is less than 10000, leading zeros are included so that each report is the full five digits. Back in the early pages of the very first ARLISS forum thread there's a nice discussion of this, with some test programs from Tracy, but I think you've worked past that already, right?

PJ Allen
04-07-2011, 12:46 PM
sylvie,
Yes, I think we're squared away on the MAWD format.
Just trying to confirm that the flight-worthy program gets to the "Movement" subroutine, by establishing that we can do so using the DEBUGIN/manual data (simulation) approach.
I'm sure it's going to come right.

sylvie369
04-07-2011, 03:30 PM
I'm glad you were able to step in. They're in good hands. I'm inclined to keep my nose out of the programming entirely again, on the "too many cooks spoil the soup" principle.

There is some chance that the MAWD will _not_ report 00000 as the final altitude, but rather some other close value. If I have a chance I'll go back and look at sample data to see if that really happens and how often, and in what format. If it's common, you might need to account for it.

Mark Kibler
04-07-2011, 03:44 PM
Mark,
It's not stopping, it's waiting. It says "enter 5 digit altimeter data" -- so enter the 5 digits of altimeter data, like in the simulation, because it's still simulating at this point.

Please jot down this sample profile:
00000, 00500, 00900, 01000, 01001, 02000, 03000, 04000, 05000, 06000, 06500, 06800, 07000, 07500, 07600,
06000, 04000, 02000, 00500, 00000, 00000, 00000, 00000, 00000, 00000, 00000, 00000, 00000
(cross off each value as you are prompted, it's increasing altitudes till apogee where it begins descent and finally hits the ground.)

** With the ninth 00000 it should result 'Got to Movement' and with each 00000 thereafter. It's going to bounce back all of your sensor data too.

PJ,

So when the program (seemingly) hangs up when it starts reading and writing data-- when it outputs, "enter 5 digit number" to the GUI-- then I should enter a number, right?"

Next I should simulate a launch by entering 00000, then 00500, then 01000, etc, -----> until apogee (7500 in your example.)

After that, to simulate descent, I should enter 07000, 06500, etc. all the way to the (virtual) ground, where I will enter 00000, 00000, 00000. At that point the "movement" subroutine should kick in. Yes?

Now I understand what all these numbers (00500, 07500, 00000, etc.) meant yesterday, when I couldn't make sense of them.

Which version of the program should I run this simulation on?

Ciao time!

Mark
:cool:

PJ Allen
04-07-2011, 04:06 PM
By Jove, Mark, I think you've got it.
I believe that the modified program in #11, which Dylan uploaded last night, is the deal.

PJ Allen
04-07-2011, 04:13 PM
Regarding Sylvie's last post, I hope that the MAWD keeps knocking out 00000 at the end or that presents another issue.
If I had one, I'd find out.
One crisis at a time.

Mark Kibler
04-07-2011, 04:16 PM
By Jove, Mark, I think you've got it.
I believe that the modified program in #11, which Dylan uploaded last night, is the deal.

Jove Allen,

So should I bench test the program AND run it in the vacuum chamber? Or just bench test it (<------ bench test is my guess since it is a simulation.) But you're the Boss.

I'll download Dylan's program from last night when I get home and try it out.

Signing off from Jupiter (see attached JPEG),

Mars

PJ Allen
04-07-2011, 05:58 PM
1) run "on the bench", as I call it. (modified program, manual altimeter data)

2) run in the bell jar. (modified program, manual altimeter data)

3) MAWD_get routine should be changed back to the original and the MAWD re-connected to the Stamp input. Keep the DEBUG in the Main: dO..LOOP ***
I guess it has to go in the bell jar because, apparently, the MAWD doesn't "go" till there's a change (not specified) in pressure. This is where/how we find how the MAWD kicks data after landing/touchdown.

4) change "Movement" to incorporate your servo routine. ^^^
Once that's working 100% then you can remove the DEBUG from the Main: dO..LOOP and you have your flight-ready example.


modified program = Dylan's work in Post# 11

*** - programming still to be done
^^^ - programming still to be done

PJ Allen
04-07-2011, 06:36 PM
So, in other words, run the program that you tried last night (but thought was stopping).
This, for the time being.
If it doesn't run on the bench then don't bother with the bell jar. If Step 1 is a success, maybe we should progress to Step 3. I will be over the moon with success in Step 1.

sylvie369
04-07-2011, 08:38 PM
Regarding Sylvie's last post, I hope that the MAWD keeps knocking out 00000 at the end or that presents another issue.
If I had one, I'd find out.
One crisis at a time.

If they test it _with a MAWD_ in the "bell jar" repeatedly, and they get it to work consistently, then it's fine. If it doesn't work consistently, and the problem is that it does not detect landing, I would look at the possibility that the MAWD is reporting low but non-zero altitudes.

I believe that I have seen that happen, but it's certainly rare. It _shouldn't_ happen. Again, if I can find the time I'll look through my MAWD data to see if it really has happened, and if so, how often. Sorry to be so vague.

Good to hear that you're making good progress.

sylvie369
04-07-2011, 08:44 PM
I guess it has to go in the bell jar because, apparently, the MAWD doesn't "go" till there's a change (not specified) in pressure. This is where/how we find how the MAWD kicks data after landing/touchdown.

The MAWD enters flight mode when it has detected a pressure drop corresponding to an increase in altitude of 160 feet. In plain English:
- when you arm it, it samples the air pressure for a number of seconds, figures an average, and sets that pressure as the "zero altitude" pressure.
- then it goes into launch detect mode, waiting for a sudden drop in pressure corresponding to what you would expect from rising to 160 feet above the ground (I have, on rare occasions, seen it fooled by excessive winds on the pad and bad vent hole placement).
- when it detects that drop in pressure, it decides that it is in flight, and changes to flight mode. This is the point at which it also begins transmitting data through the serial output line you're connecting to. No data are transmitted until launch detect has happened.
- it looks for an increase in pressure, which happens when the rocket has stopped rising and has begun to drop back toward the ground. At that point, it fires the apogee charge to deploy the drogue parachute.
- it continues to measure pressure, and fires the main charge when it believes it has fallen to the altitude specified for that event.
- upon landing it eventually stops sending data out the serial line. I don't know how it detects landing, or how many data points are sent after landing is detected.

PJ Allen
04-07-2011, 09:10 PM
Good to know, sir.
May have to go with "consecutive" values < 10 ... or something.
Anxiously awaiting the results of "Step 1".

[The best laid schemes o' mice an' men...]

Dylan Landry
04-07-2011, 10:28 PM
Ahh man. Knowing the answer to a question whilst you see people discussing it is very much painful haha.

I just saw some dialog between both of you on the matter that the MAWD could out put not 0's, but numbers close to 0. This matter has come up many times before with us teammates at practices. Lets suppose the MAWD lands with an altitude of 00002, and not 00000. After a few samples that the MAWD takes, (not necessarily samples that are displayed on the screen), and the altitude does not change, the value will automatically be set to 00000.

Mark Kibler
04-07-2011, 11:19 PM
OK Musketeers,

Here we go. I just ran two programs. Both we credit to PJ for getting things rolling along very nicely.

I ran:

1) "Main_Program_with_Controlled_Altitude-April 6, 2011.bse" (post #11 in this forum.)

2) "ASP-BOT MAWD GET - April 6, 2011.bpe" (post #1471 in our other ARLISS forum.)


Both programs read out simulated altitude data beautifully when it's entered manually, in slightly different formats (see attached screen shots.) The Data Logger continues to record actual temperature, humidity, CO2 (mV), and time as it waits for manual data input.

"Main_Program_with_Controlled_Altitude" has no "movement" subroutine for the MAWD to activate.

"ASP-BOT MAWD GET" does have an actual servo movement subroutine at the bottom.

"ASP-BOT MAWD GET" theortically should have activated the servo connected to PIN 14 when a simulated altitude of 00000 feet was manually entered. The servo didn't move but I could have the code written wrong. I believe all the subroutines to make the servo move are somewhere in the "MAWD GET" version.

The simulated launch (data manually entered) seems very successful and the program seesm to work really well at this juncture. Where do we go from here, Rocketeers?

Standing by,

MK
:cool:

Dylan Landry
04-07-2011, 11:27 PM
So it seems like the controlled altitude worked well. Now we must run it in the Bell Jar... Unless you did it for that trial already Mr. Kibler.

Mark Kibler
04-07-2011, 11:29 PM
3) MAWD_get routine should be changed back to the original and the MAWD re-connected to the Stamp input. Keep the DEBUG in the Main: DO..LOOP ***

I guess it has to go in the bell jar because, apparently, the MAWD doesn't "go" till there's a change (not specified) in pressure. This is where/how we find how the MAWD kicks data after landing/touchdown.

4) Change "Movement" to incorporate your servo routine. ^^^
Once that's working 100% then you can remove the DEBUG from the Main: dO..LOOP and you have your flight-ready example.


modified program = Dylan's work in Post# 11

*** - programming still to be done
^^^ - programming still to be done


I think this is where we are now, #3 and #4 above. Does that seem right? Dylan, I'll let you and PJ and Andrew piece the program together from here (#3 and #4?)

Standing by,

MK

Mark Kibler
04-07-2011, 11:31 PM
So it seems like the controlled altitude worked well. Now we must run it in the Bell Jar... Unless you did it for that trial already Mr. Kibler.

Doesn't it still need manual data entry if I run it in the bell jar though? Won't you have to change the MAWD GET subroutine to like it was before so that it works in the bell jar without manual data entry? (see PJ suggestions and my last post)...

???
Mr. Kibler

Dylan Landry
04-07-2011, 11:35 PM
Well that is correct, so I will have to change the program. But then might as well as move on to steps 3 and 4. I will submit the changed program with what I believe will work....

Mark Kibler
04-07-2011, 11:37 PM
Well that is correct, so I will have to change the program. But then might as well as move on to steps 3 and 4. I will submit the changed program with what I believe will work....

Does PJ agree that this is the next step? It seems like a logical next step... but you guys are a step ahead of me already! We seem really close here.

MK
:cool:

Dylan Landry
04-07-2011, 11:42 PM
I have the modified program. I will post it when we are ready.

Mark Kibler
04-07-2011, 11:43 PM
OK. Standing by. Are you writing the program to run in the vacuum chamber by itself, without manual input?

MK

Dylan Landry
04-07-2011, 11:48 PM
Yes, that is already what I have written. Do you want me to post it now?
Or wait for PJ's input?

Mark Kibler
04-07-2011, 11:54 PM
Go ahead and post it and I'll run it and we'll see what PJ says. Should I run it on the bench or in the bell jar, or both?

MK

Dylan Landry
04-08-2011, 12:02 AM
Test it in the Bell Jar. If it is automatic altitude instead of the controlled and you run it on the bench the altitude will stay at 00000. Here it is.

Dylan Landry
04-08-2011, 12:27 AM
I have just checked my Private messages and it seems that PJ will not be on again until tomorrow. I think that we shall proceed without him for today.

Mark Kibler
04-08-2011, 12:50 AM
I have just checked my Private messages and it seems that PJ will not be on again until tomorrow. I think that we shall proceed without him for today.

OK, it runs fine on the bench and in the vacuum chamber. On the bench it measures everything except altitude. In the vacuum chamber it measures everything including altitude (see attached data.)

I'm not sure where that puts us because that's exactly what the ASP did before we started. I suppose the next step is to add a "movement" subroutine to see if the altimeter activates the servo at 0000000. We should use PIN 14.

???
MK
:cool:

Dylan Landry
04-08-2011, 12:59 AM
I'm not sure where that puts us because that's exactly what the ASP did before we started.
Well Mr. Kibler,
These exercises made us able to know that the actual logic behind our program was correct. I will insert a movement program in place of the movement subroutine and report back.

Dylan Landry
04-08-2011, 01:08 AM
This is the new program... It will run the motor attached to pin 14 counter clockwise for 1 second, then resume another set of data, followed by another 1 sec of movement. Of course after it has touched ground. But remember, you have to let it be above 1000 feet for 10 seconds before having it go under 1000 feet. So the program can check the altitude enough times before it starts checking for 0's.

Mark Kibler
04-08-2011, 01:20 AM
I downloaded and ran Dylan's program, above.

In the vacuum chamber the servo runs every second from the time the BOE is turned on until it's turned off. It doesn't wait for the MAWD to activate it at 0000000. The MAWD doesn't seem to do much except measure and record altitude. It does that like it's supposed to.

I need to put things aside for the evening because I'm getting fatigued and I can't think this through straight. I'm not sure where things stand right now. Halfway there maybe??

MK

PJ Allen
04-08-2011, 02:06 AM
Hi.
It looks like there was much progress made. There's a servo glitch?

I was looking at the MAWDget, the flight-worthy version --

feet=0[/COLOR]
SERIN MAWDin,84,64,MAWDnot,[DEC5 feet]
MAWDnot:
RETURN


Note that "feet = 0".
Looks like that makes the default feet data "0" when the MAWD shuts down (and when it's not working, pending activation by pressure change when sitting on the launch pad, too)

---------------------------

Can you nutshell your status for me?

PJ Allen
04-08-2011, 02:13 AM
The rocket has to stay above 1000_ft for 6 passes (ergo the thousandcounter, TC, = 6), so the asp-bot's assumption is genuine flight status achieved, whereupon all 00000 thereafter will be assumed genuine/on-the-ground indications.

I'm buoyed by these results posted, as I hope you all are, too.

PJ Allen
04-08-2011, 04:18 AM
The servo goes on all by itself?
It's supposed to be connected to P14 [X4 on the right side, next to the Vin_Vdd select, and that should be set right (V-dd?), too]

Might want to add a DEBUG to the Movement subroutine (??)

At present, it's:


Movement:
FOR movement1 = 1 TO 43 ' 0 TO 42 ??
PULSOUT 14, 850
NEXT
RETURN


Shouldn't there be a PAUSE before each NEXT, to keep inside the appx 20ms servo refresh repetition rate (50x/sec, 1 ea. 20msec)?



Movement:
DEBUG "movn", CR
FOR movement1 = 1 TO 43 ' 0 TO 42 ??
PULSOUT 14, 850
PAUSE 18 ' ???
NEXT
RETURN


PE -- Dylan, If necessary, verify your servo routine independent of the asp-bot software.

PJ Allen
04-08-2011, 01:29 PM
Something else to consider -- is P14 getting bopped, unintentionally, by something in the rest of the asp-bot software... making for an inadvertent servo pulse?

sylvie369
04-08-2011, 02:32 PM
Something else to consider -- is P14 getting bopped, unintentionally, by something in the rest of the asp-bot software... making for an inadvertent servo pulse?

Would you suggest that they do a search through the program for any reference to "P14"?
Or are you suggesting that something else is making a pulse go out through that pin (despite not referring directly to that pin)?

PJ Allen
04-08-2011, 02:54 PM
"Or are you suggesting that something else is making a pulse go out through that pin (despite not referring directly to that pin)?" That's a possibility, accessing the output register, and thereby P14, (by the seemingly ineffable "somehow".)

The easiest way to tell, I figure, might be going back to "Step 1", BUT substituting their servo routine in the "Movement" subroutine.

Has the servo been connected all along?

Mark Kibler
04-08-2011, 03:01 PM
Can you nutshell your status for me?

Longer than a nutshell. A larger nutshell perhaps. A coconut shell?

1) BENCH TEST:

a) BOE outputs CO2 (mV), temperature, humidity, elapsed time, and "0" altitude as it should.
b) Everything records to Data Logger just fine.
c) Servo attached to P14 pulses every second beginning at BOE boot-up

2) VACUUM CHAMBER:

a) BOE outputs and records CO2 (mV), temperature, humidity, and elapsed time to the Data Logger as it should.
b) Altitude is also recorded to flash drive as it should be.
c) Servo attached to P14 pulses every second beginning at BOE boot-up.

d) Servo does not appear to be affected or activated in any way when the MAWD reaches 000000000000

e) BOE continues to read and write data at altitude = 00000000000000 as it should.
and "0" altitude

----------------------------------------------



PJ said: Something else to consider -- is P14 getting bopped, unintentionally, by something in the rest of the asp-bot software... making for an inadvertent servo pulse?

Yes, I think this may, in fact, be the case. P14 is getting bopped by electromagnetic interference from elsewhere in the circuitry or program.





PJ said: The servo goes on all by itself?

Yes, right at boot-up it starts pulsing every second, seemingly in sync with data collection (which is every second or two.)




PJ said: Has the servo been connected all along?

No, only last evening when the ASP-BOT was bench tested and then tested in the vaccum chamber.

MK

Mark Kibler
04-08-2011, 04:16 PM
The servo goes on all by itself?

Yes


It's supposed to be connected to P14 [X4 on the right side, next to the Vin_Vdd select, and that should be set right (V-dd?), too]

Yes, one servo is connected to P14 at X4 = red, white, and black wires


MK
:cool:

PJ Allen
04-08-2011, 05:03 PM
OK, the servo could only activate based on an actual pulse, not from ephemera like "EMI" or "interference".
Nothing in previous versions or applications have/has been connected to P14.
That it occurs "every second", regularly, is telling - it's coinciding with some process (then.)
My surmise is that the output register is getting "corrupted", unintentionally.

At Initialisation, it gets set LOW:


Reset:
OUTS = %0001001000000000
DIRS = %1111001111110101

But it's changing states outside of the "Movement" subroutine".
Now to find when that occurs.

PJ Allen
04-08-2011, 05:38 PM
I'd always understood the issue to have been that Movement never executed based on the consecutive zeros plan, but now it's on repeatedly?
So, the once per second occurence is a new development?



Movement:

'movementCounter VAR Byte ' Moved to top of program.-D.L, March 19 2011

DEBUG "Movement has Started.", CR

FOR movementCounter = 1 TO 100
PULSOUT 14, 850
PAUSE 20 ' Pause was missing and instead there was the PAUSE 3000 below after the NEXT statement.- D.L., March 19 2011
NEXT
RETURN 'No return was here. Causing returning to the program that called this subroutine impossible.- D.L., March 19 2011

'PAUSE 3000 'Unsure why this was there... Could this of been the source of the problem to why the motors did not move once it red 8 0's? No, it would of debuged the above statement even if the motors weren't moving.- D.L., March 19 2011

Mark Kibler
04-08-2011, 06:28 PM
I'd always understood the issue to have been that Movement never executed based on the consecutive zeros plan, but now it's on repeatedly?


I don't think the movement program is getting activated at all at 00000000. Yes, the servo is pulsing like a femoral artery about every second, at least when I ran the program last night (bench test + vacuum chamber.). I'll repeat teh same progarm tonight to make such it wasn't connected wrong. But I'm certain it wasn't. Nothing else that I could see in the program uses P14.


So, the once per second occurence is a new development

No. It was doing the same thing during our last practice when Dylan and Andrew ran a simulation program (zerocounter + 1 ??)

I pointed this out to them and explained that the wheels (servos) can't be moving inside the rocket during ascent for all sorts of reasons. For example, if you're in the actual vacuum of deep space you'd get rotational torque... not good if you're trying to fly in a straight line. In our project the parachute's shroud lines go through holes in the wheel hubs and they're anchored on the robot's platform. If the wheels move (3 minute ascent, 26 minutes descent), the parachute lines are slowly strangling the robot second by second,1/32 of a turn at a time.

MK
:cool:

PJ Allen
04-08-2011, 06:54 PM
I agree that the servo wheels should turn only under command.

Neither the zerocounter nor thousandcounter subroutines (liftoff, checkliftoff) play with the I/O.

The "last practice"... sometimes you all are calling these sessions "practice", too, but you have your get-togethers as well.

I think we need to talk about revision levels, get back to the last rev level without inappropriate servoing and incorporate the "new stuff" until the problem (re. servos) re-surfaces.

And fine-tooth comb the wiring to the Stamp I/O (P0-15)

Mark Kibler
04-08-2011, 07:09 PM
I agree that the servo wheels should turn only under command.

Neither the zerocounter nor thousandcounter subroutines (liftoff, checkliftoff) play with the I/O.

The "last practice"... sometimes you all are calling these sessions "practice", too, but you have your get-togethers as well.


"Practices" are the bi-weekly build sessions. Forum time is "on-line team time".



I think we need to talk about revision levels, get back to the last rev level without inappropriate servoing and incorporate the "new stuff" until the problem (re. servos) re-surfaces.

And fine-tooth comb the wiring to the Stamp I/O (P0-15)


Agreed. Isolate the variables, one by one. Slow and tedious, but necessary. I propose that we start with a template for the program-- a starting point-- then add to it and keep good a record of the revision history, and the name of the program. Sometimes I'm not sure which version of the program(s) we've adding to, or cutting-and-pasting from.

Re: the wiring, the servo pulsed every second on three different BOE set-ups during our last build session. That suggests it's not a wiring problm (unless all three BOE's were wired wrong, and in the same way.) However, it also pulses on last year's ASP, which uses the same BOE wiring and the same program.

Headed home; more from there later in the evening,

MK
:cool:

Mark Kibler
04-08-2011, 09:53 PM
I'm restarting testing with Dylan's "MAWD GET MOVEMENT" program from post #46 in this forum:

Automatic_MAWDget_with_movement-April 7, 2011.bse

As a point of future reference let's call this "MAWD GET v.1" and add or subtract program code from this version. I'm using this as our starting point unless PJ wants me to go back to an older version. I'll post the results shortly.

Mark
:cool:

Mark Kibler
04-08-2011, 10:09 PM
.
.
BENCH TEST results of MAWD GET v.1: Servo connected to P14, MAWD turned on in data record mode.

1) BOE measures and records temperature, humidity, CO2 (mV), elapsed time, and "0" feet altitude.

2) Servo "jumps" 1/16 turn clockwise when BOE is powered up.

3) Servo moves 1/4 turn counterclockwise between each flash of the red light on the Data Logger. The red light signals data transfer approximately every second.

A. See attached screen shot.

B. See attached data from flash drive/ Data Logger

Off to test the same program in the vacuum chamber now.

MK

Dylan Landry
04-08-2011, 10:23 PM
Why don't we just add a DEBUG statement inside of the Movement subroutine to see if it is the subroutine that is getting triggered? If it does not debug the statement, then we know that the subroutine is not being triggered. Also, i don't believe going back to past programs will help... I took a flight ready program from last year, (one that we would use at the launchpad) and added our changes. The only difference between the program we just tested and a launch ready one from last year are the new subroutines and variables... Thats it. No other changes whatsoever.

PJ Allen
04-08-2011, 10:35 PM
Dylan,
OK by me. That'd tell if it's getting sent to Movement prematurely as I put out there in #50.

Mark,
You've noted the servo kick coincides with the thumbdrive. Intriguing.

All,
What's the power source, a battery or a wall-pack?

Mark Kibler
04-08-2011, 10:36 PM
.
.
VACUUM TEST results of MAWD GET v.1: Servo connected to P14, MAWD turned on in data record mode.

1) BOE measures and records temperature, humidity, CO2 (mV), elapsed time, and maximum (pressure) altitude of 4,873 feet.

2) Servo still "jumps" 1/16 turn clockwise when BOE is powered up.

3) Servo still moves 1/4 turn counterclockwise between each flash of the red light on the Data Logger.

A. No attached screen shot. Serial cable not connected to the BOE in the vacuum chamber.

B. See attached data from flash drive/ Data Logger

Standing by,

Mark

Mark Kibler
04-08-2011, 10:38 PM
You've noted the servo kick coincides with the thumbdrive. Intriguing.

Yes, the servo kick does coincide with the thumbdrive, but BETWEEN thumbdrive data input, about a second apart.



What's the power source, a battery or a wall-pack?

Power source is a rechargeable RC battery. Fully charged.
.

Dylan and PJ, do you guys want to tweak "MAWD GET v.1" and then post the updated program as 'MAWD GET v.2"? Then I'll run it again?

Standing (sitting) by, eating dessert,

MK

PJ Allen
04-08-2011, 10:41 PM
Yes, I'd like to see how/whether it's actually getting into 'Movement' prematurely. Adding a DEBUG to tell would be helpful.

Dylan,
You're the software-meister, we're awaiting your ACK/NAK.

PJ Allen
04-08-2011, 10:51 PM
Here's the v1 with a DEBUG in the Movement subroutine.

Dylan Landry
04-08-2011, 11:08 PM
Well if the servo is moving each time the the data-logger writes on the flashdrive then the servo must be triggered each LOOP through the main program.
About the DEBUG,
If we are adding a debug then we must also attach the 9-pin connector through the bell jar again, will that be a problem?

PJ Allen
04-08-2011, 11:12 PM
If only you guys had a flat/ribbon cable adapter.

Dylan Landry
04-08-2011, 11:17 PM
Can we somehow debug it to the flashdrive? Or will that be too much work? We could use one pin to have a LED go off instead of a debug line.

PJ Allen
04-08-2011, 11:25 PM
I don't know the flashdrive situation.
Here's the manual DEBUGIN program but I commented out Checkliftoff and Liftoff.

>> Has this servo miscue been an issue only since the zerocounter/thousandcounter?

Now I'm wondering if the thumbdrive is driving the voltage down, what with all the other sensors and all.

PE - If the servo twitches with no servo routine, then there's something to ponder.

PJ Allen
04-08-2011, 11:28 PM
How hard would it be to comment out the thumbdrive access (probably a major pain)?

?? - Are you guys on dial-up? Maybe push your F5 (refresh) button once in a while.

Dylan Landry
04-08-2011, 11:43 PM
Just for clarification, what exactly what is the thumbdrive?

PJ Allen
04-08-2011, 11:45 PM
Mark Kibler posted: "Yes, the servo kick does coincide with the thumbdrive, but BETWEEN thumbdrive data input, about a second apart."

PJ Allen
04-08-2011, 11:46 PM
thumbdrive = flashdrive
vinculum, etc?

Dylan Landry
04-08-2011, 11:50 PM
Well the thumb drive has never taken a lot of power. I don't think it would be a problem now.
Also this servo issue has only happened now, never before.

PJ Allen
04-08-2011, 11:56 PM
All that's going on, which has not before, is the addition of the zerocounter and thousandcounter routines, and neither of those tweak the output pins.

But the servo twitch occurs after each flash/thumbdrive access, as noted by Mark (and he's off-line.)

Dylan Landry
04-08-2011, 11:59 PM
So then we should just take out the subroutines and make the servo, lets say... Run every third sample or something? That way we can tell if it is the subroutines or not.
Sorry if you have already suggested that. I was confused and needed some clarification.

PJ Allen
04-09-2011, 12:07 AM
You mean as I was 'advocating' in #72.
Yes, right.

I don't know if there even has to be a servo subroutine at all, so long as the pin14 is an output.
If connecting the servo results in twitching, and there's no call to CHeckliftof or Liftoff (they're commented out), then that's an indication of something amiss (odd, bad.)

PJ Allen
04-09-2011, 12:12 AM
I have mawdsimulation3 running on the bench here and instead of a DEBUG it goes to a servo routine, but the servo only moves when it's supposed to. (a gentle F-Y-I)

Dylan Landry
04-09-2011, 12:14 AM
Well eventually there will have to be a servo subroutine to get our ASP-Bot moving once it hits the ground of course.
I don't think the servo is bad. My servo's that are the same brand and model also move a tiny bit when I plug them in for the first time or turn on the BoE. But then again I can't tell from here since I do not have the ASP-Bot.

Mark Kibler
04-09-2011, 12:16 AM
Here's the v1 with a DEBUG in the Movement subroutine.

RESULTS: MAWD GET v1p5_PJ.bse - Bench tested

1) BOE measures and records all data parameters correctly. Altitude was correctly reported as '0'. MAWD was not on.

2) The servo rotates for about 1 second right between each "flash" of the Data Logger (when the data is measured and recorded.) Data Logger records, servo moves, Data Logger records, servo moves, etc. This is the same thing it was doing in Dylan's program except the servo runs longer in PJ's v 1.5 program.

See attached screen shot. The dishes are done. Standing by.

Mark
:cool:

Dylan Landry
04-09-2011, 12:17 AM
Well PJ, if the controlled altitude versions are working for you, as they did for me, then there must be a crucial difference between the two different MAWD_get subroutines that we are missing.

Mark Kibler
04-09-2011, 12:17 AM
If only you guys had a flat/ribbon cable adapter.

What does that do??

MK

Dylan Landry
04-09-2011, 12:19 AM
It is just a adapter for the 9-pin wire that is extremely flat that we could fit under the bell jar to use DEBUGS and still be able to simulate altitude.

Dylan Landry
04-09-2011, 12:19 AM
Hold on...
The one that you just tested, did it have any pulsout commands?

Dylan Landry
04-09-2011, 12:20 AM
If not then we know that something else is triggering it... Like a section of program outside the movement subroutine.

PJ Allen
04-09-2011, 12:21 AM
There's a PULSOUT routine, but it is preceded by a DEBUG "Movn"
Did "Movn" ever print on the DEBUG window

Mark Kibler
04-09-2011, 12:24 AM
I don't know the flashdrive situation.
Here's the manual DEBUGIN program but I commented out Checkliftoff and Liftoff.

>> Has this servo miscue been an issue only since the zerocounter/thousandcounter?

Now I'm wondering if the thumbdrive is driving the voltage down, what with all the other sensors and all.

PE - If the servo twitches with no servo routine, then there's something to ponder.


I don't think it's a power/ voltage problem. We're using one of the same flash drives we've used all along. Flash drive = thumb drive.

Attached are the results of the MAWD_DEBUGIN_only_v1.bse bench test. No servo movement but the same as last night: enter 5 digits, moves on to next data entry, enter 5 digits, repeat.

See screen shot:

MK

Mark Kibler
04-09-2011, 12:26 AM
There's a PULSOUT routine, but it is preceded by a DEBUG "Movn"
Did "Movn" ever print on the DEBUG window

I believe 'movn' appeared on the GUI but let me run it again to confirm. It does show "movn" on the first screen shot above.

Hold on........

PJ Allen
04-09-2011, 12:26 AM
Mark,
Is there more data preceding that which you've shown? It's showing Movn, but the zerocounter = 9 and the thousandcounter = 6, so that all looks right to me.

Mark Kibler
04-09-2011, 12:28 AM
Yes, "movn" does appear when v 1.5 is run. Servo rotates almost 360 degrees at the same time "movn" appears.

Mark Kibler
04-09-2011, 12:29 AM
Mark,
Is there more data preceding that which you've shown? It's showing Movn, but the zerocounter = 9 and the thousandcounter = 6, so that all looks right to me.

Yes:

1Movn

2Movn

3Movn

etc,

Mark Kibler
04-09-2011, 12:30 AM
It is just a adapter for the 9-pin wire that is extremely flat that we could fit under the bell jar to use DEBUGS and still be able to simulate altitude.

A flat 9-pin serial cable would be handy for vacuum chamber testing for sure.

PJ Allen
04-09-2011, 12:32 AM
So, if you let it sit on the bench, waiting for DEBUGIN data, but you don't enter anything, it just sits, the servo will twitch anyway?

Mark Kibler
04-09-2011, 12:37 AM
So, if you let it sit on the bench, waiting for DEBUGIN data, but you don't enter anything, it just sits, the servo will twitch anyway?

V 1.5? ~ Or ~ MAWD_DEBUGIN_only_v1.bse ?

I don't recall that it twitched but I'll test again.

============================

No twitch whatsoever as the program waits for data input (MAWD_DEBUGIN_only_v1.bse)

Dylan Landry
04-09-2011, 12:40 AM
So then it has to be an issue with the subroutines being inserted into the main program.

PJ Allen
04-09-2011, 12:40 AM
Right now, MAWD_debugin_only_v1.bse
Run the program, let it sit, don't enter anything. Does it twitch then?

Mark Kibler
04-09-2011, 12:42 AM
Right now, MAWD_debugin_only_v1.bse
Run the program, let it sit, don't enter anything. Does it twitch then?

No twitch whatsoever as the program waits for data input (MAWD_DEBUGIN_only_v1.bse)

Mark Kibler
04-09-2011, 12:43 AM
So then it has to be an issue with the subroutines being inserted into the main program.

I agree. But where? Nothing else uses P14. In fact, the only place the number 14 appears in the program is in the date in the comments at the top (June 14) and in the PULSOUT 14, 850 command.

PJ Allen
04-09-2011, 12:45 AM
Hold on...

PJ Allen
04-09-2011, 12:48 AM
Please run the attached program, but do not enter any data, let it sit there waiting.

Then report back.

Mark Kibler
04-09-2011, 12:48 AM
I have mawdsimulation3 running on the bench here and instead of a DEBUG it goes to a servo routine, but the servo only moves when it's supposed to. (a gentle F-Y-I)

OK... so what's different about PJ's mawdsimulation3 ---------------------> Dylan? that makes the servo only run when it's called on in the program? Is it a DEBUG statement causing the servo to be "frisky"?

PJ Allen
04-09-2011, 12:50 AM
Mark,
Let's leave that go for now and stay the course.

Mark Kibler
04-09-2011, 12:51 AM
Mark,
Let's leave that go for now and stay the course.

Aye, aye. Staying the course. Full speed ahead with ==============> Main_Prgrm_w_Controlled_Altit_040611_PJ.bse

Stand by.....

Mark Kibler
04-09-2011, 01:00 AM
Bench test results: Main_Prgrm_w_Controlled_Altit_040611_PJ.bse

1) GUI prompts for 5 digit number

2) Number is entered as an altitude

3) GUI shows all data (CO2, temp, altitude that entered, etc.) correctly.

4) Servo moves at the very same time data is entered, for about 1 second.

This is good. Dylan, this is what we want the ASP-BOT to do when it lands on the desert floor: move and collect data as it moves.

see screen shot

Standing by,

MK

PJ Allen
04-09-2011, 01:04 AM
Now, wait. I requested that you not enter any data and to report back.
I'm sorry if that seems scolding but I'm trying to get a baseline
I need to ask more questions.

PJ Allen
04-09-2011, 01:06 AM
Please acknowledge.

Mark Kibler
04-09-2011, 01:09 AM
Please acknowledge.

Here! Here! Can you clarify how you want me to run the program?

I'll run the program and NOT enter any data, then report back. Oops.

PJ Allen
04-09-2011, 01:13 AM
Please let me know when you have the Stamp/asp-bot underway.
When it prompts you for data, please do not enter.
Then report back that it's ready and note any servo movement you may have observed.

Mark Kibler
04-09-2011, 01:14 AM
Main_Prgrm_w_Controlled_Altit_040611_PJ.bse - baseline: no data entered.

1) No servo twitch whatsoever at power-up

2) Program prompts user (me) to enter 5 digit number. User does not enter a number. Neither did I.

End of bench test. Program and User are both standing by.

Sincerely Yours,

:blank: <----------- > :cool:
Program <------> User

Vote for your favorite icon: Program? or User?

PJ Allen
04-09-2011, 01:16 AM
OK, good

Please enter the following series of "altitudes"
After each, please note any servo activity after each

00000
00100
00200
00300
00400

Mark Kibler
04-09-2011, 01:17 AM
Ok. Initializing now.... (User)

Mark Kibler
04-09-2011, 01:20 AM
OK, good

Please enter the following series of "altitudes"
After each, please note any servo activity after each

00000
00100
00200
00300
00400

Entered all the "altitudes" as above and the servo did not move a twitch. So what did you find PJ? What's causing the twitch? What's the variable?

PJ Allen
04-09-2011, 01:23 AM
Hang on, Mr Kibler (Test Operator.) Let's stay with the plan.
All will be explained.
Same drill as before, different numbers, more of 'em.


00500
00600
00700
00800
00900
01010
01500
02000
03000
04000

Mark Kibler
04-09-2011, 01:25 AM
Roger Dodger (but do you expect different results than before?) Shouldn't it run the same as with 00000 -------> 00400. We'll see here in a segundo.

Here we (Program and User) go

Mark Kibler
04-09-2011, 01:29 AM
You Clever Guy!

You added movement to the program didn't you? The servo moves right on cue when each of the "altitudes" (above) were entered and it ran for ~ 1 second. No ancillary twitching whatsoever (by the servo or by the User).

Standing by.

Did Dylan fall asleep?

PJ Allen
04-09-2011, 01:31 AM
If it moved with each of those altitudes, that's not good, because it is still in flight.
If didn't move with any of the first, but it did with each of the second set?

Mark Kibler
04-09-2011, 01:34 AM
Yes, it didn't move on the first altitudes (00000 ------> 00400) but it DID move at 00500 ---------> 04000. Let me test both data sets again to confirm. Hold on.... (or get a cookie or two =====> 2 trials)

Dylan Landry
04-09-2011, 01:40 AM
This is very confusing... For the servo to move at all if HAS to have alteast 6 inputs of over 01000 and then at least 9 readings of 00000.

Dylan Landry
04-09-2011, 01:41 AM
Have we checked if anything else is using or sending signals to PIN 14?

Mark Kibler
04-09-2011, 01:43 AM
OK, the results I gave you were correct: The servo moved with data entry from 00000 -----> 00400 but then it didn't move from 00500 -----> 04000. When I ran it again it moved with data entry at all altitudes, with both data sets. Here's why:

The first two tests I left the BOE on and simply uploaded the program with the BOE's power "ON". The servo didn't move with data entry at 00500 -----> 04000.

This time I turned off the BOE between data set entry and the servo moved at every altitude (00000 -----> 00400 and 00500 -----> 04000)

OK?

PJ Allen
04-09-2011, 01:45 AM
No. Not good.
I'm looking at the program.
Hang on.

Mark Kibler
04-09-2011, 01:45 AM
This is very confusing... For the servo to move at all if HAS to have alteast 6 inputs of over 01000 and then at least 9 readings of 00000.

PJ has manually overidden (changed) the program to move with any altitude/ data entry. He's trying to find what's causing the servo to twitch. I think.

Mark Kibler
04-09-2011, 01:47 AM
Hanging on (see attached.)

Mark Kibler
04-09-2011, 01:49 AM
This is very confusing... For the servo to move at all if HAS to have alteast 6 inputs of over 01000 and then at least 9 readings of 00000.

I think because of the way he's writing the program-- to find what's causing P14 to move-- this function has been "overridden" too. At least for now.

PJ Allen
04-09-2011, 01:51 AM
There was something else.
Please turn off the BoE. Then turn it back on and re-program it with the attached program.
There should be no twitching, except some brief little shudder at the beginning which is unavoidable (not unusual.)

Please enter the following data when prompted, and note any servo activity with each:

00000
00100
00200
00500
01010
02020
03030
04040
05050
06060
07070

and then report back with your findings and I will give you more data.

Mark Kibler
04-09-2011, 01:58 AM
Results: One servo rotation each time data/ altitude was entered. No additional servo movement; no twitching.

MK

PJ Allen
04-09-2011, 02:03 AM
OK
I had been referring to movement as twitching.
I changed the movement routine by adding a PAUSE 18 (for the servo refresh timing).

Mark,
Can you push the reset button on the BoE and enter the first 4 set of numbers and screenshot that?

Mark Kibler
04-09-2011, 02:17 AM
No program movement when reset button is pushed and when 00000 ----> 00400 are entered. Switch is in the #2 position. I lost the screen shot and I'm doing it again.

Mrs. K says 10 minutes until bedtime; I have to be at Harvard at 8 AM...!

PJ Allen
04-09-2011, 02:19 AM
Well, that's all as it should

PJ Allen
04-09-2011, 02:22 AM
When will you be available again, Mark?

Mark Kibler
04-09-2011, 02:23 AM
OK, here's the screen shot. The movement portion of the program did not work after I pressed the reset button; it did the first run through the data set. When I entered 00000 -----> 00400 (after I depressed the reset button) I got only altitude, but no movement...

???

PJ Allen
04-09-2011, 02:25 AM
That is as it should be, Mark.
I'd like to get your cellphone#. We need to talk.

Mark Kibler
04-09-2011, 02:27 AM
When will you be available again, Mark?


I'll be on-line tomorrow evening about the same time. But I certainly don't want to monopolize your valuable time PJ. You've been so gracious in sharing your time and expertise already, and very helpful.

I'm not sure where we're leaving things tonight. It seems like we've backtracked, but it also seemed necessary. I got lost as to the "why" about halfway through but you and Dylan seems to have a handle on things. I'm content to be the bench lacky and simply test your programs!

What do you think?

Mark Kibler
04-09-2011, 02:30 AM
That is as it should be, Mark.
I'd like to get your cellphone#. We need to talk.

I don't keep my cell phone on much at all. I'm more of an on-line, "ET Phone Me At Home" person (evenings).

You're probably just as well off calling Dylan. He's already surpassed my skillset....!

PJ Allen
04-09-2011, 02:30 AM
You're the only guy with a complete asp-bot, so you're the Test Operator, Mark.

It's doing what it ought to at this point, nothing, it thinks it's flying, no movement. Yippee!

OK, what time tomorrow?

PJ Allen
04-09-2011, 02:32 AM
I wrote those down. Please delete them (if you want to stay private.)

What time tomorrow, I think we're there, but you're off to Slumberland (Harvard.)

Mark Kibler
04-09-2011, 02:32 AM
How does 7 PM tomorrow (EST) work? It's 10:30 PM here right now. Are you 3 hours different, or 4? Have you had dinner yet?!

PJ Allen
04-09-2011, 02:34 AM
I'm west coast time. Till tomorrow at 7pm eastern.
OK?

Mark Kibler
04-09-2011, 02:37 AM
.
M. Kibler is off to Slumberland (Harvard? Slumberland?) See you all tomorrow around 7 PM EST. "It was fun" seems so trite. How can I say how much fun it REALLY was?1

Over and out,

MK
Punched the time clock at 10:36 PM

Mark Kibler
04-09-2011, 02:37 AM
Thanks PJ. 7 PM it is.

PJ Allen
04-09-2011, 10:55 PM
It's Saturday...
Are You Ready?

Mark Kibler
04-09-2011, 11:00 PM
Like clockwork. Back from Harvard (but just barely),

PJ, can you help us understand why we were doing what we were last night in short and simple terms? Some of the other team members and parents were following along on the forum and they were trying to understand what we were doing. I tried to explain it by PM, but words failed me because I lost continuity about halfwat through.

How does last night's work fit in with getting the rover to move and collect data after in lands? I think that's what they would like to understand.

:cool:

PJ Allen
04-09-2011, 11:19 PM
Here's the program att'd

Mark Kibler
04-09-2011, 11:21 PM
Here's the program att'd

Got it downloaded A-Ok and it's waiting for me to enter 5 digits.

PJ Allen
04-09-2011, 11:23 PM
Here is the data profile --

00000
00100
00500
01010
02020
03030
04040
05050
06060
05050
04040
03030
02020
01010
00500
00100
00000
00000
00000
00000
00000
00000
00000
00000
00000
00000
00000
00000

! !

Mark Kibler
04-09-2011, 11:32 PM
.
Results:

1) All data outputs to the GUI as it's supposed to: correct temperature, humidity, elapsed time, CO2 (mV). Altitude is the same what was entered by user. No servo movement wnatsoever; no twitches ;-)

2) At 00000, no servo movement.

3) At the second 00000, the servo moved for ~ 1 second.

4) Each time after that, when 00000 was entered the servo moved for 1 second.

5) 00000 -----> servo movement (1 sec) -----> 00000 -----> servo movement -----> 00000 -----> movement, etc.

Looks good!

PJ Allen
04-10-2011, 12:08 AM
Here's the program with the mawd activated

PJ Allen
04-10-2011, 12:54 AM
Phew!
We've turned the corner.
I'm glad it's turning out.
I think you guys can start packing
your suitcases for Nevada.
(Don't forget: Hats.)

Mark Kibler
04-10-2011, 01:05 AM
.
.
EUREKA!

Tonight, thanks to PJ and Dylan's work, the ASP-BOT moves when it lands! We are indebted to PJ for giving us his time and expertise, and to Dylan and PJ for their diligence is seeing this problem through to good (great!) resolution. Please be sure to thank PJ for his help, everyone.

There are a few minor "tweaks" to be made in the program and I'd like Dylan and Andrew to work on these the next time we meet. But we're over the hump as far as getting the ASP-BOT moving once it lands. :smile:

PJ said that he'll be monitoring the forum and that he'll assist you as needed. But let's not wear out our welcome, either. He's already given us plenty of his time.

Now for the "bad news": we're out of PINs and there's no place to plug in the second servomotor on the BOE! You've aleady figured out what this means, right? We have to run two wheels with one motor....! Rocketeers, put your thinking caps on. We have a mechanical engineering challenge to solve.

Thanks again for all your help, PJ ~ !

Mr. (Mark) Kibler
:cool:

sylvie369
04-10-2011, 01:22 AM
Wow. You guys have been on fire the last day or two. I think the rocketeers owe PJ a major debt of gratitude (and maybe one of those great ARLISS t-shirts?). I'm very impressed at the amount of time and expertise he has put in here - a very worthy successor to Tracy.

Mark Kibler
04-10-2011, 01:39 AM
Wow. You guys have been on fire the last day or two. I think the rocketeers owe PJ a major debt of gratitude (and maybe one of those great ARLISS t-shirts?). I'm very impressed at the amount of time and expertise he has put in here - a very worthy successor to Tracy.

On fire indeed ~ ! I would say blazing. PJ sure has been a great catalyst for our project and our programmers, and a fine role model of diligence. We couldn't have done it wiithout him. I think an ARLISS T-shirt is the very least we can do. We certainly owe him more than our undying appreciation and admiration. Maybe a new car? Or a new dog? What to get him, what to get him...?!

No small thanks to you too, Sylvie. You've been a stalwart of advice and support and your input and guidance have been invaluable. You've taught these kids a lot, much more than just technical expertise. Consider everything you and Tracy and PJ have role modeled: community service, fine character, humor and humility to name a few. These, in my estimation are more important than a robot, which is simply a vehicle for learning.

Today was rip-roaring fun at Harvard. The SEDS project team all got their Level 1 rockets built... six, 3-inch diameter x 42" tall scratch-built rockets. Our four-hour build time stretched into 6-1/2 hours but we got them all built, painted, and (almost) launch ready. I even built one with them. It has cool, clear plexiglass fins and I named it "Veritas." A good day's work but I had to rush back to New Hampshire for my 7 PM conference call with PJ. We talked for quite some time as we zapped programs and posts to the forum back and forth. But what a day it was today, with a lot accomplished. I'm glad it's Saturday so I can relax.

Do have any 'favorite' TARC teams in the hunt this year?

Mark

Mark Kibler
04-10-2011, 10:17 PM
April 9, 2011

Attached are current pictures of the ASP-BOT so that everyone can see how much space is-- and isn't-- available on the clear plexiglass platforms. If we add much more, something may have to be removed. The shortwave transmitter? The CO2 sensor and ADC chip? Maybe trade the big heavy RC battery for alighter lithium battery? Physical space will ultimately make some decisions for us.

sylvie369
04-11-2011, 01:37 AM
Do have any 'favorite' TARC teams in the hunt this year?

Pavel's Mad West teams again, of course.

Man, I haven't been to a rocket launch this year at all yet, other than one little low power launch at a new field back in January. I've got the urge, but no time.

Mark Kibler
04-11-2011, 01:52 AM
Pavel's Mad West teams again, of course.

Man, I haven't been to a rocket launch this year at all yet, other than one little low power launch at a new field back in January. I've got the urge, but no time.

Yeah, Pavel's Mad West TARC teams are as predictable as clockwork. But then, good science should be predicatable. I wonder how many test launches they make before they do their qualifying flights? I'll bet they go through a few thousand Newton-seconds of thrust getting ready.

I haven't launched a rocket since ARLISS either. I've worked on a lot of rockets for other people but nary a launch I've had. The group at Harvard got their Level 1 rockets pretty much finished on Saturday. We did a 6-hour build session and we went from start to finish, including the paint job. You should drop them a PM on the Harvards SEDS e-mail link and ask them how they think it went. I'm buildng a rocket with them, a 3" diameter x 42" beast with clear plexiglass fins. In the spirit of Harvard I'm naming it "Very Fast". Tee hee. We'll see who gets the double entendre.

Mark
:nerd:

Mark Kibler
04-13-2011, 05:54 PM
PJ,

The CO2 sensor and ADC are wired and mounted on the rover and it's spitting out data as we speak. I set the CO2 sensor Trip Level at 1000 mV and "input" millivoltage wanders from around 991 to 1050 or so. CO2 mV wanders from around 1392 to1456. Last year the data was tight-- very little variation-- and this wide range of data indicated a loose wire or somethin similar. When we had the system dialed in last year the Trip Level and CO2 mV both stayed within 0.002 or 0.003 or so. But the rover is pretty much assembled, all the major parts or installed, and the software doesn't show any major problems. Whew ~ ! That's good news, and BIG progress.

I've had 5 or 6 kids in my study hall "Advisory" class working on the wiring the last several days-- more unseen faces in the project-- and this may account for the "loose wires" (??) and the variation in data (**See attached screen shot - the third column is input mV and the fourth column is CO2 millivoltage.) When it gets here were work on getting the ServoPal and servos working, and fine tuning the wiring. Thanks again for the servo controller and the wire harness, PJ.

Mark
:cool:

=======================================

Added an hour later:

I swapped out the round CO2 sensor, not the whole module, and the data smoothed out nicely. There is little or no variation in the input millivoltage now (ranges from 1001 to 1004 mV) and the CO2 millivoltage is equally stable. There are no large jumps (e.g. from 1094 to 1164) in the CO2 mV either; the changes are small and stable. Good, good news. Things are wired correctly.

Compare column the data in column 3 and 4 in the second (good) screen shot with the first screen shot. Much less variation. ;-)

Of course I jinxed things. As soon as I took the second screen shot the data started to "stray" again...

Mark Kibler
04-15-2011, 06:45 PM
PJ,

Jake and I worked on the program in class today. We cut and pasted from your "ServoPal" program into Main_Prgrm_w_Controlled_Altit_040611_v2p5_PJ.bse (WAMD/ARLISS forum, post #150).
Doggone it, we're close! The servos both activate and rotate in the same direction beautifully and your ServoPal and extender-adapter solution work beautifully! ===> :smile:

However, after we added the ServoPal code to the Main_Prgrm_w_Controlled_Altit program and bench tested the rover/program, the servos initiated between the 8th and 9th Zero Count on the debug screen. It did this before the altimeter is even in the vacuum chamber.

It seems that some program code is out of place but we couldn't figure out exactly where. I had 22 other kids in the classroom wanting to "help out", I was trying to teach Jake the logic and the "flow" (the Zen) of the program, and I couldn't concentrate well enough to figure out which line(s) of code were out of order. I'll tackle it again when I get home.

Does any program code jump out at you as being out of place?

Thanks,

Mark, Jake and The Twenty Two
:cool: + :innocent: + 22 :lol:

PJ Allen
04-15-2011, 07:44 PM
Maybe you're "re-starting" ("re-doing") your test without pushing the Reset button on the BoE?
You must push the Reset button after any test or interruption, that's the only way to clear
those ZC and TC counters.

I added a couple of Stop commands to the ServoPAL initialisation routine in the program attached.
I'll see how you're doing when I get home later this afternoon.

PJ Allen
04-15-2011, 10:34 PM
I didn't have PBASIC_IDE available where I was made my Reply above. To look at it I had to change it to a .TXT and then I couldn't un-TXT it. I didn't see that till after I uploaded it, maybe that made for even more angst.
It seems that maybe you got caught up with "the 22" and didn't push the Reset button?
[Push the BoE Reset button.]
It wouldn't hurt to issue some STOP commands to begin with. Just to make sure that it's stopped from the beginning, so I kept them in the .BSE attached to this post.
There's no reason for the Servos to Go without being commanded to -- TC > 5, ZC > 8 is the only way that is possible.

PE -- You still have the DEBUG line in the Main_DO..LOOP (that should beomitted from the final version). You should be able to read the status of TC and ZC. When/once TC = 6 and ZC = 9 then the servos will turn.

PJ Allen
04-15-2011, 11:00 PM
I saw that P14 was declared twice, once as nInp (servoPAL way) and then as Servo (old way). I omitted the latter.

I modified the 'Movement' subroutine so that it will only get called once, from that point on it will keep rolling ("as per" the ServoPAL plan).

Mark Kibler
04-15-2011, 11:14 PM
I saw that P14 was declared twice, once as nInp (servoPAL way) and then as Servo (old way). I omitted the latter.

I modified the 'Movement' subroutine so that it will only get called once, from that point on it will keep rolling ("as per" the ServoPAL plan).


PJ,

You were right in your first post. The BOE simply had to be reset after its first start-up/initialization. When it's started on the bench the servos activate when the program reads ZC > 8. When it's reset and put into the bell jar, then when it comes "back to the (virtual) ground" (altitude = 0), the servos kick in perfectly...!

I'll download your new programs and compare them and report back. After dinner that is. Mrs. K has fresh oregeno bread, corn, and mustard and collard greens. If only I could upload the aroma...!

I didn't mean to bother you at work though I appreciated your reply.

More later,

Mark
:cool:

Mark Kibler
04-17-2011, 01:33 AM
PJ,

Attached is an operational version of the program, open to interpretation (tweaking, critcism and humor.) It's called "Rover - Launch Ready" because essentially it is, launch ready. It's pretty much the same program that was posted above. If we had to launch tomorrow it would probably do just fine, don't you think?

Now that we're at a good "pause point" I'd like to sit back and examine the program long and hard to get a more complete understanding of how it really works. I'd also like to clean up the code a bit, if you think that will do any good (streamline DEBUG statements, etc.) Or does the axiom, "Leave well enough alone" apply here?

:thumb: <------------ (This is you Conscience speaking. "When in doubt, leave well enough alone, Mark.")

Thanks ever so much for sharing your time and expertise PJ.

Mark
:nerd:

PJ Allen
04-17-2011, 02:41 AM
OK.
I've attached your version with a couple of minor Revs:


I looked it over and saw that you commented out the DEBUG for ZC/TC (troubleshooting.)

I saw that PIN 14 was declared for nInp (for the ServoPAL) and Servo, so I omitted the latter.

As I mentioned in #162, "Movement" would be more efficient were it called only once. I guess it doesn't hurt anything to call it repeatedly (as it is.) It's horribly redundant, but
I'm not going to force the issue. Howbeit, I did make mention of this as comments in
"Movement" and would be much obliged for your leaving that note there.


If you're happy then I can live with it. :)

Mark Kibler
04-17-2011, 01:00 PM
OK.
I've attached your version with a couple of minor Revs:


I looked it over and saw that you commented out the DEBUG for ZC/TC (troubleshooting.)

Yes, this made the data on the GUI easier to interpret. Adding the statement, 'PUSH REST BUTTON" serves as a dual reminder that the first time through, the ZC is active,
.


I saw that PIN 14 was declared for nInp (for the ServoPAL) and Servo, so I omitted the latter.

I noticed that a few days ago too. But I simply left it for minds more clever than mine to decipher. Thanks for omitting (so what DOES a program do if a PIN is called on twice like that, by different names?)
.

As I mentioned in #162, "Movement" would be more efficient were it called only once. I guess it doesn't hurt anything to call it repeatedly (as it is.) It's horribly redundant, but
I'm not going to force the issue. Howbeit, I did make mention of this as comments in
"Movement" and would be much obliged for your leaving that note there....
This could be modified so that Movement is only called once by resetting ZC, TC = 0, but it doesn't hurt anything to come back here (repeated Calls to this subroutine) though it does 'defeat' the purpose of the ServoPAL.
.
Can you please explain this in Braille so I can understand it? How exactly does it end-run the ServoPal if it makes both servos moves in tandem?



If you're happy then I can live with it. :)
.

.
Blissful would be more precise. Or ecstatic. Or relieved. I have lots of irons in the fire (though I'm sure you do, too) and it's nice to have the light at the end of the tunnel shining on cherubic faces. There are still some relatively minor mechanical things to finish and it's really nice to have programming "done". As you've figured out, while I do understand the basic's of BASIC, programming isn't my forte. My learning curve-- and the kids'-- is becoming more than flat-line though, thanks to some excellent on-line mentoring.

We had a potentially "Oh My Gosh" moment yesterday. I got the 7.2, 4000 mAh battery from "Batteris Plus" and they had soldered wires and a 9-volt battery connector on so we can connect it to the BOE. The wires and the connector were too thick to fit bewteen the 110 V and 9 volt plug-ins on the BOE so we cut the wires and soldered a thinner wire with a different end onto the battery pack's wires. Then we plugged it in. Guess what happened? When the BOE was turned on, nothing (*visible) happened. "Why?" you ask, as I did. Because the damage was already done.

We hadn't noticed that adding the battery end had essentially reversed polarity...! Red was black and black was red. BOING! =====> :thumb: (*moment of instant realization.)

We unplugged it immediately but the damage was done. Thankfully "all" that we fried was the CO2 sensor module, which we had mounted right on top of the rover's platform. That makes the fifth CO2 $en$or we've went through. "Ouch" to the wallet (and please don't tell Mrs. K.) Lesson learned again, the hard way, but the rover runs beautifully after the new COs sensor was added.

Practice at 1:00 today. We'll update you during or afterwards. Any suggestions for us before practice starts, Commander?

*Sung to the tune of "Vaya Con Dios":

"Now the hacidenda's dark, the town is sleeping.
And the time has come to part, the time for weeping.
'Vaya con huevos', compadres... (egss for breakfast)


Yawn,

Mark
:coffee:

PJ Allen
04-17-2011, 02:54 PM
You guys need a voltmeter. When making power connections you need to know: assume nothing.

I don't know where to begin.

I don't "do" Braille, I "do" heat - for when they feel the heat then they shall see the light.

Don't look at the ServoPAL as some "two-servos from one pin mystery device". Properly understood, it is a servo manager that autonomously oversees as many as two servos.

The asp-bot's mobility (via servos) was/is effected by the states of two status registers; zerocounter (ZC) and thousandcounter (TC). When the ZC & TC thresholds were met then a servo routine ("Movement") would be executed each time the MAWD was polled.

Formerly, with no ServoPAL, to move the asp-bot, it was necessary to run a basic servo routine, subject to servo pulsing and refresh requirements. The result was that the asp-bot would move forward briefly and then exit to the sensor reading functions (the Main:DO..LOOP) whereupon it would come around, necessarily, to execute the Movement routine, again, and so on.

Presently, the asp-bot is equipped with a ServoPAL. The ServoPAL manages the servos. The ServoPAL, a model of obedience and compliance, only needs to be told what to do once and will manage the servos as commanded, till commanded otherwise, with no further oversight.

The ROVER LAUNCH READY program, as it stands, continues to command the ServoPAL with every MAWD poll. If the object is, having landed, to get the asp-bot underway then one should simply command the ServoPAL as appropriate, because the ServoPAL takes over from there (as previously explained.) From that point, it serves no purpose to keep telling it to do the/that same thing, over and over again [emphasis], especially if it's doing what it should already.
(Imagine "the boss" telling you to mow the grass. You start the mower and start pushing it about only to have "the boss" tell you to mow the grass with each pass of the mower across the yard. Same thing.)

Mark Kibler
04-18-2011, 12:26 PM
You guys need a voltmeter. When making power connections you need to know: assume nothing.

I don't know where to begin.

I don't "do" Braille, I "do" heat - for when they feel the heat then they shall see the light.

Don't look at the ServoPAL as some "two-servos from one pin mystery device". Properly understood, it is a servo manager that autonomously oversees as many as two servos.

The asp-bot's mobility (via servos) was/is effected by the states of two status registers; zerocounter (ZC) and thousandcounter (TC). When the ZC & TC thresholds were met then a servo routine ("Movement") would be executed each time the MAWD was polled.

Formerly, with no ServoPAL, to move the asp-bot, it was necessary to run a basic servo routine, subject to servo pulsing and refresh requirements. The result was that the asp-bot would move forward briefly and then exit to the sensor reading functions (the Main:DO..LOOP) whereupon it would come around, necessarily, to execute the Movement routine, again, and so on.

Presently, the asp-bot is equipped with a ServoPAL. The ServoPAL manages the servos. The ServoPAL, a model of obedience and compliance, only needs to be told what to do once and will manage the servos as commanded, till commanded otherwise, with no further oversight.

The ROVER LAUNCH READY program, as it stands, continues to command the ServoPAL with every MAWD poll. If the object is, having landed, to get the asp-bot underway then one should simply command the ServoPAL as appropriate, because the ServoPAL takes over from there (as previously explained.) From that point, it serves no purpose to keep telling it to do the/that same thing, over and over again [emphasis], especially if it's doing what it should already.
(Imagine "the boss" telling you to mow the grass. You start the mower and start pushing it about only to have "the boss" tell you to mow the grass with each pass of the mower across the yard. Same thing.)

Vaquero PJ Sundance,

Hacienda Kibler was hopping this afternoon. Lots of great progress and lots of happy, animated faces. The kids were thrilled to so (y)our rover ramble along the ground like a caffeinated chipmunk. It (the rover, not the caffeine) energized and buoyed them and they shifted into a higher plane of excellence because of it. Thanks.

The last "big" hurdle is that doggone parachute release mechanism. Justin and Jake had two excellent ideas and they came with two full-blown prototypes. Either idea would have worked but the Design Team opted for "The (Rube) Goldsberry Invention." Whether the decision was collective or unilateral is uncertain. Jake (of Goldsberry fame) has a full-sized prototype made of Legos and Lego motors, and two of our rover wheels, to work with. I'm eager to see what they end up with but I'm certain it *will* work.

Ah yes, the voltmeter. The good news is that we have one. That not-so-good news is that "someone" didn't use it to check polarity before installing the battery. "Someone" assumed that red = positive and black = negative but that is not the always case. Le$$on learned the hard way. Now if I could just get my hands on that "someone"... I would clap my hands. "Mis manos son mis manos."

That business about the boss telling you how to mow the grass each time you come around with the mower: did my wife e-mail you and tell you to tell me that the grass needs mowed. (*I asked her not to do that.) She always stands by the side of the yard every time I come around with the mower... How do I program her and/or the rover with just one program command so the WifePal/ServoPal program isn't repetetively redundant? I'll muse over the program code to see if I can figure it out on my own (for once.) I may need help though.

I hope you're not diabetic. Expect treats soon. The kids and I are very appreciative of all you've done to help us along.

Vaya con queso mi amigo. Hasta manana,

Pepe
:cool:

Mark Kibler
04-21-2011, 01:18 AM
PJ,

The Parallax servos use a 650 or 850 PULSOUT for full power. If you use a non-Parallax servo, how do you know what PULSOUT value to use? How did you know how to use a value of 500 and 1000 for the "nInp" (and why is it called nInp?) Why did you use a value that's different than 650 and 850?

I remember that, at some point in the past, we had a Vex servo connected to the BOE. When we used the same 650/850 values (or similar values), the Vex servo pulsed erratically. While I understand the basic premise of what makes a servo run (the pulse length and its corresponding value determines the movement) I really don't understand the theory in simple terms. Would you mind clarifying?

Thanks,

Mark

PJ Allen
04-21-2011, 02:43 AM
OK

Servo operation is based on the pulse width of a regular timing pulse. Typical servo pulse widths are in the range of 1ms to 2 ms (that's 1000us to 2000us.)
PULSOUT 650 effects a pulse width of 1300us, PULSOUT 850 effects a pulse width of 1700us (PULSOUT val * 2).

In the following, my numbers are valid given a general sense, it's concepts and relationships not concretes and strict exactness here. There's not a lot of precision with these hobby servos, they all vary, so when I state some value, in practice that means "about".
With a standard servo, the type with limited range (180deg), 0 deg is achieved with 1000us, 90 deg with 1500us, and 180 deg with 2000us.
With a continuous servo, the spinning sort, the pulse width doesn't vary the position but the direction and the speed. So, full full-bore one direction is 1000us and full-bore the other direction is 2000us; 1500us is a sort of neither one nor the other, where you're very slow and on the verge of neutral.

[Another important aspect is the repetition rate of the position/direction pulses - they must occur regularly: the 20ms rep rate (50 times / sec, 50pps, 50Hz). That much is managed by the ServoPAL, no matter which servo type is used.]

So far as why I used/chose the values that I did in my demonstration and so on, they were based/chosen on the operating premise previously explained. As I stated, every servo is different, within a reasonable range but nonetheless, and given some particular value each will position slightly differently or spin at a slightly different speed. There's a certain tolerance, or range, that you have to deal with, expect, integrate; and when you want to have two servos operating in harmony you have to experiment with (jockey) the values a little.

Given all that, you see, it's not as simple as me popping you a universal value. You guys need to play around with this stuff a little outside the asp-bot program. Just get one of your BoEs without all the other stuff and run the demo with the servos, change the numbers, observe, take notes: find what's appropriate for your servos and your situation. That's what this stuff is all about.

I think that all/most hobby servos operate on this same 1-2ms envelope/premise (Parallax/Futaba, VEX, too.)

Mark Kibler
04-22-2011, 12:55 AM
~ Helpful technical explanation. Just what we needed. ~ Thanks!

:cool:
M. Kibler