Even though all PBASIC Help's IF..THEN examples go to Addresses, and the IF..THEN..ELSEs do operations, by experimenting with DEBUGIN I find that an IF..THEN math operation works.
I'd like to see the testing we'd mentioned last night: MAWD data along with zerocounter and thousandcounter status. Note Bene -- Zerocounter and Thousandcounter can overflow if a MAX is not specified.
An example is attached, so you can see what I mean. (Hope you have access to your BoE, et al.)
-- PJA --
Just downloaded and ran PJ's "MAWDifthen.bs" program to the ASP-BOT sitting on the table.
Results:
1) No information or data appeared on the GUI (graphic user interface, or computer screen)
2) Nothing was written to the flash drive and the Data Logger didn't initialize.
I'm going to download Dylan's program and run it next. Stand by.
Maude... she was so obnoxious. Yeah... busy signal... busy signal...
Anyway. I smell toast burning.
All levity aside, full stop.
The objective is to run the asp-bot program, the MAWD won't be plugged in. In place of the MAWD, the user will input numeric data manually by using DEBUGIN. The bell-jar is a hassle.
"We" need to find out why it doesn't get to the Movement routine, to get a handle on that deal. The key elements to monitor are the variables: "Mawdin", zerocounter, and thousandcounter.
So, take the existing program and use the DEBUGIN routine that I posted previously.
' substitute subroutine for "faking" data
MAWD_get:
DEBUG "Enter 5 digits of alt data!", CR
DEBUGIN DEC5 MAWDin
DEBUG CR, DEC5 MAWDin, CR
RETURN
Additionally, you will need to make/place DEBUG statements so that you can see the resulting effect on zerocounter and thousandcounter.
Does everyone get the plan? How does that work for everyone concerned (D, A, MK)?
Are we all on-board?
Your memory map shows that you're getting close to full utilisation.
My memory map showed full utilization several years back. Since then I have beem getting bad sector errors. Since then I have been getting bad setr errs. Snc thn Iv bn gttng bd sctr rrs. Oh, you menat the Stamps's memory map!
OK, I'm going to run Dylan and Andrew's version of the program now, hoping that they understood and added the changes you wanted, PJ. I didn't catch all of your last post but I think they understood.
I have a bell jar and vacuum pump and the fully operational ASP-BOT. Dylan and Andrew have a BOE-BOT without a CO2 sensor or a MAWD. I'll run the programs that you guys upload and then report back. Does that work?
Hold on, the phone's ringing.... It's Maude... she wants to talk to one of you guys.
Your program from page 72 on the forum, "Movement and Sampling V 0.6- April 5, 2011.bse", with PJ's changes, initializes OK and it outputs to the GUI. But it stops data feed after the very first sample column and it never even gets to CO2, temperature, or humidity.
Mark,
This should be The Dylan & Andrew Show, since they're the programmers/Stamp-men. Yes?
Yes, Dyland and Andrew are the programmers. Dylan is the team captain and Andrew has been with the project for years. They are the Stamp Men. You are the Stamp King. I am the...? "Downloader"?
Emily and Jake are the Parachute Release Subsystem design team. Justin is also helping out and trying out for the team.
Obie and I do the physical building and wiring. Chase also helps out. He's also trying out for the team. Others come, try out, and move on.
I am essentially the project coordinator. I organize the team, make sure we have the parts we need (*thank you, Parallax!), arrange travel, get cookies for practice, etc. I try to help with the programming but with so many others responsibilities I really don't understand it as well, nor as thoroughly, as I should.
At first our project was fairly simple and the programming was easier. The project has morphed and become very-- incredible-- over the past three years and programming has become "deep". It has crossed into the realm of experts, which is why I appreciate you teaching and mentoring the Stamp Men.
Meeting and wiring Thursday evening is OUT. I have to get parts ready for early Saturday morning. The Harvard SEDS group wants to do a build session at 9 AM in Boston. I spent half the evening cutting out fins and engine tube mounts so they can build. Sorry. :frown:
Keep up the great communication on the forum everyone! You're finally starting to make progress and move ahead. We may make it to Nevada after all.
Are we in agreement that the "big problem" is: the altimeter and getting to the "Movement" subroutine?
Yes, that is the big problem. Do you agree, Andrew and Dylan? What we're trying to do is:
1) Land the robot by parachute (it already collects atmospheric data all the way to the ground just perfectly.)
2) Detach the parachute immediately after landing (Emily, Jake, Justin -- no programming required.)
3) Program the BOE to read the MAWD after it lands (a series of 0's??) , then move across the ground while it continues to sample for temperature, humidity, CO2, and elapsed time. This is the major malfunction-- the "big problem"-- and it's also their primary mission goal.
Mark,
Their (Andrew's & Dylan's) activity dots are not green, it must be supper time.
Or study time. Or bed time. It's almost 10 PM here. I always worry when my green light goes out. What if it doesn't come back on?
A Subject for this specific goal (altimeter interface) would be best. Do you concur?
I need to interface with The Stamp Men. We/They will keep you in the loop. When would be a good time?
I'm not sure what you mean by a "Subject". A new thread?
I think a good time to interface with Stamp Man #1 and Stamp Man #2 is this time of the evening. But that is a "you guys" decision. The forum is certainly the best place to comuunicate and to figure this out. Someone will need to to let me know when you have an updated program you want me to test out, unless you can do that without a vaccum chamber... and a MAWD, and a CO2 sensor. Ultimately we'll want to confirm proof of concept in the vaccum chamber.
Mark,
Yes, subject = thread.
I think that this can be worked out outside of the bell-jar and all the fuss that involves, your infectiously cheerful demeanor notwithstanding.
Dylan and Andrew,
Please brief Mark as to the relation of MAWDin, zerocounter, and thousandcounter, how they're key to getting the program to the Movement subroutine. Then let me know when we can "get together" for some quality time on the matter ourselves. Weekdays I'm not available till 6:30p east-coast time. Sat and Sun mornings are good for me, I could be up around 8am your time.
I need you guys to be versatile, to communicate, and to be amenable to taking the bull by the horns.
I made a program that simulates and checks the altimeter functions. I just pulled out the relevant code, as is, but used DEBUGIN for manually entering alitmeter data.
Please review it, run it on your Stamp and give me some meaningful feedback.
(Change the Stamp declaration at the top to match the Stamp that you're using.)
** It's probably a good idea to disconnect everything from P0-P15. **
Start with 00000, progress to greater #s, then back down in steps, and then 00000s. Or just hammer it. Check it out.
Hi all- Sorry I wasn't online for the conversation last night. Justin, I agree your idea has promise. But we do need to have more than one idea in case one doesn't work or one works better than another. I'm currently working on a idea so you can understand it. Another meeting this sunday would be very helpful. I think we are back on track for our trip to Nevada.
Good work programming team!
Emily and Justin- I think we are close to reaching our goal. Once we have a working idea, it isn't far from there. I believe we have three ideas ready to be prototyped:
1) Justin's idea. I like it, but i'm still a little confused about the rod. Can you prototype it for us to see?
2) The idea I posted earlier with the one string on a hook.
3) Dylan's dad's idea- A razor blade attached to the wheel that cuts the string when the wheel begins to turn. I like this idea alot but that blade will have to be REALLY sharp to cut Kevlar.
Emily- Do you have any ideas? If so please post them so we can start prototyping them.
I don't have the tools here to prototype it. That's why I suggested meeting at your place before Sunday to try to prototype it. I thought you had a router, but I don't. The rod is just a solid metal rod.
Justin- Thanks for your quick response! My time is limited, class is almost over, but this I can say. We can cut metal if my dad is home, but only small things like holes, and grooves. Meeting up this weekend may be best, because my dad will be home. Hopefully we will be able to build atleast two prototypes. Thanks again.
...That's why I suggested meeting at your place before Sunday to try to prototype it. I thought you had a router, but I don't.
Guys,
If you're going to be using a router and other power tools-- at your house or at mine-- be sure there's an adult there to supervise you (and to glue all your severed fingers back on!) :thumb:
I made a program that simulates and checks the altimeter functions. I just pulled out the relevant code, as is, but used DEBUGIN for manually entering alitmeter data.
Please review it, run it on your Stamp and give me some meaningful feedback.
(Change the Stamp declaration at the top to match the Stamp that you're using.)
** It's probably a good idea to disconnect everything from P0-P15. **
Start with 00000, progress to greater #s, then back down in steps, and then 00000s. Or just hammer it. Check it out.
PJ,
We'll run your program later this afternoon and then report back to you. Re: "hammering it", should we use a carpenter's hammer or a sledge hammer? Or will a simple tack hammer do?
I made a program that simulates and checks the altimeter functions. I just pulled out the relevant code, as is, but used DEBUGIN for manually entering alitmeter data.
Please review it, run it on your Stamp and give me some meaningful feedback.
(Change the Stamp declaration at the top to match the Stamp that you're using.)
** It's probably a good idea to disconnect everything from P0-P15. **
Start with 00000, progress to greater #s, then back down in steps, and then 00000s. Or just hammer it. Check it out.
RESULTS from "mawdsimulation.bs2" - April 6, 2011:
This is what appeared on the computer screen when I typed in random 5-digit numbers and ran the MAWD/BOE on a table top (not in the vacuum chamber). I'm not sure what it tells us about the program.
NOTE: If the MAWD is not in a vacuum chamber it does not initialize. It takes a change in atmospheric pressure to start the MAWD.
enter 5digit altimeter data
12571
12571
12571ft. ' ZC =0 TC = 1
enter 5digit altimeter data
32119
32119
32119ft. ' ZC =0 TC = 2
enter 5digit altimeter data
89221
23685
23685ft. ' ZC =0 TC = 3
enter 5digit altimeter data
98322
32786
32786ft. ' ZC =0 TC = 4
enter 5digit altimeter data
11004
11004
11004ft. ' ZC =0 TC = 5
enter 5digit altimeter data
23561
23561
23561ft. ' ZC =0 TC = 6
enter 5digit altimeter data
Mark,
Since the programmers haven't briefed you on the zerocounter (zc) and thousandcounter (tc) relevance, which are their devise, then I will.
Zerocounter, you've gathered, is the sum of "0" altitude readings, from which "we" infer that the module has landed (8 is the threshold).
Thousandcounter (tc) gets incremented after the rocket reaches an altitude of 1000ft, that way pre-launch "0" altitudes don't get counted toward the threshold total. Zeros don't get counted till thousandcounter is > 5. [This presumes there will be no false-zeros.]
I think that zerocounter should have a MAX, likewise thousandcounter -- so that they won't "roll-over". I don't know how quickly or how many times it goes through the "Main: DO..LOOP", but that (MAX) would obviate any worries there.
I would worry a little bit about the razor as it seems like that would be a little more risky. The strings might be difficult to cut. I think your idea definitely could work. I think during the meeting what held us up the most, was the thought that the wheels would be spinning in the air. Since that doesn't seem to be the issue, I'm much more confident that we will have a solution.
Hopefully, Dylan &/or Andrew will have some questions.
Hopefully. I expect to see them both on the forum a bit later this evening.
OK, "MAWDgetsimulation.bs" accepts intergers up to 65535 before it rolls over to '0' at 65536. I understand the basic theory of why we're running a simulated MAWD program but I don't really grasp the innuendo of the program language-- that subtle ebb and flow-- nor what all the specific program commands do. But I do understand the theory, the "why" behind what we're doing. We're testing to see if the program syntax and the order of the program code work before we put it into the operational program.
With that said...
I compiled a "framework" for the operational version of the program; it's attached it below. It's an amalgam of various program pieces, past and present, and I believe all the subroutines we need are there (or at least a template for the subroutines. I could be wrong and it will certainly need to be reorganized. These "pieces" include:
1) The program code that initializes the BOE and that makes all the sensors work.
2) A movement subroutine, revitalized 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 (last column):
ASP data
00:00:09, 023.4,036.2,00000,00002
00:00:11, 023.4,036.2,00000,00007
00:00:12, 023.4,036.2,00000,00254
00:00:13, 023.5,036.2,00000,00498
00:00:15, 023.5,036.2,00000,00689
00:00:16, 023.5,036.2,00000,00880
00:00:18, 023.5,036.2,00000,01110
00:00:19, 023.5,036.2,00000,01305
2) It does NOT activate the servomotor (which I attached to PIN 14.) when the altitude returns to "0". PIN 12, which the other servo uses, is shared by another function. Ultimately we will have to figure out where else we can can attach it, or how to share a PIN.
3) It does not stop writing data when the altitude reaches "0" as it did before. That could be a good thing since we want the ASP-BOT to move and record data after it lands.
I'm not really sure how to tweak the attached program-- especially the "MAWDget" subroutine-- to make the servos move when altitude returns to "0". That is what I have to report for now and that is your task and your challenge, oh Tall Trees of the Programming Forest.
PJ, Dylan, and Andrew, it's in your hands. I wait for your beck and call (and the call, "Dinner's ready!)
Comments
Just downloaded and ran PJ's "MAWDifthen.bs" program to the ASP-BOT sitting on the table.
Results:
1) No information or data appeared on the GUI (graphic user interface, or computer screen)
2) Nothing was written to the flash drive and the Data Logger didn't initialize.
I'm going to download Dylan's program and run it next. Stand by.
MK
MK
Anyway. I smell toast burning.
All levity aside, full stop.
The objective is to run the asp-bot program, the MAWD won't be plugged in. In place of the MAWD, the user will input numeric data manually by using DEBUGIN. The bell-jar is a hassle.
"We" need to find out why it doesn't get to the Movement routine, to get a handle on that deal. The key elements to monitor are the variables: "Mawdin", zerocounter, and thousandcounter.
So, take the existing program and use the DEBUGIN routine that I posted previously.
' substitute subroutine for "faking" data
MAWD_get:
DEBUG "Enter 5 digits of alt data!", CR
DEBUGIN DEC5 MAWDin
DEBUG CR, DEC5 MAWDin, CR
RETURN
Additionally, you will need to make/place DEBUG statements so that you can see the resulting effect on zerocounter and thousandcounter.
Does everyone get the plan? How does that work for everyone concerned (D, A, MK)?
Are we all on-board?
Sorry, about that, Dylan and his Dad is who I'm talking about that said they had ideas.
As for Thursday, 6:00 was a go for me. Mr. Kibler?
Justin
There's an issue with other traffic on this channel.
My memory map showed full utilization several years back. Since then I have beem getting bad sector errors. Since then I have been getting bad setr errs. Snc thn Iv bn gttng bd sctr rrs. Oh, you menat the Stamps's memory map!
OK, I'm going to run Dylan and Andrew's version of the program now, hoping that they understood and added the changes you wanted, PJ. I didn't catch all of your last post but I think they understood.
I have a bell jar and vacuum pump and the fully operational ASP-BOT. Dylan and Andrew have a BOE-BOT without a CO2 sensor or a MAWD. I'll run the programs that you guys upload and then report back. Does that work?
Hold on, the phone's ringing.... It's Maude... she wants to talk to one of you guys.
MK
:cool:
This should be The Dylan & Andrew Show, since they're the programmers/Stamp-men. Yes?
Results:
Your program from page 72 on the forum, "Movement and Sampling V 0.6- April 5, 2011.bse", with PJ's changes, initializes OK and it outputs to the GUI. But it stops data feed after the very first sample column and it never even gets to CO2, temperature, or humidity.
See the attached "screen shot."
Mr. Kibler
PE -- He needs to know that asp-bot program. His name begins with an A or a D.
I need to have a dialog with him.
Yes, Dyland and Andrew are the programmers. Dylan is the team captain and Andrew has been with the project for years. They are the Stamp Men. You are the Stamp King. I am the...? "Downloader"?
Emily and Jake are the Parachute Release Subsystem design team. Justin is also helping out and trying out for the team.
Obie and I do the physical building and wiring. Chase also helps out. He's also trying out for the team. Others come, try out, and move on.
I am essentially the project coordinator. I organize the team, make sure we have the parts we need (*thank you, Parallax!), arrange travel, get cookies for practice, etc. I try to help with the programming but with so many others responsibilities I really don't understand it as well, nor as thoroughly, as I should.
At first our project was fairly simple and the programming was easier. The project has morphed and become very-- incredible-- over the past three years and programming has become "deep". It has crossed into the realm of experts, which is why I appreciate you teaching and mentoring the Stamp Men.
MK
Are we in agreement that the "big problem" is: the altimeter and getting to the "Movement" subroutine?
Meeting and wiring Thursday evening is OUT. I have to get parts ready for early Saturday morning. The Harvard SEDS group wants to do a build session at 9 AM in Boston. I spent half the evening cutting out fins and engine tube mounts so they can build. Sorry. :frown:
Keep up the great communication on the forum everyone! You're finally starting to make progress and move ahead. We may make it to Nevada after all.
Mr. Kibler
:cool:
Their (Andrew's & Dylan's) activity dots are not green, it must be supper time.
A Subject for this specific goal (altimeter interface) would be best. Do you concur?
I need to interface with The Stamp Men. We/They will keep you in the loop.
When would be a good time?
--
Yes, that is the big problem. Do you agree, Andrew and Dylan? What we're trying to do is:
1) Land the robot by parachute (it already collects atmospheric data all the way to the ground just perfectly.)
2) Detach the parachute immediately after landing (Emily, Jake, Justin -- no programming required.)
3) Program the BOE to read the MAWD after it lands (a series of 0's??) , then move across the ground while it continues to sample for temperature, humidity, CO2, and elapsed time. This is the major malfunction-- the "big problem"-- and it's also their primary mission goal.
MK
Or study time. Or bed time. It's almost 10 PM here. I always worry when my green light goes out. What if it doesn't come back on?
I'm not sure what you mean by a "Subject". A new thread?
I think a good time to interface with Stamp Man #1 and Stamp Man #2 is this time of the evening. But that is a "you guys" decision. The forum is certainly the best place to comuunicate and to figure this out. Someone will need to to let me know when you have an updated program you want me to test out, unless you can do that without a vaccum chamber... and a MAWD, and a CO2 sensor. Ultimately we'll want to confirm proof of concept in the vaccum chamber.
If a tree falls in a vacuum chamber...
MK
Dylan is the Student Project Lead. He is the Big Cheese (Swiss?) He's also our team's software lead-man in the Granite State. He's your go-to guy.
MK
My green light is going off for the evening. Thanks PJ, and thanks Rocketeers. Good night
Yes, subject = thread.
I think that this can be worked out outside of the bell-jar and all the fuss that involves, your infectiously cheerful demeanor notwithstanding.
Dylan and Andrew,
Please brief Mark as to the relation of MAWDin, zerocounter, and thousandcounter, how they're key to getting the program to the Movement subroutine. Then let me know when we can "get together" for some quality time on the matter ourselves. Weekdays I'm not available till 6:30p east-coast time. Sat and Sun mornings are good for me, I could be up around 8am your time.
I need you guys to be versatile, to communicate, and to be amenable to taking the bull by the horns.
I made a program that simulates and checks the altimeter functions. I just pulled out the relevant code, as is, but used DEBUGIN for manually entering alitmeter data.
Please review it, run it on your Stamp and give me some meaningful feedback.
(Change the Stamp declaration at the top to match the Stamp that you're using.)
** It's probably a good idea to disconnect everything from P0-P15. **
Start with 00000, progress to greater #s, then back down in steps, and then 00000s. Or just hammer it. Check it out.
Good work programming team!
Emily and Justin- I think we are close to reaching our goal. Once we have a working idea, it isn't far from there. I believe we have three ideas ready to be prototyped:
1) Justin's idea. I like it, but i'm still a little confused about the rod. Can you prototype it for us to see?
2) The idea I posted earlier with the one string on a hook.
3) Dylan's dad's idea- A razor blade attached to the wheel that cuts the string when the wheel begins to turn. I like this idea alot but that blade will have to be REALLY sharp to cut Kevlar.
Emily- Do you have any ideas? If so please post them so we can start prototyping them.
Thanks all
-JAKE-
I don't have the tools here to prototype it. That's why I suggested meeting at your place before Sunday to try to prototype it. I thought you had a router, but I don't. The rod is just a solid metal rod.
Justin
-JAKE-
P.S What did you think about the other two ideas?
Guys,
If you're going to be using a router and other power tools-- at your house or at mine-- be sure there's an adult there to supervise you (and to glue all your severed fingers back on!) :thumb:
Be safe,
Mr. Kibler
:cool:
PJ,
We'll run your program later this afternoon and then report back to you. Re: "hammering it", should we use a carpenter's hammer or a sledge hammer? Or will a simple tack hammer do?
Out there somewhere,
Mark
RESULTS from "mawdsimulation.bs2" - April 6, 2011:
This is what appeared on the computer screen when I typed in random 5-digit numbers and ran the MAWD/BOE on a table top (not in the vacuum chamber). I'm not sure what it tells us about the program.
NOTE: If the MAWD is not in a vacuum chamber it does not initialize. It takes a change in atmospheric pressure to start the MAWD.
enter 5digit altimeter data
12571
12571
12571ft. ' ZC =0 TC = 1
enter 5digit altimeter data
32119
32119
32119ft. ' ZC =0 TC = 2
enter 5digit altimeter data
89221
23685
23685ft. ' ZC =0 TC = 3
enter 5digit altimeter data
98322
32786
32786ft. ' ZC =0 TC = 4
enter 5digit altimeter data
11004
11004
11004ft. ' ZC =0 TC = 5
enter 5digit altimeter data
23561
23561
23561ft. ' ZC =0 TC = 6
enter 5digit altimeter data
MK
3:30 PM EST
:cool:
Since the programmers haven't briefed you on the zerocounter (zc) and thousandcounter (tc) relevance, which are their devise, then I will.
Zerocounter, you've gathered, is the sum of "0" altitude readings, from which "we" infer that the module has landed (8 is the threshold).
Thousandcounter (tc) gets incremented after the rocket reaches an altitude of 1000ft, that way pre-launch "0" altitudes don't get counted toward the threshold total. Zeros don't get counted till thousandcounter is > 5. [This presumes there will be no false-zeros.]
I think that zerocounter should have a MAX, likewise thousandcounter -- so that they won't "roll-over". I don't know how quickly or how many times it goes through the "Main: DO..LOOP", but that (MAX) would obviate any worries there.
Signify, brothers and sisters.
PE -- Altitudes should be < 60000 feet. Sheesh
A 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
Hopefully, Dylan &/or Andrew will have some questions.
I would worry a little bit about the razor as it seems like that would be a little more risky. The strings might be difficult to cut. I think your idea definitely could work. I think during the meeting what held us up the most, was the thought that the wheels would be spinning in the air. Since that doesn't seem to be the issue, I'm much more confident that we will have a solution.
Justin
Hopefully. I expect to see them both on the forum a bit later this evening.
OK, "MAWDgetsimulation.bs" accepts intergers up to 65535 before it rolls over to '0' at 65536. I understand the basic theory of why we're running a simulated MAWD program but I don't really grasp the innuendo of the program language-- that subtle ebb and flow-- nor what all the specific program commands do. But I do understand the theory, the "why" behind what we're doing. We're testing to see if the program syntax and the order of the program code work before we put it into the operational program.
With that said...
I compiled a "framework" for the operational version of the program; it's attached it below. It's an amalgam of various program pieces, past and present, and I believe all the subroutines we need are there (or at least a template for the subroutines. I could be wrong and it will certainly need to be reorganized. These "pieces" include:
1) The program code that initializes the BOE and that makes all the sensors work.
2) A movement subroutine, revitalized 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 (last column):
ASP data
00:00:09, 023.4,036.2,00000,00002
00:00:11, 023.4,036.2,00000,00007
00:00:12, 023.4,036.2,00000,00254
00:00:13, 023.5,036.2,00000,00498
00:00:15, 023.5,036.2,00000,00689
00:00:16, 023.5,036.2,00000,00880
00:00:18, 023.5,036.2,00000,01110
00:00:19, 023.5,036.2,00000,01305
2) It does NOT activate the servomotor (which I attached to PIN 14.) when the altitude returns to "0". PIN 12, which the other servo uses, is shared by another function. Ultimately we will have to figure out where else we can can attach it, or how to share a PIN.
3) It does not stop writing data when the altitude reaches "0" as it did before. That could be a good thing since we want the ASP-BOT to move and record data after it lands.
I'm not really sure how to tweak the attached program-- especially the "MAWDget" subroutine-- to make the servos move when altitude returns to "0". That is what I have to report for now and that is your task and your challenge, oh Tall Trees of the Programming Forest.
PJ, Dylan, and Andrew, it's in your hands. I wait for your beck and call (and the call, "Dinner's ready!)
MK
:cool: