MAWD - ARLISS Team NH
Dylan Landry
Posts: 235
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...
Comments
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
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.
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.
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".
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.
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.
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.]
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.
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.
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
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.
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.
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?
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.
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.
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:
I believe that the modified program in #11, which Dylan uploaded last night, is the deal.
If I had one, I'd find out.
One crisis at a time.
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
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
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.
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.
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.
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...]
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.