Remember that we have a presentation to the Bedford Rotary Club on Wednesday morning. We'll leave from my house at 6:30 AM and we should be done around 8:45. Team dress, as always. If you're a candidate for team I would not expect to go.
1) Do we have a presentation "script"? Who'sgoing to say what, and when?
2) Do we have a budget prepared so we can defend the amount we're asking for?
Attached is our program which Dylan and I are troubleshooting. In theory, our new subroutines listed at the bottom of the program should activate the movement subroutine when the MAWD outputs ten consecutive zeroes. We have yet another set of subroutines that act as a fail safe, so that when the beginning zeroes are read at the launch pad the movement subroutine will not activate prematurely. However, when we simulate flight by putting the ASP in a vacuum chamber, the movement subroutine does not activate. Could you please assist us to determine why?
I have tried to go through the logic of your code, just so that I could understand what it is doing. Let me make sure this is correct. The beginning of the code is just initializing everything and making sure everything can log data. The real loop where it all happens is MAIN. Basically it is an ongoing loop that waits until you are over 1000 feet verified by the CheckLiftoff and Liftoff subroutines. Until it has verified being over 1000 feet for 5 times, it won't actually go to your MainMAWDMmovement. This is to make sure you hit the proper altitude before starting to check for being on the ground. Now, in MainMAWDmovement you check to see if you are on the ground by receiving 8 consecutive zeroes. One thing I noticed was that the variable zerocounter was never initialized. The other thing I thought was possible was that feet never equaled a "True zero." I'm not sure exactly how the vacuum chamber works, but let say you launched the rocket on a flat surface, and it was to land on a very slight hill of 2 feet. Would it then register 2, and thus not kick into your Movement subroutine that requires the absolute zero with your statement that only if you have feet equaling zero you increase your zerocounter.
When you actually run your code, is the measurement of feet truly 0 at the end of your data gathering? I was thinking if it equaled "1" or something similar you would never get to your movement command.
But then again, as you know, I'm hardly familiar with your code or even Pbasic, so I very well could just not be understanding some of the code. It was interesting, though, trying to follow it all through.
Mr. Kibler,
I really liked the trip to Harvard. It was interesting to see what they were doing. I was kind of surprised though that they didn't do a scientific pay load, and as one of them said he just wanted to be there to see a rocket go up! I do understand that they have a time constraint, but I mean, really, this is Harvard!
I will be there tomorrow morning and I will be bringing Andrew and Obie to Dunbarton. Jake, we should make a list of things that need to be accomplished on Sunday to keep us on track with our schedule, also I need to talk to either Dylan or Andrew about the program and where it would go and if it would fit, or how we could make a wheel servo activate the mechanism.
Emily
Hi all,
I do not seem to have all off your emails, so I'm just going to ask this on the forum.
Dylan and Andrew- What do you want me to speak to the rotary club about, and can I have the article so I can modify it and understand it before I get there. Thanks.
Release mechanism team- This weekend will be (If you all are okay with it) our testing weekend. We will run a lot of tests, so we can gather a good data table, and then make any simple modifications (like space limitations and so on). We should be ready to make our final design by the end of the day.
Thank you for the dimensions. Thats what I guessed it was. I will have been working on a few different prototypes of the hub cap idea for the meeting on Sunday. Hope they will work!
Attached is the draft version of our presentation to the Bedford Rotary. Please download it and familiarize yourself with it. See you all tomorrow!
Andrew
ROCKETEERS:
Attached below is the FINAL COPY of tomorrow's presentation. I've already made copies for tomorrow but if you see this tonight, please take a look at it. See you at 6:30 AM.
Your presentation to the Bedford Rotary Club (picture below) was very solid and well organized, and you were very professional. The Rotarians had lots of compliments for you afterwards. Good work, and thank you for getting up at 5 AM to make it to the presentation. We should hear back from them sometime next week about whether they can help support our trip to the launch in Nevada in June.
NOTE TO EVERYONE: Please bring your BOE circuit board and all the wires, sensors, etc. to Sunday's practice... 1-4 PM at my house.
Hi all,
I just have one question today:
How much in total do you think the ASP-bot will weigh once all the components are attached?
Emily- Tomorrow will be our testing day. We will test, and modify, and test again. I'm thinking 15 tests before making a modification? What do you think? Do you have other plans for tomorrow? Thanks.
How much in total do you think the ASP-bot will weigh once all the components are attached?
Jake,
Check with Obie on the ASP-BOT's weight. We established a "target weight" two practices ago.
Tomorrow will be our testing day. We will test, and modify, and test again. I'm thinking 15 tests before making a modification? What do you think? Do you have other plans for tomorrow? Thanks. ~Jake~
Before you test the parchute release mechanism tomorrow you should re-examine the ASP-BOT closely to see how everything is mounted. Will the mechanism you have mount on the platform? Remember that "forms follows function." What else do we absolutely have to mount on the platform (MAWD, ADC chip, battery...) Better talk with Obie to see what's going to be mounted where, how much room you have for your mechanism, and how much room you need.
Another question that no one has answered yet: will the parachute release mechanism be operated by a servomotor? Better talk to Dylan and Andrew! The number of "pins" to plug the servo into is very limited. Also, if we/you use a servo, THEY have to write the program (and they're already slipping behind on getting the movement program integrated with the MAWD and the main program.)
The circuit board is now permanently mounted between the two plexiglass layers and the flash drive fits exactly, without even 2 mm to spare. I think you should be prepared to modify the idea you have, or move to plan 'B' or plan 'C'. Space requirements will ultimately make a lot of the decisions for us.
PRACTICE TOMORROW FROM 1-4, ROCKETEERS.
EVERYONE, PLEASE BRING YOUR BOE'S, BOE-BOTS, wires, etc. tomorrow... all the electronics that you have that I gave you.
To answer your question Jake, our current target weight is 720g which is half of the ASP's current weight. I'm sure that can be adjusted a little but I'd prefer we have it as close to 720 as possible. How exactly do you plan on attaching the release mechanism? I know originally you were thinking about mounting it on the wheel, and while that might work I think it would be best to mount it somewhere on the main body.
Great job at the Rotary Club everyone! I'm sure we did a fantastic presentation and impressed them. See ya all Sunday
Obie- Thanks. I'll explain tomorrow with a more in-depth answer, But here is the basic idea:
A heavy duty string with an elastic trait. This will be attached to a servo (the wheels or an extra servo) and to a metal bar located in (by this I mean going through) the wheel. When the servo spins, it release the "string" that has the parachute clipped to it.
Mr. Kibler- That sounds like a good idea! How long do you think it will take tomorrow to get most of the electronics secured to the board?
How long do you think it will take tomorrow to get most of the electronics secured to the board?
Mounting all the electronics will not be done tomorrow but the BOE has already been mounted on the plexiglass. It fits perfectly between the two servos, and side-to-side, and it's sandwiched between the two layers of plexiglass.
However, the MAWD and the shortwave radio transmitter have to be mounted; the ADC circuit board has to be built (soldered) to its own circuit board and then mounted to the BOE; and we have to find a lightweight 3,300 - 4,400 mAHbattery supply for the BOE and then install that, too. Building the ADC chip will take and entire practoce. What else have I forgot?
The challenge for the parachute mechanism team will be:
1) Is there enough room for a servo?
2) How can the design be scaled back (made smaller) to fit a smaller space?
3) **Where will the wire plug into the BOE if we do use a servo? Have you decided this with the programming team?
4) What other ideas do you have for a parachute release mechanism in case the servo idea goes out the window? Don't hang on too tight to the idea you started with because it will most likely change.
Ok today we had a long talk about the future of our project. After putting some thought into it here is what I think of where we stand and what should be done about it.
Where we stand:
Right now we only have a small portion of our overall project done. Currently we have to figure out what to do with the MAWD, or more percisely how to make it trigger the movement proticol after several consecutive zeros. The movement and sampling program itself is jerky right now but that at least is on its way. The parachute release mechanism seems to have returned to drawing board, so that needs to be dealt with very fast if we are to complete the project. The robot itself may at least have the basic platform but we still have a lot of electronics to create, place and safely attach them to the ASP-BOT. So our overall project needs some work so we better get cracken.
What to do:
Where we go from here is another story. The only way I can see us finishing this project is for the team to meet every week until about mid May, or our groups/subsystem teams having many mini-meetings on their own time used in order to get their part done. Like Mr. K said we need to increase forum activity, posting our ideas, suggestions, and problems and colaborating on it as a team could go a long way for us to complete this project. As we all know this is a team effort and without us working as a team there will be no functional project! This is what I suggest and see as of April 3, 2011. Anyone else have an opinion?
I think we definitely need to have more meetings, if we are to get things done on time.
I want one clarification on the wheels during the descent. Dylan and Andrew I believe told me that the wheels could turn while it was falling. I believe Mr. Kibler thought that the wheels would be stationary. Can you you discuss on the forum whether I misunderstood one of you, or which one is accurate. If the wheels stay stationary, I have one idea that could work, but I need you to help me brainstorm it. What I was thinking was a completely mechanical solution to the parachute release mechanism problem. I was thinking about having a partial groove through the wheels. In this groove we will have a bar going across the ASP into both of these grooves. On this bar we would attach a string that would go through the wheel attaching to the parachute. When the wheel begins to turn the bar would hit the plexiglass and slide out of the groove, thereby releasing the parachute. Suggestions anyone?
I want one clarification on the wheels during the descent...I believe Mr. Kibler thought that the wheels would be stationary.
Let me clarify that the servomotors need to be stationary-- not moving-- during the flight and during descent, for a number or reasons. The primary reason is so that the parachute shroud lines (strings) don't get tangled in the wheels.
I have one idea that could work... I was thinking about having a partial groove through the wheels. In this groove we will have a bar going across the ASP into both of these grooves. On this bar we would attach a string that would go through the wheel attaching to the parachute. When the wheel begins to turn the bar would hit the plexiglass and slide out of the groove, thereby releasing the parachute. Suggestions anyone?
Can you make a good diagram of your idea, label the parts, scan it, and then upload it to the forum for everyone to see? "I'm a visual learner." I like the mechanical approach much better than using a servomotor.
The ADC chip is most of the way done, and all the hardware (maybe not the battery) will be mounted on the ASP-BOT when we meet again. We need a parachute release mechanism and a program now...
It seems we figured out a lot of things that we know need to be done. Right now, the project is still far from completion with the parachute release mechanism and program still with much work to be done. It was good to see the various prototypes that the parachute release team designed, but I think they will each need to be considered carefully as we simply do not have the available physical space, as well as I/O slot space on the BOE for a servo motor. In addition, even if we did have space on the BOE for a servo, we must consider the reliability of this method.
Our subsystem team, which is responsible for putting together the final program, must still incorporate a movement routine that is activated by the MAWD. We expected this to be done much sooner, but due to errors that we are unable to fix, the development of our program is set behind. However, I am quite optimistic that once the errors are ironed out, our program will be on it's way completion.
I think some reasonable steps to catch up on the work we have ahead of us are quite obvious. For the teams that can easily and efficaciously work via the forum, you should be posting more often, with regular updates in where you stand and what you need assistance with. This is going to be the only way that the program Dylan and I are working is going to be completed. Working by the forum only but be difficult for the parachute subsystem team, so organizing extra meetings may be a requirement. Either way, I think everyone needs to be more involved on the forum, whether or not they have made progress in their task. If you need help, you must ask for it! Time is running out, and all of our deadlines are approaching faster than you think.
-- Andrew
P.S.-- Although I'm not on the release mechanism subsystem team, I'm interested in your idea, Justin. Do you think you could illustrate or draw out your idea? It sounds simple and straightforward, which is going to be ideal for the final mechanism.
I have many different topics to talk about in this post..
I agree with Obie about where he said we were in accordance to how done we are with the project, and with Andrew about communicating more. But let me clarify about where the programming team really is.
Andrew and I are stuck on only one problem, which is dealing with the MAWD. I am also optimistic like Andrew, because once we get that problem out of the way the programming will be nearly done.
Now with the parachute release mechanism.
It seems like we are back to the drawing board as Obie had said. We CANNOT use another servo in the design. We do not have the space capacity nor the PIN slots needed. My father and I stayed after practice had ended at Mr. Kibler's house and we came up with a few ideas on how to design a release mechanism. Some with a little more thinking seem that they can be possible. Although it is the sub-system team's job to design it, as well as come up with the idea.
Mr. Kibler,
Would it or would it not be possible to be able to test the ASP bot in the gas chamber with the 9 pin cord connecting it to the computer? I remember you stating that you have and can but I wanted to make sure that you were willing to. If it is a no then Andrew and I immediately have to find ways around it. I'm asking this because testing it this way seems like our next logical step. Do you agree Andrew?
What do you think of these ideas. Obie, what are some of the things you and your Dad thought of. We can try prototyping a few different ideas. Jake/Emily when would you be available?
Would it or would it not be possible to be able to test the ASP BOT in the gas [vacuum] chamber with the 9 pin cord connecting it to the computer?
Yes, but you wouldn't be able to see the computer screen until our next practice, two weeks from now.
I can set the vacuum chamber up and run the programs that you and Andrew send me (and others) on the forum. Then I'll report back to you after each expreimental trial as I did with Dr. Allen last year.
Please post PJ's e-mail/suggestions to the forum so everyone can benefit from his ideas and expertise. I'm eager to hear what he suggested to you and to learn from it, too. Others will only be able to learn if you share the information with them, and if you communicate.
Yes, but you wouldn't be able to see the computer screen until our next practice, two weeks from now.
I can set the vacuum chamber up and run the programs that you and Andrew send me (and others) on the forum. Then I'll report back to you after each expreimental trial as I did with Dr. Allen last year.
Please post PJ's e-mail/suggestions to the forum so everyone can benefit from his ideas and expertise. I'm eager to hear what he suggested to you and to learn from it, too. Others will only be able to learn if you share the information with them, and if you communicate.
Nobody answers my PMs.
Perhaps my reputation precedes me.
(Lightning Rod -- On!) OK, here goes...
Given:
feet VAR Word
... and ...
SERIN MAWDin,84,64,Mawdnot,[DEC5 ft]
What form is the data coming from the MAWD?
Is it binary, or BCD, or... what?
(I was looking for details, howbeit superficially, but all I've
seen detailed is this beeping stuff.)
Somebody changed it (the SERIN process) from STR to DEC5.
Yes?
DEC5 isn't 5 bytes, per se, it's 5 'decimal' numbers - characters.
Is the MAWDin data actually a Word (a binary number 0 to 1111_1111 1111_1111)?
It would have to be retrieved as two bytes (HIGHBYTE, LOWBYTE, ??)
If the Mawd data out was "5" "0" "0" for 500 feet then you'd use DECx
If the data is %00000001 11110100, then you need to bag that data as two bytes.
What can you tell me about the MAWD's output data (I haven't found much)?
Nobody answers my PMs.
Perhaps my reputation precedes me.
(Lightning Rod -- On!) OK, here goes...
Hey PJ,
Thanks for posting the forum. I apologize that the team members didn't reply to your PM and I've asked them to keep the dialog on the forum where we can all learn from your expertise. Your reputation does, in fact precede you...!
What form is the data coming from the MAWD?
Is it binary, or BCD, or... what?
(I was looking for details, howbeit superficially, but all I've
seen detailed is this beeping stuff.)
I'll research this a bit but I think Sylvie can help us with this answer because he uses and programs the MAWD to interface with the BOE. Here's what I can tell you as I write: Last year we had to build an Analog-to-Digital (ADC) converter circuit board so the BOE would interpret the signal from the MAWD. With that said, is it fair to assume that the signal is binary?
Somebody changed it (the SERIN process) from STR to DEC5.
Yes?
DEC5 isn't 5 bytes, per se, it's 5 'decimal' numbers - characters.
I'm not sure whether Dylan and Andrew did this or not. Attached is a fully functional (unadulterated) Parlllax version of the program. In this version of the program, which ran just fine last fall and which gave us excellent altitude (etc.) data:
MAWD_get: ' alternative code to acquire MAWD data, uses DEC5 instead of STR in SERIN
PULSIN MAWDin,1,iobyte ' the purpose of this is to synchronize with the MAWD timing.
PAUSE 10 ' this assures the SERIN will start waiting in the silent period before
' a MAWD xmission
feet=0
SERIN MAWDin,84,64,MAWDnot,[DEC5 feet]
MAWDnot:
RETURN
Is the MAWDin data actually a Word (a binary number 0 to 1111_1111 1111_1111)?
It would have to be retrieved as two bytes (HIGHBYTE, LOWBYTE, ??)
I'm not sure what you mean here. The data is read and stored to the Parallax Data Logger as a Notepad document, not a Word document.
If the Mawd data out was "5" "0" "0" for 500 feet then you'd use DECx
This I understand (I think.) If we want the data to output as the number "500" we need to use "DEC.5" (etc.) in the program. Is that accurate?
If the data is %00000001 11110100, then you need to bag that data as two bytes.
You lost me on this; I'm not sure what bagging the data as two bytes means, nor how.
What can you tell me about the MAWD's output data (I haven't found much)?
As above, the data is read and stored to the Parallax Data Logger as a Notepad document, not a Word document. We use an ADC converter to interpret the signal. Here's where our friend Sylvie could be helpful.
Here's a link to the PerfectFlite Mini Altimeter With Dual Deployment (MAWD):
Thanks for posting to the forum PJ, and thanks for sharing your time and expertise. I'm learning this slowly but I am learning. However. we always graduate team members every spring and so we have new team members every year, along with one or two returning team members. So essentially we start anew every time (while I learn slowly. I'm not sure if it's dementia, Alzheimer's, old age, or hunger. I thinkl I'll have a piece of cake.)
Thanks again. We look forward to hearing back from you (and we bow to your expertise.)
"Lightning Rod - On!"
>
"...a universal blow throughout my whole body from head to foot, which seemed within as well as without; after which the first thing I took notice of was a violent quick shaking of my body..." (He also had a feeling of numbness in his arms and the back of his neck that gradually wore off.)
Nobody answers my PMs.
Perhaps my reputation precedes me.
(Lightning Rod -- On!) OK, here goes...
We apologize for not answering your PM. We had received the first PM three weeks ago towards Andrew's account. Although your elaboration on the specific commands of the MAWD_get subroutine have assisted us, we are still uncertain of the bigger picture, so to speak.
What form is the data coming from the MAWD?
Is it binary, or BCD, or... what?
(I was looking for details, howbeit superficially, but all I've
seen detailed is this beeping stuff.)
We are entirely confused on whether or not the data coming from the MAWD is infact binary, (BCD?) or another form. According to Perfectflite, the manufacturer of the MAWD, this is how serial data is outputted. However, we are uncertain on what this exactly means in terms of how it is outputted.
[b]Serial data format:[/b]
8 data, no parity, 1 stop, XON/XOFF
[b]Serial data rate:[/b]
38,400 bps (commands, data)
9.600 bps (telemetry)
Somebody changed it (the SERIN process) from STR to DEC5.
Yes?
DEC5 isn't 5 bytes, per se, it's 5 'decimal' numbers - characters.
The MAWD_get subroutine itself has not been changed since it's creation two years ago by Dr. Allen and Sylvie. Due to this fact, we can not answer any MAWD-specific questions as we had very little to do with writing this portion of the program.
What can you tell me about the MAWD's output data (I haven't found much).
Although we do not understand how the program receives or handles the data received by the MAWD, the altitude is stored as a 6-digit integer in the data textfile on the USB drive. From our understanding, the altitude is stored as an integer in the Word-sized variable called "feet." Therefore, we are using "feet" under the assumption that feet is equal to the altitude. In theory, our updated program should function as expected. However, despite the fact that feet is successfully recorded to the USB drive, it does not seem to behave the same way when used directly within the program.
in re. my e.g. %00000001 11110100 is 500 (decimal) expressed as a binary number (a Word = two bytes = 16 bits.)
MAWDin is the name of the Stamp input pin where the data output from the MAWD (what I'm calling the "MAWD data") goes.
So there's an ADC between the MAWD and the Stamp?
The DEC modifier means that a character, a code, representing a decimal number is expected, as opposed to the number itself. For "0"-"9" then the SERIN is waiting for a code/byte in the range of $30-39 ($30 = "0", $31 = "1", and so on.) As described in PBASIC Help, The DEC formatter "tells SERIN to convert incoming text representing decimal numbers into true-decimal form and store the result in sData."
That'd be some kind of ADC. Ordinarily, an ADC would output a binary number unless there was other circuitry which configured that as ASCII/text characters.
Comments
Remember that we have a presentation to the Bedford Rotary Club on Wednesday morning. We'll leave from my house at 6:30 AM and we should be done around 8:45. Team dress, as always. If you're a candidate for team I would not expect to go.
1) Do we have a presentation "script"? Who'sgoing to say what, and when?
2) Do we have a budget prepared so we can defend the amount we're asking for?
3) How much are we askng for?
4) Who's preparing these...?
Off to Scouts,
Mr. Kibler
Attached is our program which Dylan and I are troubleshooting. In theory, our new subroutines listed at the bottom of the program should activate the movement subroutine when the MAWD outputs ten consecutive zeroes. We have yet another set of subroutines that act as a fail safe, so that when the beginning zeroes are read at the launch pad the movement subroutine will not activate prematurely. However, when we simulate flight by putting the ASP in a vacuum chamber, the movement subroutine does not activate. Could you please assist us to determine why?
Thank you,
Andrew and Dylan
Movement by MAWD - (FeetProblem, CLEAN D.L.) - March 28, 2011.bse
On another note, we would like to know who will definitely be in attendance for the rotary presentation on Wednesday morning.
I will be be able to go to the rotary presentation, unless you preferred that candidates not go. .
Justin,
You are certainly welcome to join us on Wednesday morning (yawn!) at 6:30 AM. What did you think of our trip to Harvard?
Mr. Kibler
:cool:
I have tried to go through the logic of your code, just so that I could understand what it is doing. Let me make sure this is correct. The beginning of the code is just initializing everything and making sure everything can log data. The real loop where it all happens is MAIN. Basically it is an ongoing loop that waits until you are over 1000 feet verified by the CheckLiftoff and Liftoff subroutines. Until it has verified being over 1000 feet for 5 times, it won't actually go to your MainMAWDMmovement. This is to make sure you hit the proper altitude before starting to check for being on the ground. Now, in MainMAWDmovement you check to see if you are on the ground by receiving 8 consecutive zeroes. One thing I noticed was that the variable zerocounter was never initialized. The other thing I thought was possible was that feet never equaled a "True zero." I'm not sure exactly how the vacuum chamber works, but let say you launched the rocket on a flat surface, and it was to land on a very slight hill of 2 feet. Would it then register 2, and thus not kick into your Movement subroutine that requires the absolute zero with your statement that only if you have feet equaling zero you increase your zerocounter.
When you actually run your code, is the measurement of feet truly 0 at the end of your data gathering? I was thinking if it equaled "1" or something similar you would never get to your movement command.
But then again, as you know, I'm hardly familiar with your code or even Pbasic, so I very well could just not be understanding some of the code. It was interesting, though, trying to follow it all through.
Mr. Kibler,
I really liked the trip to Harvard. It was interesting to see what they were doing. I was kind of surprised though that they didn't do a scientific pay load, and as one of them said he just wanted to be there to see a rocket go up! I do understand that they have a time constraint, but I mean, really, this is Harvard!
Justin
Emily
I do not seem to have all off your emails, so I'm just going to ask this on the forum.
Dylan and Andrew- What do you want me to speak to the rotary club about, and can I have the article so I can modify it and understand it before I get there. Thanks.
Release mechanism team- This weekend will be (If you all are okay with it) our testing weekend. We will run a lot of tests, so we can gather a good data table, and then make any simple modifications (like space limitations and so on). We should be ready to make our final design by the end of the day.
Thanks and see you all tomorrow,
-Jake-
Attached is the draft version of our presentation to the Bedford Rotary. Please download it and familiarize yourself with it. See you all tomorrow!
Andrew
ROCKETEERS:
Attached below is the FINAL COPY of tomorrow's presentation. I've already made copies for tomorrow but if you see this tonight, please take a look at it. See you at 6:30 AM.
Mr. Kibler
:cool:
Your presentation to the Bedford Rotary Club (picture below) was very solid and well organized, and you were very professional. The Rotarians had lots of compliments for you afterwards. Good work,
NOTE TO EVERYONE: Please bring your BOE circuit board and all the wires, sensors, etc. to Sunday's practice... 1-4 PM at my house.
Good morning,
Mr. Kibler
:cool:
I just have one question today:
How much in total do you think the ASP-bot will weigh once all the components are attached?
Emily- Tomorrow will be our testing day. We will test, and modify, and test again. I'm thinking 15 tests before making a modification? What do you think? Do you have other plans for tomorrow? Thanks.
-Jake-
Jake,
Check with Obie on the ASP-BOT's weight. We established a "target weight" two practices ago.
Before you test the parchute release mechanism tomorrow you should re-examine the ASP-BOT closely to see how everything is mounted. Will the mechanism you have mount on the platform? Remember that "forms follows function." What else do we absolutely have to mount on the platform (MAWD, ADC chip, battery...) Better talk with Obie to see what's going to be mounted where, how much room you have for your mechanism, and how much room you need.
Another question that no one has answered yet: will the parachute release mechanism be operated by a servomotor? Better talk to Dylan and Andrew! The number of "pins" to plug the servo into is very limited. Also, if we/you use a servo, THEY have to write the program (and they're already slipping behind on getting the movement program integrated with the MAWD and the main program.)
The circuit board is now permanently mounted between the two plexiglass layers and the flash drive fits exactly, without even 2 mm to spare. I think you should be prepared to modify the idea you have, or move to plan 'B' or plan 'C'. Space requirements will ultimately make a lot of the decisions for us.
PRACTICE TOMORROW FROM 1-4, ROCKETEERS.
EVERYONE, PLEASE BRING YOUR BOE'S, BOE-BOTS, wires, etc. tomorrow... all the electronics that you have that I gave you.
Good morning,
Mr. Kibler
:cool:
Great job at the Rotary Club everyone! I'm sure we did a fantastic presentation and impressed them. See ya all Sunday
-Obie Wan
A heavy duty string with an elastic trait. This will be attached to a servo (the wheels or an extra servo) and to a metal bar located in (by this I mean going through) the wheel. When the servo spins, it release the "string" that has the parachute clipped to it.
Mr. Kibler- That sounds like a good idea! How long do you think it will take tomorrow to get most of the electronics secured to the board?
See you all tomorrow!
-Jake-
Mounting all the electronics will not be done tomorrow but the BOE has already been mounted on the plexiglass. It fits perfectly between the two servos, and side-to-side, and it's sandwiched between the two layers of plexiglass.
However, the MAWD and the shortwave radio transmitter have to be mounted; the ADC circuit board has to be built (soldered) to its own circuit board and then mounted to the BOE; and we have to find a lightweight 3,300 - 4,400 mAHbattery supply for the BOE and then install that, too. Building the ADC chip will take and entire practoce. What else have I forgot?
The challenge for the parachute mechanism team will be:
1) Is there enough room for a servo?
2) How can the design be scaled back (made smaller) to fit a smaller space?
3) **Where will the wire plug into the BOE if we do use a servo? Have you decided this with the programming team?
4) What other ideas do you have for a parachute release mechanism in case the servo idea goes out the window? Don't hang on too tight to the idea you started with because it will most likely change.
Mr. Kibler
:cool:
CORRECTION: Our target weight is 750 grams (0.75kg or a little less than one pound.) 1 kg = 2.2 pounds.
Mr. Kibler
I think 750 grams is equal to around 1.65 pounds, or a little more than 1 1/2 pounds.
Justin
Where we stand:
Right now we only have a small portion of our overall project done. Currently we have to figure out what to do with the MAWD, or more percisely how to make it trigger the movement proticol after several consecutive zeros. The movement and sampling program itself is jerky right now but that at least is on its way. The parachute release mechanism seems to have returned to drawing board, so that needs to be dealt with very fast if we are to complete the project. The robot itself may at least have the basic platform but we still have a lot of electronics to create, place and safely attach them to the ASP-BOT. So our overall project needs some work so we better get cracken.
What to do:
Where we go from here is another story. The only way I can see us finishing this project is for the team to meet every week until about mid May, or our groups/subsystem teams having many mini-meetings on their own time used in order to get their part done. Like Mr. K said we need to increase forum activity, posting our ideas, suggestions, and problems and colaborating on it as a team could go a long way for us to complete this project. As we all know this is a team effort and without us working as a team there will be no functional project! This is what I suggest and see as of April 3, 2011. Anyone else have an opinion?
Obie
I want one clarification on the wheels during the descent. Dylan and Andrew I believe told me that the wheels could turn while it was falling. I believe Mr. Kibler thought that the wheels would be stationary. Can you you discuss on the forum whether I misunderstood one of you, or which one is accurate. If the wheels stay stationary, I have one idea that could work, but I need you to help me brainstorm it. What I was thinking was a completely mechanical solution to the parachute release mechanism problem. I was thinking about having a partial groove through the wheels. In this groove we will have a bar going across the ASP into both of these grooves. On this bar we would attach a string that would go through the wheel attaching to the parachute. When the wheel begins to turn the bar would hit the plexiglass and slide out of the groove, thereby releasing the parachute. Suggestions anyone?
Justin
Let me clarify that the servomotors need to be stationary-- not moving-- during the flight and during descent, for a number or reasons. The primary reason is so that the parachute shroud lines (strings) don't get tangled in the wheels.
Can you make a good diagram of your idea, label the parts, scan it, and then upload it to the forum for everyone to see? "I'm a visual learner." I like the mechanical approach much better than using a servomotor.
The ADC chip is most of the way done, and all the hardware (maybe not the battery) will be mounted on the ASP-BOT when we meet again. We need a parachute release mechanism and a program now...
Mr. Kibler
It seems we figured out a lot of things that we know need to be done. Right now, the project is still far from completion with the parachute release mechanism and program still with much work to be done. It was good to see the various prototypes that the parachute release team designed, but I think they will each need to be considered carefully as we simply do not have the available physical space, as well as I/O slot space on the BOE for a servo motor. In addition, even if we did have space on the BOE for a servo, we must consider the reliability of this method.
Our subsystem team, which is responsible for putting together the final program, must still incorporate a movement routine that is activated by the MAWD. We expected this to be done much sooner, but due to errors that we are unable to fix, the development of our program is set behind. However, I am quite optimistic that once the errors are ironed out, our program will be on it's way completion.
I think some reasonable steps to catch up on the work we have ahead of us are quite obvious. For the teams that can easily and efficaciously work via the forum, you should be posting more often, with regular updates in where you stand and what you need assistance with. This is going to be the only way that the program Dylan and I are working is going to be completed. Working by the forum only but be difficult for the parachute subsystem team, so organizing extra meetings may be a requirement. Either way, I think everyone needs to be more involved on the forum, whether or not they have made progress in their task. If you need help, you must ask for it! Time is running out, and all of our deadlines are approaching faster than you think.
-- Andrew
P.S.-- Although I'm not on the release mechanism subsystem team, I'm interested in your idea, Justin. Do you think you could illustrate or draw out your idea? It sounds simple and straightforward, which is going to be ideal for the final mechanism.
I agree with Obie about where he said we were in accordance to how done we are with the project, and with Andrew about communicating more. But let me clarify about where the programming team really is.
Andrew and I are stuck on only one problem, which is dealing with the MAWD. I am also optimistic like Andrew, because once we get that problem out of the way the programming will be nearly done.
Now with the parachute release mechanism.
It seems like we are back to the drawing board as Obie had said. We CANNOT use another servo in the design. We do not have the space capacity nor the PIN slots needed. My father and I stayed after practice had ended at Mr. Kibler's house and we came up with a few ideas on how to design a release mechanism. Some with a little more thinking seem that they can be possible. Although it is the sub-system team's job to design it, as well as come up with the idea.
Mr. Kibler,
Would it or would it not be possible to be able to test the ASP bot in the gas chamber with the 9 pin cord connecting it to the computer? I remember you stating that you have and can but I wanted to make sure that you were willing to. If it is a no then Andrew and I immediately have to find ways around it. I'm asking this because testing it this way seems like our next logical step. Do you agree Andrew?
I drew those sketches you were asking for.
What do you think of these ideas. Obie, what are some of the things you and your Dad thought of. We can try prototyping a few different ideas. Jake/Emily when would you be available?
Justin
Yes, but you wouldn't be able to see the computer screen until our next practice, two weeks from now.
I can set the vacuum chamber up and run the programs that you and Andrew send me (and others) on the forum. Then I'll report back to you after each expreimental trial as I did with Dr. Allen last year.
Please post PJ's e-mail/suggestions to the forum so everyone can benefit from his ideas and expertise. I'm eager to hear what he suggested to you and to learn from it, too. Others will only be able to learn if you share the information with them, and if you communicate.
Aim high (3,050 meters).
Mr. Kibler
:cool:
-- Andrew
Perhaps my reputation precedes me.
(Lightning Rod -- On!) OK, here goes...
Given:
feet VAR Word
... and ...
SERIN MAWDin,84,64,Mawdnot,[DEC5 ft]
What form is the data coming from the MAWD?
Is it binary, or BCD, or... what?
(I was looking for details, howbeit superficially, but all I've
seen detailed is this beeping stuff.)
Somebody changed it (the SERIN process) from STR to DEC5.
Yes?
DEC5 isn't 5 bytes, per se, it's 5 'decimal' numbers - characters.
Is the MAWDin data actually a Word (a binary number 0 to 1111_1111 1111_1111)?
It would have to be retrieved as two bytes (HIGHBYTE, LOWBYTE, ??)
If the Mawd data out was "5" "0" "0" for 500 feet then you'd use DECx
If the data is %00000001 11110100, then you need to bag that data as two bytes.
What can you tell me about the MAWD's output data (I haven't found much)?
Hey PJ,
Thanks for posting the forum. I apologize that the team members didn't reply to your PM and I've asked them to keep the dialog on the forum where we can all learn from your expertise. Your reputation does, in fact precede you...!
I'll research this a bit but I think Sylvie can help us with this answer because he uses and programs the MAWD to interface with the BOE. Here's what I can tell you as I write: Last year we had to build an Analog-to-Digital (ADC) converter circuit board so the BOE would interpret the signal from the MAWD. With that said, is it fair to assume that the signal is binary?
I'm not sure whether Dylan and Andrew did this or not. Attached is a fully functional (unadulterated) Parlllax version of the program. In this version of the program, which ran just fine last fall and which gave us excellent altitude (etc.) data:
MAWD_get: ' alternative code to acquire MAWD data, uses DEC5 instead of STR in SERIN
PULSIN MAWDin,1,iobyte ' the purpose of this is to synchronize with the MAWD timing.
PAUSE 10 ' this assures the SERIN will start waiting in the silent period before
' a MAWD xmission
feet=0
SERIN MAWDin,84,64,MAWDnot,[DEC5 feet]
MAWDnot:
RETURN
I'm not sure what you mean here. The data is read and stored to the Parallax Data Logger as a Notepad document, not a Word document.
This I understand (I think.) If we want the data to output as the number "500" we need to use "DEC.5" (etc.) in the program. Is that accurate?
You lost me on this; I'm not sure what bagging the data as two bytes means, nor how.
As above, the data is read and stored to the Parallax Data Logger as a Notepad document, not a Word document. We use an ADC converter to interpret the signal. Here's where our friend Sylvie could be helpful.
Here's a link to the PerfectFlite Mini Altimeter With Dual Deployment (MAWD):
Data sheet - http://www.perfectflite.com/Downloads/MAWDData.pdf
User manual: http://www.perfectflite.com/Downloads/MAWDManual.pdf
Specifications (from page 22 in the manual):
dimensions: 0.90”W x 3.00”L x 0.75”T
weight: 20 grams (without battery)
operating voltage: 9V nominal (6V - 10V)
default low battery alarm: 8.4V
operating current: 8 ma typical
firing current: 27A peak, 190 mJ energy
continuity check current: 8.9μA/V
*Serial data format: 8 data, no parity, 1 stop, XON/XOFF
*Serial data rate: 38,400 bps (commands, data)
*9,600 bps (telemetry)maximum altitude: 25,000 feet MSL
launch detect: 160 feet AGL
event 1 output: apogee
event 2 output: selectable 300-1700 feet AGL
altitude accuracy: +/- .5% typical
Sylvie, are you there??
Thanks for posting to the forum PJ, and thanks for sharing your time and expertise. I'm learning this slowly but I am learning. However. we always graduate team members every spring and so we have new team members every year, along with one or two returning team members. So essentially we start anew every time (while I learn slowly. I'm not sure if it's dementia, Alzheimer's, old age, or hunger. I thinkl I'll have a piece of cake.)
Thanks again. We look forward to hearing back from you (and we bow to your expertise.)
"Lightning Rod - On!"
>
"...a universal blow throughout my whole body from head to foot, which seemed within as well as without; after which the first thing I took notice of was a violent quick shaking of my body..." (He also had a feeling of numbness in his arms and the back of his neck that gradually wore off.)
- Ben Franklin, our first Lightning Rod, 1746
Mark Kibler
Project Mentor
:cool:
(This is a joint post by both Andrew and I)
We apologize for not answering your PM. We had received the first PM three weeks ago towards Andrew's account. Although your elaboration on the specific commands of the MAWD_get subroutine have assisted us, we are still uncertain of the bigger picture, so to speak.
We are entirely confused on whether or not the data coming from the MAWD is infact binary, (BCD?) or another form. According to Perfectflite, the manufacturer of the MAWD, this is how serial data is outputted. However, we are uncertain on what this exactly means in terms of how it is outputted.
The MAWD_get subroutine itself has not been changed since it's creation two years ago by Dr. Allen and Sylvie. Due to this fact, we can not answer any MAWD-specific questions as we had very little to do with writing this portion of the program.
Although we do not understand how the program receives or handles the data received by the MAWD, the altitude is stored as a 6-digit integer in the data textfile on the USB drive. From our understanding, the altitude is stored as an integer in the Word-sized variable called "feet." Therefore, we are using "feet" under the assumption that feet is equal to the altitude. In theory, our updated program should function as expected. However, despite the fact that feet is successfully recorded to the USB drive, it does not seem to behave the same way when used directly within the program.
---Dylan Landry & Andrew Mahn
OK... hmm,hmm.
in re. my e.g. %00000001 11110100 is 500 (decimal) expressed as a binary number (a Word = two bytes = 16 bits.)
MAWDin is the name of the Stamp input pin where the data output from the MAWD (what I'm calling the "MAWD data") goes.
So there's an ADC between the MAWD and the Stamp?
The DEC modifier means that a character, a code, representing a decimal number is expected, as opposed to the number itself. For "0"-"9" then the SERIN is waiting for a code/byte in the range of $30-39 ($30 = "0", $31 = "1", and so on.) As described in PBASIC Help, The DEC formatter "tells SERIN to convert incoming text representing decimal numbers into true-decimal form and store the result in sData."
That'd be some kind of ADC. Ordinarily, an ADC would output a binary number unless there was other circuitry which configured that as ASCII/text characters.
Intriguing.