I apologize for not being on more often. I get home around 6:00 from track in the afternoon, have homework, studying then dinner before I can get on the forum again. I also go to bed around 10:30, so I try to get in as much as I can.
P.S. Andrew and I use a program so we can both work on the same computer even if we aren't near each other. That helps us get more work done in a higher quality level then we can just alone. We are usually on it from around 7:30 - 8:30 PM weekdays, although the times can differ due to events we have to be at.
----For the program you posted PJ, I can run that on my BoE even if I don't have the MAWD, so I will do that soon and report back.
But before that, do you want to start a new thread for just this MAWD programming set of issues?
PJ,
Andrew does not seem to be online right now, but I am sure that he would agree with the decision to make a new thread.
I will start a new thread ARLISS_MAWD, right away and report my findings from both the program with Max's and the program you have just uploaded.
I think that artists and rocket scientists will be the death of me.
The sheep are all gone astray, each is turned unto his own way.
That "new MAWDget" (Apr 6, 2011) is the old "MAWDget".
Not exactly. The "new MAWD get" has a movement subroutine and the new subroutine you just posted. They're similar yes, but I don't think they're the same.
I have a final simulator.
It has a GOSUB for repeated "Movement" calls.
Please let me know that you understand what's going on or if you don't.
Thanks.
No toto comprendo,
In 'mawdsimulation3.bs',
1) GOTO movement was changed to GOSUB movement
2) END was changed to RETURN (returns out of the subroutine rather than ending the program)
Why the two subtle changes? Why can't you count the sheep? You should sleep.
================================================
Here are the tech specs for the MAWD from PerfectFlite. The data is, in fact, streamed in ASCII
Following is a blurb about the telemetry output from the MAWD. When connecting to the data port with anything other than our DT2P/DT2U interfaces, pleas make sure you connect the output from the altimeter only to an input on your circuitry and vice versa. Isolating the altimeter with 330 ohm resistors in series with the TX data and RX data lines will offer protection to the altimeter and your circuitry in the event of a mis-connection.
As far as the telemetry data goes; signal level is TTL at the altimeter, or converted to RS-232 by the DT2P data transfer interface. There is a command list and connector pinout on page 23 of the manual, and the serial data format ands speed are noted in the specs on page 22 (telemetry is streamed at a slower data rate than commands and data download to better accommodate most RF modems).
Data are streamed in ASCII format, lines terminated with CRLF, in feet AGL, starting at launch detect until 5 seconds after landing. e.g:
00168
00222
00289
00337
...
Data are streamed at 20 samples per second.
Data streaming is off from factory default; it is enabled using the data transfer kit and remains on (even through power cycling) until it is explicitly turned off.
That much is required unless the Movement subroutine was/is to go only one pass and STOP.
There are supposed to be several iterations, I think.
Anyway.
The team's program/s were GOSUBing, so I put that much back that way.
Emily and Justin- I'm unsure when would be the best time to meet.Either sometime next week, or just a lot of conversation would suffice. It should be in our best interest to have all of our prototypes uploaded so we have a place to start, and then start to prototype the ideas if you have the tools to do it. Justin, Mr. Kibler and I are a still a little confused about your idea. I understand how it releases, but very confused as to how the bar wont just come out? When the parachute comes out of the payload, it will pull directly on the end of the pin, releasing it so quickly you wont even have time to say "oops". Keep up the good work. Remember, engineering doesn't just take book smarts, it takes creativity and imagination. I think this is something we should all think about. We are trying to do things that derive from things we learned in books, but have we tried anything that has that gut feeling "this is the one"?
I think we are almost about to get a break through. Knowing the wheel wont turn in air just helped us that much more.
Thanks
-JAKE-
P.S I think we are all on the edge of something great! We just have to keep going!
If you look at the sketch, the groove does not go out to the edges of the wheel. When you launch, the last bit of the groove that does not go out of the wheel the rod is in there and against the plexiglass so there is no where for it to go. It isn't until the wheel turns that the rod can slip out. There is no pin, so I'm not sure what pin you are talking about. This idea isn't out of any book, so I don't know where you are going with that... I'm willing to try anyone's suggestion, and I think ultimately the idea that works might be any one of the three ideas that gets improved upon after we do testing. Or it might be a brand new idea that is thought of after we look at why one of the other ideas wouldn't work.
I anyone still didn't get my idea of the parachute release mechanism, I built a lego prototype of it to show you the concept of it. Sorry about the quality of the video and the prototype. It was just a quick thing to show you how it kind of worked. [video]https://docs.google.com/leaf?id=0B9dlkKFHZ9FoYjkyMmQ0ZTItNjRmOC00NmY2LThjM zktMGI2NjJhMDY1YzVh&hl=en&authkey=CMOfkYYG[/video]
Justin-
Thanks for the video. That makes it much easier to understand. I'm still confused at how it is able to not just get pulled out. Try putting some strain on it and and pulling in different directions. I'm curious to know the results. In the video you only pulled up. this however will not be the case, as far as I know. You also said that the shroud lines go through the wheel, but if the bar just falls out, how does it let go of the shroud lines? It's a good idea! Hopefully we can meet up soon and see it in person. The video was very unstable. Not to be a critic because I probably wouldn't have done much better.
Emily-
I suggest we follow Justin's example by making videos as well. explanations can be very confusing.
Thanks so much!
-Jake-
P.S Justin-
How did you upload your video to Google docs? Great job!
I anyone still didn't get my idea of the parachute release mechanism, I built a lego prototype of it to show you the concept of it. Sorry about the quality of the video and the prototype. It was just a quick thing to show you how it kind of worked. [video]https://docs.google.com/leaf?id=0B9dlkKFHZ9FoYjkyMmQ0ZTItNjRmOC00NmY2LThjM zktMGI2NjJhMDY1YzVh&hl=en&authkey=CMOfkYYG[/video]
Justin,
This is exactly the type of initiative I'm looking for. Keep up the good work!
It seems like we are all talking about how the wheels will stay stationary during the descent of the ASP-Bot.... But exactly how?
The payload is prey of quite a lot of force that is being thrown around during its fall. So how exactly will the wheels stay in position untill landing?
Thanks Justin that helped alot!
as for Dylan's comment aren't there servos that lock in a certain position? or am I incorrect?
Jake, I would post a video if I could bu when I come up with an Idea I'll draw it out and try my very best to explain it.
Emily
Jake, I cannot put my prototype through testing simply because of the materials it is made of. I just put the prototype together to illustrate the idea. It is made fairly shakily and the legos will come apart much more easily than an actual wooden prototype. That is why I wanted to meet with you to see if we couldn't put together a stronger version... As for the shroud lines, I looked at two different methods. One would be going through the wheels and then the connection on the rod would be a loos loop. So that when the rod was released, the loop would come off the rod and then the shroud lines would come back through the wheel. The other possibility, which I know you didn't like as well, is to perhaps is to cut a very small notch in the wheel, much like a tread. The line would then be on the outside of the wheel. It could then be attached firmly to the rod. This would also take care of the problem with landing as it would land with the two wheels touching at the same time.
Justin
Jake--If you look at the upper right hand corner of the Google homepage you can sign up for a Google account which you can post stuff to. Make them public, and then you can post a link.
P.S. Sorry about the quality of the video. I had to turn down the quality so that it didn't take forever to load to the website.
It seems like we are all talking about how the wheels will stay stationary during the descent of the ASP-Bot.... But exactly how?
So how exactly will the wheels stay in position untill landing?
I'm curious how the wheels will stay in position, too. Right now the wheels move every 1 second from the very moment the ASP-BOT is turned on. We need to write the program so the wheels don't move at all-- not even 1/8 of a rotation-- until after the ASP-BOT has landed,
I will not be on the forum from tonight to Sunday morning because I will be on a Boy Scout camping trip. Jake, if you wanted to do prototyping work we can still do that Sunday afternoon. If you need to talk to me I will have my phone at (603) - 738 - 4643(and yes ,Mr. Kibler, I know we are not supposed to have cell phones in scouts, but they let us).
If you need to talk to me I will have my phone at (603) - 738 - 4643(and yes ,Mr. Kibler, I know we are not supposed to have cell phones in scouts, but they let us).
"A Scout is trustworthy."
Have fun at the campout and watch out for bears! See you on the forum when you return.
Everyone,
I think it is important to get sorted out now if there is going to be a meeting for whichever teams this weekend. (Parachute Release team, Design team). I believe it is critical for the parachute team to at least meet once before next practice, as well as for the design team.
Tonight, thanks to PJ and Dylan's work, the ASP-BOT moves when it lands! We are indebted to PJ for giving us his time and expertise, and to Dylan and PJ for their diligence is seeing this problem through to good (great!) resolution. Please be sure to thank PJ for his help, everyone.
There are a few minor "tweaks" to be made in the program and I'd like Dylan and Andrew to work on these the next time we meet. But we're over the hump as far as getting the ASP-BOT moving once it lands.
PJ said that he'll be monitoring the forum and that he'll assist you as needed. But let's not wear out our welcome, either. He's already given us plenty of his time.
Now for the "bad news": we're out of PINs and there's no place to plug in the second servomotor on the BOE! You've aleady figured out what this means, right? We have to run two wheels with one motor....! Rocketeers, put your thinking caps on. We have a mechanical engineering challenge to solve.
Congratulations!
PJ-Thank you so much for all the help you have provided us with the "road bumps" to our final destination. We may not have made it this far without you!
As for this new problem, it also creates a space problem. The two servos happened to be out of the way so there was plenty of room for all the other gear. But there is an upside to this, that being that now we can put a larger piece of plexi glass in between the two wheels, now that the servos are gone. As for the actual problem, we have to either put two BoEs on the glass, or use a system similar to how a car works. If we did have one rod connecting to both wheels, the wheels wouldn't be so weak, but there wouldn't be as much power. It could easily get stuck somewhere.
Congratulations again and thank you so much again for the help PJ!
Oh! I almost forgot! Dylan, I do believe it would be important for the Parachute release mechanism team to meet, and now that the musical is over, I'm free after school! So lets plan a time for sometime this week.
I'm back from my camping trip. I could meet, today in the afternoon--anytime between 1-5. My phone is listed above. I could meet Monday, anytime. Tuesday, my brother will be in surgery, so I will be in MA with my Dad, and won't be home until probably around 6:30. Wednesday, I could meet anytime. Thursday, would be bad due to Boy Scouts, unless we could meet as soon as people were off from school. I need to be at Boy Scouts by 7:00. Friday, I could be free any time. Saturday, I have something in the afternoon, but could meet early morning. Any of these times are fine with me, so just let me know.
As for this new problem, it also creates a space problem. The two servos happened to be out of the way so there was plenty of room for all the other gear. But there is an upside to this, that being that now we can put a larger piece of plexi glass in between the two wheels, now that the servos are gone.
Woah woah woah.. Why don't we have two servo's? I understand that we only had one pin left, but we have not discussed yet if we can free up a pin, or any other capabilities. Like somehow controlling two separate servo's with one pin. Having two BoE's could be a possibility, but that would take up too much space I believe. And you said that not having the two Servo's freed up space two put a bigger piece of plexi glass in between the wheels, but we need atleast one servo somewhere in there to make the ASP-Bot move. Also as one more thing. If we were to have a bar between the two wheels to replicate how a car steers, how would we get that bar to move? We would need to have something to move the bar, potentially another servo that we don't have pins for.
Comments
P.S. Andrew and I use a program so we can both work on the same computer even if we aren't near each other. That helps us get more work done in a higher quality level then we can just alone. We are usually on it from around 7:30 - 8:30 PM weekdays, although the times can differ due to events we have to be at.
----For the program you posted PJ, I can run that on my BoE even if I don't have the MAWD, so I will do that soon and report back.
But before that, do you want to start a new thread for just this MAWD programming set of issues?
The sheep are all gone astray, each is turned unto his own way.
That "new MAWDget" (Apr 6, 2011) is the old "MAWDget".
A new Subject "ARLISS_MAWD" would be a good idea, provided you all concur.
It has a GOSUB for repeated "Movement" calls.
Please let me know that you understand what's going on or if you don't.
Thanks.
Andrew does not seem to be online right now, but I am sure that he would agree with the decision to make a new thread.
I will start a new thread ARLISS_MAWD, right away and report my findings from both the program with Max's and the program you have just uploaded.
Is there a razor sharp enough to cut kevlar?
What time are we meeting at Jake's?
I'll think of one or two ideas and bring sketches Sunday
do you have any ideas Jake?
Emily
I concur with a new "ARLISS - MAWD" thread.
MK
Not exactly. The "new MAWD get" has a movement subroutine and the new subroutine you just posted. They're similar yes, but I don't think they're the same.
MK
No toto comprendo,
In 'mawdsimulation3.bs',
1) GOTO movement was changed to GOSUB movement
2) END was changed to RETURN (returns out of the subroutine rather than ending the program)
Why the two subtle changes? Why can't you count the sheep? You should sleep.
================================================
Here are the tech specs for the MAWD from PerfectFlite. The data is, in fact, streamed in ASCII
Following is a blurb about the telemetry output from the MAWD. When connecting to the data port with anything other than our DT2P/DT2U interfaces, pleas make sure you connect the output from the altimeter only to an input on your circuitry and vice versa. Isolating the altimeter with 330 ohm resistors in series with the TX data and RX data lines will offer protection to the altimeter and your circuitry in the event of a mis-connection.
As far as the telemetry data goes; signal level is TTL at the altimeter, or converted to RS-232 by the DT2P data transfer interface. There is a command list and connector pinout on page 23 of the manual, and the serial data format ands speed are noted in the specs on page 22 (telemetry is streamed at a slower data rate than commands and data download to better accommodate most RF modems).
Data are streamed in ASCII format, lines terminated with CRLF, in feet AGL, starting at launch detect until 5 seconds after landing. e.g:
00168
00222
00289
00337
...
Data are streamed at 20 samples per second.
Data streaming is off from factory default; it is enabled using the data transfer kit and remains on (even through power cycling) until it is explicitly turned off.
MK
in re. GOTO to GOSUB and END to RETURN
That much is required unless the Movement subroutine was/is to go only one pass and STOP.
There are supposed to be several iterations, I think.
Anyway.
The team's program/s were GOSUBing, so I put that much back that way.
I think we are almost about to get a break through. Knowing the wheel wont turn in air just helped us that much more.
Thanks
-JAKE-
P.S I think we are all on the edge of something great! We just have to keep going!
If you look at the sketch, the groove does not go out to the edges of the wheel. When you launch, the last bit of the groove that does not go out of the wheel the rod is in there and against the plexiglass so there is no where for it to go. It isn't until the wheel turns that the rod can slip out. There is no pin, so I'm not sure what pin you are talking about. This idea isn't out of any book, so I don't know where you are going with that... I'm willing to try anyone's suggestion, and I think ultimately the idea that works might be any one of the three ideas that gets improved upon after we do testing. Or it might be a brand new idea that is thought of after we look at why one of the other ideas wouldn't work.
Justin
I anyone still didn't get my idea of the parachute release mechanism, I built a lego prototype of it to show you the concept of it. Sorry about the quality of the video and the prototype. It was just a quick thing to show you how it kind of worked. [video]https://docs.google.com/leaf?id=0B9dlkKFHZ9FoYjkyMmQ0ZTItNjRmOC00NmY2LThjM zktMGI2NjJhMDY1YzVh&hl=en&authkey=CMOfkYYG[/video]
Thanks for the video. That makes it much easier to understand. I'm still confused at how it is able to not just get pulled out. Try putting some strain on it and and pulling in different directions. I'm curious to know the results. In the video you only pulled up. this however will not be the case, as far as I know. You also said that the shroud lines go through the wheel, but if the bar just falls out, how does it let go of the shroud lines? It's a good idea! Hopefully we can meet up soon and see it in person. The video was very unstable. Not to be a critic because I probably wouldn't have done much better.
Emily-
I suggest we follow Justin's example by making videos as well. explanations can be very confusing.
Thanks so much!
-Jake-
P.S Justin-
How did you upload your video to Google docs? Great job!
Justin,
This is exactly the type of initiative I'm looking for. Keep up the good work!
Mr. Kibler
The payload is prey of quite a lot of force that is being thrown around during its fall. So how exactly will the wheels stay in position untill landing?
as for Dylan's comment aren't there servos that lock in a certain position? or am I incorrect?
Jake, I would post a video if I could bu when I come up with an Idea I'll draw it out and try my very best to explain it.
Emily
Jake, I cannot put my prototype through testing simply because of the materials it is made of. I just put the prototype together to illustrate the idea. It is made fairly shakily and the legos will come apart much more easily than an actual wooden prototype. That is why I wanted to meet with you to see if we couldn't put together a stronger version... As for the shroud lines, I looked at two different methods. One would be going through the wheels and then the connection on the rod would be a loos loop. So that when the rod was released, the loop would come off the rod and then the shroud lines would come back through the wheel. The other possibility, which I know you didn't like as well, is to perhaps is to cut a very small notch in the wheel, much like a tread. The line would then be on the outside of the wheel. It could then be attached firmly to the rod. This would also take care of the problem with landing as it would land with the two wheels touching at the same time.
Justin
Jake--If you look at the upper right hand corner of the Google homepage you can sign up for a Google account which you can post stuff to. Make them public, and then you can post a link.
P.S. Sorry about the quality of the video. I had to turn down the quality so that it didn't take forever to load to the website.
I'm curious how the wheels will stay in position, too. Right now the wheels move every 1 second from the very moment the ASP-BOT is turned on. We need to write the program so the wheels don't move at all-- not even 1/8 of a rotation-- until after the ASP-BOT has landed,
Mr. Kibler
:cool:
I will not be on the forum from tonight to Sunday morning because I will be on a Boy Scout camping trip. Jake, if you wanted to do prototyping work we can still do that Sunday afternoon. If you need to talk to me I will have my phone at (603) - 738 - 4643(and yes ,Mr. Kibler, I know we are not supposed to have cell phones in scouts, but they let us).
Justin
"A Scout is trustworthy."
Have fun at the campout and watch out for bears! See you on the forum when you return.
Mr. Kibler
I think it is important to get sorted out now if there is going to be a meeting for whichever teams this weekend. (Parachute Release team, Design team). I believe it is critical for the parachute team to at least meet once before next practice, as well as for the design team.
.
EUREKA!
Tonight, thanks to PJ and Dylan's work, the ASP-BOT moves when it lands! We are indebted to PJ for giving us his time and expertise, and to Dylan and PJ for their diligence is seeing this problem through to good (great!) resolution. Please be sure to thank PJ for his help, everyone.
There are a few minor "tweaks" to be made in the program and I'd like Dylan and Andrew to work on these the next time we meet. But we're over the hump as far as getting the ASP-BOT moving once it lands.
PJ said that he'll be monitoring the forum and that he'll assist you as needed. But let's not wear out our welcome, either. He's already given us plenty of his time.
Now for the "bad news": we're out of PINs and there's no place to plug in the second servomotor on the BOE! You've aleady figured out what this means, right? We have to run two wheels with one motor....! Rocketeers, put your thinking caps on. We have a mechanical engineering challenge to solve.
Thanks again for all your help, PJ ~ !
Mr. (Mark) Kibler
:cool:
PJ-Thank you so much for all the help you have provided us with the "road bumps" to our final destination. We may not have made it this far without you!
As for this new problem, it also creates a space problem. The two servos happened to be out of the way so there was plenty of room for all the other gear. But there is an upside to this, that being that now we can put a larger piece of plexi glass in between the two wheels, now that the servos are gone. As for the actual problem, we have to either put two BoEs on the glass, or use a system similar to how a car works. If we did have one rod connecting to both wheels, the wheels wouldn't be so weak, but there wouldn't be as much power. It could easily get stuck somewhere.
Congratulations again and thank you so much again for the help PJ!
-Jake-
Thanks again,
-Jake-
I'm back from my camping trip. I could meet, today in the afternoon--anytime between 1-5. My phone is listed above. I could meet Monday, anytime. Tuesday, my brother will be in surgery, so I will be in MA with my Dad, and won't be home until probably around 6:30. Wednesday, I could meet anytime. Thursday, would be bad due to Boy Scouts, unless we could meet as soon as people were off from school. I need to be at Boy Scouts by 7:00. Friday, I could be free any time. Saturday, I have something in the afternoon, but could meet early morning. Any of these times are fine with me, so just let me know.
Justin
Woah woah woah.. Why don't we have two servo's? I understand that we only had one pin left, but we have not discussed yet if we can free up a pin, or any other capabilities. Like somehow controlling two separate servo's with one pin. Having two BoE's could be a possibility, but that would take up too much space I believe. And you said that not having the two Servo's freed up space two put a bigger piece of plexi glass in between the wheels, but we need atleast one servo somewhere in there to make the ASP-Bot move. Also as one more thing. If we were to have a bar between the two wheels to replicate how a car steers, how would we get that bar to move? We would need to have something to move the bar, potentially another servo that we don't have pins for.