Dear Dr. Allen and Sylvie, or to anyone who may be able to assist,
Dylan and I are still in the process of troubleshooting our movement activation subroutine. It is our current goal to have the movement subroutine activated when the Mini-Altimeter with Deployment, or MAWD, outputs 10 consecutive zeroes to the BOE. Last year, you both helped us in writing the subroutine labeled "MAWD_get" which reads the altitude outputted from the MAWD. In the subroutine Dylan and I are trying to fix, the BOE checks for the 10 consecutive zeroes by using a counter. Each time a zero is detected, the counter should be increased by a value of one. If an integer is detected that is not a zero, the counter is reset and the process continues until 10 *consecutive* zeroes are read.
Please take a look at the attached program, and specifically, our new subroutine. Although we are positive there is a more simple and efficent way to write it, both Dylan and I believe that it should work in theory. However, when we tested it at our last practice, we had mixed results. It seemed to start the movement after arbitrary numbers, and possibly the number of samples received from the MAWD, not the number of consecutive zeroes. We're now stuck, as we simply don't understand the MAWD_get subroutine, of which our subroutine is dependent on. Our subroutine works under the assumption that the variable declared as 'feet' is an integer representing the altitude in feet. We believe this for two reasons: there is a comment stating that it holds the alitude where the variable was declared, and because 'feet' is only referenced in one other place, and that's in the MAWD_get subroutine.
We are fairly certain that our subroutine's faults are due to our misunderstanding of how the MAWD_get subroutine works. However, there also may be a "logical" error in our program that is responsible for the program. Whatever the issue is, we're uncertain how to fix it and we really appreciate your kind assistance!
Unfortunately, the program, in theory, is still functioning similarly to how it did during our last practice. Few changes have been made by Dylan and I, due to the fact that any changes we make are simply guesses at this point. We've looked over every resource we have, including earlier pages in this forum thread when the "MAWD_get" subroutine was added, but we still don't fully understand how it works. WIthout an understanding of how the MAWD_get subroutine works, there is little we can do since our subroutine is dependent on it. Dr. Allen and Sylvie, we would greatly appreciate your assistance on this as we understand that you helped write the MAWD_get subroutine some time ago.
Andrew,
I have looked over the program that we were using at the last practice. I have noticed some possible sources of error. I recognized them by adding comments in the area of the possible source of error. The program will likely not work, (since we still need the, "feet" variable to become operational) but the mixed results will hopefully stop. I will show you my findings at some point in the practice today.
--Dylan Landry
I was very impressed by the amount of work accomplished at today's meeting. Jacob and Emily, it was fantastic to see a working prototype for the parachute release mechanism. It seems very promising! I was also impressed by the new form the ASP-Bot is taking. The wheels look excellent, and to see them fit perfectly in the payload bay was exciting! I can't wait to see what it ends up looking like when the design team is finished with it.
It was also fantastic to meet two people interested in joining the team, Chase and Justin. It seems that you have already found your way to the forum, Justin. Chase, I'll be e-mailing you a link to the forum and instructions on how to register. Be sure to check this forum thread regularly, as nearly all team discussion outside of practice occurs here.
Dr. Allen and Sylvie,
Dylan and I continued to work on the MAWD-activated movement subroutine today. Please refer to post #1292 of this thread for a recent update on our situation, if you haven't already read it. We fixed a programming bug earlier today at practice, which was calling "sub-subroutines" in the wrong order. We then ground-tested the program by setting the "zero counter" requirement to an arbitrary number of 8. Surely enough, the movement subroutine was (seemingly) activated after 8 zeroes were received from the MAWD. Dylan then added a clause in the program which will not allow our zero-checking subroutine to begin until after the altitude moves to something above zero, and then back to zero. This is because the MAWD will read out zeroes before we launch, which we don't want the program to count. In theory, the program should start the motor when 10 zeroes are read after landing. However, several tests in a vacuum chamber proved otherwise, with no success. Nonetheless, data was still successfully recorded to the USB drive.
Dylan will be posting the most recent version of the program this evening. We would very much appreciate it if you could take a look at our "MainMawdMovement" subroutine within the program and offer suggestions as to why our program is behaving the way it is.
Today's practice was very helpful. I was glad that Jake and I almost finished our prototype I was very impressed with Justin's program, I remember it took me a few tries to finally understand how it worked. Having all the pieces of the new ASP helped me think. I think our next step is to talk to the Programing sub system team about incorporating our program and making it work.
My views on the problem are the same as Andrew.
We tested my additions to the program in such ways that we believe that the program written is correct. We simulated the altitude by changing the VAR "feet" to 0, (ground) or at times above 1000 (in the air). This gave us the ability to simulate altitude. By simulating altitude, we were able to test different portions of the program.
Example:
When we made the variable, lets say 3000, the program initiated what should happen once the ASP would be in the air after take off.
When we made the variable 0, the ASP also behaved as should.
**NOTE** When we were programming, we were not testing it on the ASP. We were using a seperate board that DID NOT have a MAWD equipped. So when ever we set, "feet" as a decimal value, it WAS the declared value... No changing what so ever.
**Once We Tested it With Real ASP in Gas Chamber**
When we put the actuall ASP inside the gas chamber to simulate altitude change, the ASP did not behave as programmed, or I should say, as we believed it should of. The ASP did withstand an altitude above 1000 feet for the time needed for the program to register that it is in flight. The same happened for when it needed to count eight 0's post flight on the ground to recognize that it has indeed landed and should start the motors. The movement of the motors never started, thus the subroutine, "movement" was never initiated.
**I have made changes to the program whilst writing this... My changes will be marked...
**WARNING**
This program is my, "clean" version. By clean, I mean that I took out lines of program code that is not used at all by the ASP. Such as a, "Movement2" subroutine that we used for testing perpuses. Same goes for a subroutine, "Purge" that reset a counter to 0 that was not needed. Since it is a clean version, there may be some differences from other programs in that section. I BY NO MEANS took out anything that was not used by only me and Andrew while developing this code. In simple terms, the code deleted was not vital in anyway to anyother part of the ASP. If by chance there was something deleted that shouldn't of been, I do indeed have a backup.
**NOTE2**
I apolagize for all these notes. I caught errors whilst I was cleaning the program.
There were some errors, as in a PAUSE 3000 in a PULSOUT command instead of a PAUSE 20, as well as missing RETURNS... I added/removed these, so the program may behave differently as before. Mr. Kibler, could you test this program in the gas chamber one more time and post the results? I don't believe this would of fixed the problem though. My reasoning behind that is because the errors were in a certain subroutine called, "movement". This subroutine held how the ASP would move once 8 0's had been read after take off. If the subroutine had even been activated once, we would of seen it DEBUG "Movement has Started.". Since it didn't we know that subroutine with errors was never even reached in the first place.
I apoligize for the long post and how it can, (most likely HAS) confused you. Please ask any questions you have.
I have downloaded my, "Clean" file below...
I was thinking about the parachute problem and how as our release mechanism is it relies on the parachute being full of air. I was thinking that after the servo relases the parachute and the ASP-BOT moved then wouldn't the parachute come out because its no longer attached. In theory if there was no wind wouldn't the parachute stay in one place and the ASP-BOT move away from it?
Just a thought. Let me know what you think.
Emily
Thank you everyone who allowed me to sit in on your meeting yesterday and I just want to say that the order and teamwork displayed was fantastic. I have been on a few robotics teams in the past and either not everyone cooperates or they do not work well with each other.
In response to the idea Emily brought up in the last post I do think that point is valid, however it does seem that there could be a chance that the parachute would be caught on the wheels once the ASP-BOT starts to move. Yes it may fall away from the robot but there is still the chance of it getting caught up on the wheels or dragging the entire time which offset the ASP-BOT.
I think Dylan and Andrew have written the essence of the subroutine they need to make the ASP-BOT rover move after it lands (see Andrew's program at the bottom of the last forum page.) However, we're stumped by the complexity of the main program and we're unsure exactly where and how to intergrate the subroutine into the main program. They also have a question about the "feet" variable that I'm unable to answer. We want to make the rover continue to record data and then move after it lands. Movement would be intitiated by the MAWD (altimeter) after it reads a string of consecutive 0's (10 or 20 zeroes as Paul suggested.)
Can you please help us rearrange and/or re-write the program so the rover will continue to record data and also move after it lands? We would certainly appreciate your help.
We have a really BIG team evolving this spring, our largest ever! We're aiming for a mid-June launch in Black Rock. Check out all the new names here on the forum and then add a few more. That's how many kids have also asked to join the team. This year's group is running and working like clockwork; you'd never guess that most are "newbies."
Paul, I'm not sure if you saw when I posted a few pages back, but Harvard has asked us to mentor their SEDS rocketry group. Their mission is a lot like ARLISS (4 kg maximum payload, 2 mile target altitude, etc.) We're going down next Saturday to walk them through basic rocket parts and design (using RockSim) and subsystem integration. It's cool when you think about the fact that a group of 8th and 9th graders will in essence be teaching Harvard students. What great learning all the way around! Want to come along?
I was just thinking about the parachute release mechanism problem. What if we began to start running the wheels before the ASP-BOT hit the ground. They could start when the altimeter read 20 feet or whatever made sense. If there was no wind then the bot would simply move away from it after it landed. Also if there was wind it would always just move away from the parachute. I think there could be a danger of the bot spinning, so would there be a way to change the mechanism that attaches the parachute to the bot that would not spin the actual parachute strings.
Justin- I like your idea. Unfortanitly, you can't drop exposed electronics twenty feet in the air in the middle of the desert without smashing it. Unless we had a shield (which we don't have room for) it would be smashed, and the wheels would come right off.
Emily- I agree, it would just drive away. If we dont use something with an elastic property though, it has a much higher chance of getting stuck. I'm working on making a few small modifications (adding a wheel and making sure everything is securley attached) and then I (or maybe we can hook up again?) will run test with a parachute to see what will happen.
Mr. Kibler- Can you please bring the large parachute to school tomorrow so I can bring it home and attach it to the prototype? thanks.
NO, I wasn't talking about releasing the parachute at the altitude, just spinning the wheels so that when it landed, it would immediately drive away from where the parachute was. We would release the parachute when we were on the ground... Either using the altitude test that is already in the program, or using an alternate sensor... I would never think of dropping electronics from that height!!!
NO, I wasn't talking about releasing the parachute at the altitude, just spinning the wheels so that when it landed, it would immediately drive away from where the parachute was. We would release the parachute when we were on the ground... Either using the altitude test that is already in the program, or using an alternate sensor... I would never think of dropping electronics from that height!!!
Justin,
I see a few problems wrong with your idea. I believe the first and most evident is the fact that due to the force and speed of it's landing, the odds of the robot moving actually making a difference is going to be minimal. I don't believe "hitting the ground running" (so to speak) is going to be the best solution to the problem. Even a slight wind will drag the large parachute quite a distance, especially with the relatively light weight of the payload. These are just my thoughts though, and there are many possibilities and combination of solutions, such as yours, to overcome this challenge.
It's good to see everyone engaged in dialog here on the forum. I'm hoping that we'll hear from Dr. Allen or Sylvie soon about the program. Keep working at it while we wait to hear from them.
Good news and bad news:
GOOD NEWS - The ASP-BOT driving base is done! SEE PICTURES BELOW. The wheels and servos are mounted on a bare plexiglass platform, waiting for circuitry.
BAD NEWS - The new plaform is really tight on space, a mere 14 x 14 cm. The BOE circuit board fits exactly between the two servomotors with the Data Logger sticking out the side. However, no matter which way I try to mount the BOE on the platform the Data Logger sticks out. Dylan, can you bring your tiny flash drive to next practice? We'll need one that's really, really small so we can save space.
The wheels also seem a bit fragile, attached to the servo by a single screw. I don't think we want to mount the parachute directly to the wheel (unless we want to risk losing a wheel and watching the ASP-BOT fall from 11,000 feet...!)
Keep up the good work; keep working on the program,
I think I need to understand the problem a little better. Based on Emily's post above it seemed that if there was wind in the parachute there was no problem. I thought the issue was if there was no wind, and that is what I thought "hitting the ground running" might help. From Andrew's post above it seemed that having wind would blow the parachute, being a problem. If that is the case, how could we not be sure that the parachute would blow on top of the bot, regardless. Please clarify.
If the wind is blowing when the ASP-BOT lands it will keep the parachute inflated and it will pull the string out through the wheels when the servomotor releases the parachute string. Then the ASP-BOT with start moving, minus the parachute.
If there's no wind and the parachute goes limp afterlanding, there may not be any pressure to "pull" the string through wheels. So the string could get tangled in the wheels when the robot starts to move.
Emily believes that the weight of the parachute will be sufficient to pull the string out when the robot starts moving. The parachute does have weight. We'll want to test all three scenarios before we launch..
An idea for landing the ASP-BOT: I do not know if this would exceed any constraints for the bot, but is it possible to put a rounded hub cap on the wheel opposite where the parachute would be so that it would roll onto its side? Or we could put the parachute offset on the side of the bot so it will come down at an angle and guarantee it would fall on its side.Just an idea I thought of today though not necessary because of all of the factors that would most likely make the bot fall onto its side.
I want to add that if you need me to re-wire the circuit board I could do it fairly quickly if need be. I know how to create analog and digital circuits using and, nor, or, nand, + inverter gates, etc., and try to do so so we could make our spacing more efficient on the ASP-BOT because I am now wrapping up a class I took at school on that subject. Just offering.
An idea for landing the ASP-BOT: ... is it possible to put a rounded hub cap on the wheel opposite where the parachute would be so that it would roll onto its side?
Chase
Clever idea Chase, using a rounded hub cup to make sure the ASP-BOT lands upright. We had discussed offsetting the parachute's shroud lines ("strings") but that idea got complicated when we had to consider how to release the parachute at touchdown. I like the hub cap idea a lot: it's simple and functional. Should we use a Ford, Chevy, or BMW hub cap?
I want to add that if you need me to re-wire the circuit board I could do it fairly quickly if need be. I know how to create analog and digital circuits using and, nor, or, nand, + inverter gates, etc.
Now that you mention it... One of the next things we have to do is reconstruct the (blue and yellow) ASP-2's circuitry on the new (yellow-wheeled) ASP-BOT. We also have to solder up a new ADC (analog-to-digtital) converter, etc. So your skills will come in handy. How are you with programming? Andrew and Dylan could use some help figuring out the program sequence. Fair warning: it's deep stuff and you have to understand all of it in order to do some of it.
I was just thinking about the hubcap option. In ARLISS is there a weight limit? If so, what is it, and how close are we to it? The idea sounds like a good one, though.
ARLISS has no weight limit but we're trying to keep the weight at 750 grams or less. The lighter the weight the less batteries the ASP-BOT will use, and the farther it should travel. Just like on the surface of Mars, power consumption is a concern.
I think Dylan and Andrew have written the essence of the subroutine they need to make the ASP-BOT rover move after it lands (see Andrew's program at the bottom of the last forum page.) However, we're stumped by the complexity of the main program and we're unsure exactly where and how to intergrate the subroutine into the main program. They also have a question about the "feet" variable that I'm unable to answer. We want to make the rover continue to record data and then move after it lands. Movement would be intitiated by the MAWD (altimeter) after it reads a string of consecutive 0's (10 or 20 zeroes as Paul suggested.)
Can you please help us rearrange and/or re-write the program so the rover will continue to record data and also move after it lands? We would certainly appreciate your help.
I've been a little hesitant to comment on the program itself, as that has been Tracy's area. It looks to me as though you've been doing the right kind of problem solving (i.e., putting DEBUG statements into the appropriate subroutines to see if they work). Here are my suggestions:
1 - Make certain that the code in your movement subroutine actually does what you want it to do. You have
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
Try uploading _just_ that code to the BOE, and make sure that it spins the wheels when you run it.
2 - Make sure that the MAWD data make sense. Write a program that just runs your MAWD_get routine and displays the value of the feet variable on the screen.
3 - You have this:
'----- [ Main (MAWD Movement) ] -----
MainMAWDmovement:
IF feet = 0 THEN GOSUB CheckConsecutive
DEBUG "Cycle...", CR
RETURN
'----- [ Subroutines ] -----
CheckConsecutive:
zerocounter = zerocounter + 1
IF zerocounter = 8 THEN GOSUB movement
RETURN
I think that those could be combined into one routine, rather than having the consecutive 0s check moved into its own subroutine. Regardless, set up a test program so that rather than starting the movement subroutine, when the zerocounter reaches 8, have it display "Landed" to the screen, to check to see that's working.
I take it that the "thousand counter" stuff and the MainMAWDMovement stuff is to get it started checking for landing only after you're sure you've been up over 1000 feet. That's good. Now, in the stuff where you check for landing, you're reading the MAWD once, putting that value into the feet variable, and then if it's 0, checking to see if it stays 0 over 8 counts of the zerocounter. But you're never going back to read the next value from the MAWD while you're in that loop. "feet" is of course going to stay at 0 over that time, because there's nothing there to change it. The first time that you get a 0 from the MAWD, it's going to go to Check_Consecutive, where the zerocounter will count to 8, and then start the movement subroutine. There's nothing in there to make sure that the altitude has stayed at 0 for that time - you never went back and read another value from the MAWD.
You need something that looks like this:
Read the altitude from the MAWD
If altitude does equal 0, note that fact, and add one to your counter
If the counter = 8, then set your landing flag (you have landed)
If altitude does not equal 0, set your counter back to 0 (the previous 0 was just a glitch)
If the landing flag is not set, go back to the start
If the landing flag IS set, you've landed, and you can get out of this loop and run the movement routine
Does that help? Notice that if you haven't landed, you go back to the start and read the altitude again. You're missing that step.
Paul, I'm not sure if you saw when I posted a few pages back, but Harvard has asked us to mentor their SEDS rocketry group. Their mission is a lot like ARLISS (4 kg maximum payload, 2 mile target altitude, etc.) We're going down next Saturday to walk them through basic rocket parts and design (using RockSim) and subsystem integration. It's cool when you think about the fact that a group of 8th and 9th graders will in essence be teaching Harvard students. What great learning all the way around! Want to come along?
I'd be interesting in helping out with this, yes. I have to see what it involves, but feel free to put me in the loop on it.
Well it was nice meeting you Chase and Justin. So the board is smaller than the ASP's original. Dylan and Andrew, what do we need on the boe-bot besides the BoE, batteries, MAwD, and gps tracker. Also I have another question, while I was examining the board I noticed that a lot of the I/O pins were being used so I was wondering which pins do we have to work with right now that would allow us to use servo motors?
Chase, I love the hubcab idea. It's very elegant and should work. I think we should look deeper into the idea and try to maximize the space and efficiency. What I mean by that is look at how sperical it is.
What should we make it out of though, metal would be too heavy.
Hi all-
I got a chance to look at the ASP-Bot with it's smaller size today. It is much smaller than i anticipated.
Emily and Justin- We need to plan on having to use the wheel's servo to release the mechanism, unless space provides room for another servo. Although I do really like Justin's idea of using the wheel's servo, you then contradicted yourself with the starting the wheels spinning twenty feet from the ground. That would release the parachute if i'm not mistaken?
Chase- I really like the idea of using a "hub cap" but after i saw how much room we have left, I don't know that we can! what if we rounded the edge of the wheel instead? That in the end gives us MORE room with a HIGHER chance of a succesful landing. Post what you think about this?
Good work all!
-Jake-
P.S Justin and Emily and dylan and anyone else who wants to praticapate- It would be outstanding if we could meet up this weekend and work on using the wheels servo. Sunday would work best for me, later in the day. We can meet at my house or anyone elses who is willing to host the team. Thanks
Jake, I will check my calender but I think I can make it. I would also offer to host the team at my house but I live the farthest away and that would be wasting gas.
Emily
Remember as you plan your weekend that the Harvard University SEDS rocketry group meeting is this SATURDAY. We'll leave the Concord area around 12:30 and return around 6:30 or 7:00 PM, with dinner on the way home at a restaurant.
This is who has confirmed to go to Harvard on Saturday so far:
Obie
Justin
Please confirm if you are going to Harvard here on the forum. I know more of you said you were going. I just forgot who.
Comments
Dylan and I are still in the process of troubleshooting our movement activation subroutine. It is our current goal to have the movement subroutine activated when the Mini-Altimeter with Deployment, or MAWD, outputs 10 consecutive zeroes to the BOE. Last year, you both helped us in writing the subroutine labeled "MAWD_get" which reads the altitude outputted from the MAWD. In the subroutine Dylan and I are trying to fix, the BOE checks for the 10 consecutive zeroes by using a counter. Each time a zero is detected, the counter should be increased by a value of one. If an integer is detected that is not a zero, the counter is reset and the process continues until 10 *consecutive* zeroes are read.
Please take a look at the attached program, and specifically, our new subroutine. Although we are positive there is a more simple and efficent way to write it, both Dylan and I believe that it should work in theory. However, when we tested it at our last practice, we had mixed results. It seemed to start the movement after arbitrary numbers, and possibly the number of samples received from the MAWD, not the number of consecutive zeroes. We're now stuck, as we simply don't understand the MAWD_get subroutine, of which our subroutine is dependent on. Our subroutine works under the assumption that the variable declared as 'feet' is an integer representing the altitude in feet. We believe this for two reasons: there is a comment stating that it holds the alitude where the variable was declared, and because 'feet' is only referenced in one other place, and that's in the MAWD_get subroutine.
We are fairly certain that our subroutine's faults are due to our misunderstanding of how the MAWD_get subroutine works. However, there also may be a "logical" error in our program that is responsible for the program. Whatever the issue is, we're uncertain how to fix it and we really appreciate your kind assistance!
Thank you,
~ Andrew (from Obie's house)
Andrew,
No program file is attached.
Mr. Kibler
:nerd:
Mr. Kibler,
I've re-uploaded the file into my previous post.
Thanks,
Andrew
Great; thanks. Got it now. How do yout hink it will work tomorrow...?
Mr. Kibler
Unfortunately, the program, in theory, is still functioning similarly to how it did during our last practice. Few changes have been made by Dylan and I, due to the fact that any changes we make are simply guesses at this point. We've looked over every resource we have, including earlier pages in this forum thread when the "MAWD_get" subroutine was added, but we still don't fully understand how it works. WIthout an understanding of how the MAWD_get subroutine works, there is little we can do since our subroutine is dependent on it. Dr. Allen and Sylvie, we would greatly appreciate your assistance on this as we understand that you helped write the MAWD_get subroutine some time ago.
Thank you,
~ Andrew (from Obie's)
I have looked over the program that we were using at the last practice. I have noticed some possible sources of error. I recognized them by adding comments in the area of the possible source of error. The program will likely not work, (since we still need the, "feet" variable to become operational) but the mixed results will hopefully stop. I will show you my findings at some point in the practice today.
--Dylan Landry
I was very impressed by the amount of work accomplished at today's meeting. Jacob and Emily, it was fantastic to see a working prototype for the parachute release mechanism. It seems very promising! I was also impressed by the new form the ASP-Bot is taking. The wheels look excellent, and to see them fit perfectly in the payload bay was exciting! I can't wait to see what it ends up looking like when the design team is finished with it.
It was also fantastic to meet two people interested in joining the team, Chase and Justin. It seems that you have already found your way to the forum, Justin. Chase, I'll be e-mailing you a link to the forum and instructions on how to register. Be sure to check this forum thread regularly, as nearly all team discussion outside of practice occurs here.
Dr. Allen and Sylvie,
Dylan and I continued to work on the MAWD-activated movement subroutine today. Please refer to post #1292 of this thread for a recent update on our situation, if you haven't already read it. We fixed a programming bug earlier today at practice, which was calling "sub-subroutines" in the wrong order. We then ground-tested the program by setting the "zero counter" requirement to an arbitrary number of 8. Surely enough, the movement subroutine was (seemingly) activated after 8 zeroes were received from the MAWD. Dylan then added a clause in the program which will not allow our zero-checking subroutine to begin until after the altitude moves to something above zero, and then back to zero. This is because the MAWD will read out zeroes before we launch, which we don't want the program to count. In theory, the program should start the motor when 10 zeroes are read after landing. However, several tests in a vacuum chamber proved otherwise, with no success. Nonetheless, data was still successfully recorded to the USB drive.
Dylan will be posting the most recent version of the program this evening. We would very much appreciate it if you could take a look at our "MainMawdMovement" subroutine within the program and offer suggestions as to why our program is behaving the way it is.
Thank you,
~ Andrew
Emily
We tested my additions to the program in such ways that we believe that the program written is correct. We simulated the altitude by changing the VAR "feet" to 0, (ground) or at times above 1000 (in the air). This gave us the ability to simulate altitude. By simulating altitude, we were able to test different portions of the program.
Example:
When we made the variable, lets say 3000, the program initiated what should happen once the ASP would be in the air after take off.
When we made the variable 0, the ASP also behaved as should.
**NOTE** When we were programming, we were not testing it on the ASP. We were using a seperate board that DID NOT have a MAWD equipped. So when ever we set, "feet" as a decimal value, it WAS the declared value... No changing what so ever.
**Once We Tested it With Real ASP in Gas Chamber**
When we put the actuall ASP inside the gas chamber to simulate altitude change, the ASP did not behave as programmed, or I should say, as we believed it should of. The ASP did withstand an altitude above 1000 feet for the time needed for the program to register that it is in flight. The same happened for when it needed to count eight 0's post flight on the ground to recognize that it has indeed landed and should start the motors. The movement of the motors never started, thus the subroutine, "movement" was never initiated.
**I have made changes to the program whilst writing this... My changes will be marked...
**WARNING**
This program is my, "clean" version. By clean, I mean that I took out lines of program code that is not used at all by the ASP. Such as a, "Movement2" subroutine that we used for testing perpuses. Same goes for a subroutine, "Purge" that reset a counter to 0 that was not needed. Since it is a clean version, there may be some differences from other programs in that section. I BY NO MEANS took out anything that was not used by only me and Andrew while developing this code. In simple terms, the code deleted was not vital in anyway to anyother part of the ASP. If by chance there was something deleted that shouldn't of been, I do indeed have a backup.
**NOTE2**
I apolagize for all these notes. I caught errors whilst I was cleaning the program.
There were some errors, as in a PAUSE 3000 in a PULSOUT command instead of a PAUSE 20, as well as missing RETURNS... I added/removed these, so the program may behave differently as before. Mr. Kibler, could you test this program in the gas chamber one more time and post the results? I don't believe this would of fixed the problem though. My reasoning behind that is because the errors were in a certain subroutine called, "movement". This subroutine held how the ASP would move once 8 0's had been read after take off. If the subroutine had even been activated once, we would of seen it DEBUG "Movement has Started.". Since it didn't we know that subroutine with errors was never even reached in the first place.
I apoligize for the long post and how it can, (most likely HAS) confused you. Please ask any questions you have.
I have downloaded my, "Clean" file below...
Movement by MAWD - (FeetProblem, CLEAN D.L.) - March 19, 2011.bse
Just a thought. Let me know what you think.
Emily
In response to the idea Emily brought up in the last post I do think that point is valid, however it does seem that there could be a chance that the parachute would be caught on the wheels once the ASP-BOT starts to move. Yes it may fall away from the robot but there is still the chance of it getting caught up on the wheels or dragging the entire time which offset the ASP-BOT.
Chase
I think Dylan and Andrew have written the essence of the subroutine they need to make the ASP-BOT rover move after it lands (see Andrew's program at the bottom of the last forum page.) However, we're stumped by the complexity of the main program and we're unsure exactly where and how to intergrate the subroutine into the main program. They also have a question about the "feet" variable that I'm unable to answer. We want to make the rover continue to record data and then move after it lands. Movement would be intitiated by the MAWD (altimeter) after it reads a string of consecutive 0's (10 or 20 zeroes as Paul suggested.)
Can you please help us rearrange and/or re-write the program so the rover will continue to record data and also move after it lands? We would certainly appreciate your help.
We have a really BIG team evolving this spring, our largest ever! We're aiming for a mid-June launch in Black Rock. Check out all the new names here on the forum and then add a few more. That's how many kids have also asked to join the team. This year's group is running and working like clockwork; you'd never guess that most are "newbies."
Paul, I'm not sure if you saw when I posted a few pages back, but Harvard has asked us to mentor their SEDS rocketry group. Their mission is a lot like ARLISS (4 kg maximum payload, 2 mile target altitude, etc.) We're going down next Saturday to walk them through basic rocket parts and design (using RockSim) and subsystem integration. It's cool when you think about the fact that a group of 8th and 9th graders will in essence be teaching Harvard students. What great learning all the way around! Want to come along?
Thank you,
Mark
:nerd:
I was just thinking about the parachute release mechanism problem. What if we began to start running the wheels before the ASP-BOT hit the ground. They could start when the altimeter read 20 feet or whatever made sense. If there was no wind then the bot would simply move away from it after it landed. Also if there was wind it would always just move away from the parachute. I think there could be a danger of the bot spinning, so would there be a way to change the mechanism that attaches the parachute to the bot that would not spin the actual parachute strings.
Justin
Mr. Kibler- Can you please bring the large parachute to school tomorrow so I can bring it home and attach it to the prototype? thanks.
Justin,
I see a few problems wrong with your idea. I believe the first and most evident is the fact that due to the force and speed of it's landing, the odds of the robot moving actually making a difference is going to be minimal. I don't believe "hitting the ground running" (so to speak) is going to be the best solution to the problem. Even a slight wind will drag the large parachute quite a distance, especially with the relatively light weight of the payload. These are just my thoughts though, and there are many possibilities and combination of solutions, such as yours, to overcome this challenge.
Andrew
It's good to see everyone engaged in dialog here on the forum. I'm hoping that we'll hear from Dr. Allen or Sylvie soon about the program. Keep working at it while we wait to hear from them.
Good news and bad news:
GOOD NEWS - The ASP-BOT driving base is done! SEE PICTURES BELOW. The wheels and servos are mounted on a bare plexiglass platform, waiting for circuitry.
BAD NEWS - The new plaform is really tight on space, a mere 14 x 14 cm. The BOE circuit board fits exactly between the two servomotors with the Data Logger sticking out the side. However, no matter which way I try to mount the BOE on the platform the Data Logger sticks out. Dylan, can you bring your tiny flash drive to next practice? We'll need one that's really, really small so we can save space.
The wheels also seem a bit fragile, attached to the servo by a single screw. I don't think we want to mount the parachute directly to the wheel (unless we want to risk losing a wheel and watching the ASP-BOT fall from 11,000 feet...!)
Keep up the good work; keep working on the program,
Mr. Kibler
:cool:
I think I need to understand the problem a little better. Based on Emily's post above it seemed that if there was wind in the parachute there was no problem. I thought the issue was if there was no wind, and that is what I thought "hitting the ground running" might help. From Andrew's post above it seemed that having wind would blow the parachute, being a problem. If that is the case, how could we not be sure that the parachute would blow on top of the bot, regardless. Please clarify.
Justin
If the wind is blowing when the ASP-BOT lands it will keep the parachute inflated and it will pull the string out through the wheels when the servomotor releases the parachute string. Then the ASP-BOT with start moving, minus the parachute.
If there's no wind and the parachute goes limp afterlanding, there may not be any pressure to "pull" the string through wheels. So the string could get tangled in the wheels when the robot starts to move.
Emily believes that the weight of the parachute will be sufficient to pull the string out when the robot starts moving. The parachute does have weight. We'll want to test all three scenarios before we launch..
Mr. Kibler
:cool:
I want to add that if you need me to re-wire the circuit board I could do it fairly quickly if need be. I know how to create analog and digital circuits using and, nor, or, nand, + inverter gates, etc., and try to do so so we could make our spacing more efficient on the ASP-BOT because I am now wrapping up a class I took at school on that subject. Just offering.
Chase
Clever idea Chase, using a rounded hub cup to make sure the ASP-BOT lands upright. We had discussed offsetting the parachute's shroud lines ("strings") but that idea got complicated when we had to consider how to release the parachute at touchdown. I like the hub cap idea a lot: it's simple and functional. Should we use a Ford, Chevy, or BMW hub cap?
Now that you mention it... One of the next things we have to do is reconstruct the (blue and yellow) ASP-2's circuitry on the new (yellow-wheeled) ASP-BOT. We also have to solder up a new ADC (analog-to-digtital) converter, etc. So your skills will come in handy. How are you with programming? Andrew and Dylan could use some help figuring out the program sequence. Fair warning: it's deep stuff and you have to understand all of it in order to do some of it.
Glad to see you active here on the forum,
Mr. Kibler
:nerd:
I was just thinking about the hubcap option. In ARLISS is there a weight limit? If so, what is it, and how close are we to it? The idea sounds like a good one, though.
Justin
Yawn,
Mr. Kibler
:nerd:
I've been a little hesitant to comment on the program itself, as that has been Tracy's area. It looks to me as though you've been doing the right kind of problem solving (i.e., putting DEBUG statements into the appropriate subroutines to see if they work). Here are my suggestions:
1 - Make certain that the code in your movement subroutine actually does what you want it to do. You have
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 NEXTTry uploading _just_ that code to the BOE, and make sure that it spins the wheels when you run it.
2 - Make sure that the MAWD data make sense. Write a program that just runs your MAWD_get routine and displays the value of the feet variable on the screen.
3 - You have this:
I think that those could be combined into one routine, rather than having the consecutive 0s check moved into its own subroutine. Regardless, set up a test program so that rather than starting the movement subroutine, when the zerocounter reaches 8, have it display "Landed" to the screen, to check to see that's working.
I take it that the "thousand counter" stuff and the MainMAWDMovement stuff is to get it started checking for landing only after you're sure you've been up over 1000 feet. That's good. Now, in the stuff where you check for landing, you're reading the MAWD once, putting that value into the feet variable, and then if it's 0, checking to see if it stays 0 over 8 counts of the zerocounter. But you're never going back to read the next value from the MAWD while you're in that loop. "feet" is of course going to stay at 0 over that time, because there's nothing there to change it. The first time that you get a 0 from the MAWD, it's going to go to Check_Consecutive, where the zerocounter will count to 8, and then start the movement subroutine. There's nothing in there to make sure that the altitude has stayed at 0 for that time - you never went back and read another value from the MAWD.
You need something that looks like this:
Read the altitude from the MAWD
If altitude does equal 0, note that fact, and add one to your counter
If the counter = 8, then set your landing flag (you have landed)
If altitude does not equal 0, set your counter back to 0 (the previous 0 was just a glitch)
If the landing flag is not set, go back to the start
If the landing flag IS set, you've landed, and you can get out of this loop and run the movement routine
Does that help? Notice that if you haven't landed, you go back to the start and read the altitude again. You're missing that step.
I'd be interesting in helping out with this, yes. I have to see what it involves, but feel free to put me in the loop on it.
Paul
Chase, I love the hubcab idea. It's very elegant and should work. I think we should look deeper into the idea and try to maximize the space and efficiency. What I mean by that is look at how sperical it is.
What should we make it out of though, metal would be too heavy.
See ya all soon
I got a chance to look at the ASP-Bot with it's smaller size today. It is much smaller than i anticipated.
Emily and Justin- We need to plan on having to use the wheel's servo to release the mechanism, unless space provides room for another servo. Although I do really like Justin's idea of using the wheel's servo, you then contradicted yourself with the starting the wheels spinning twenty feet from the ground. That would release the parachute if i'm not mistaken?
Chase- I really like the idea of using a "hub cap" but after i saw how much room we have left, I don't know that we can! what if we rounded the edge of the wheel instead? That in the end gives us MORE room with a HIGHER chance of a succesful landing. Post what you think about this?
Good work all!
-Jake-
P.S Justin and Emily and dylan and anyone else who wants to praticapate- It would be outstanding if we could meet up this weekend and work on using the wheels servo. Sunday would work best for me, later in the day. We can meet at my house or anyone elses who is willing to host the team. Thanks
Emily
Remember as you plan your weekend that the Harvard University SEDS rocketry group meeting is this SATURDAY. We'll leave the Concord area around 12:30 and return around 6:30 or 7:00 PM, with dinner on the way home at a restaurant.
This is who has confirmed to go to Harvard on Saturday so far:
Obie
Justin
Please confirm if you are going to Harvard here on the forum. I know more of you said you were going. I just forgot who.
Mr. Kibler
:cool:
"participate" <