Here we go. I just ran two programs. Both we credit to PJ for getting things rolling along very nicely.
I ran:
1) "Main_Program_with_Controlled_Altitude-April 6, 2011.bse" (post #11 in this forum.)
2) "ASP-BOT MAWD GET - April 6, 2011.bpe" (post #1471 in our other ARLISS forum.)
Both programs read out simulated altitude data beautifully when it's entered manually, in slightly different formats (see attached screen shots.) The Data Logger continues to record actual temperature, humidity, CO2 (mV), and time as it waits for manual data input.
"Main_Program_with_Controlled_Altitude" has no "movement" subroutine for the MAWD to activate.
"ASP-BOT MAWD GET" does have an actual servo movement subroutine at the bottom.
"ASP-BOT MAWD GET" theortically should have activated the servo connected to PIN 14 when a simulated altitude of 00000 feet was manually entered. The servo didn't move but I could have the code written wrong. I believe all the subroutines to make the servo move are somewhere in the "MAWD GET" version.
The simulated launch (data manually entered) seems very successful and the program seesm to work really well at this juncture. Where do we go from here, Rocketeers?
3) MAWD_get routine should be changed back to the original and the MAWD re-connected to the Stamp input. Keep the DEBUG in the Main: DO..LOOP ***
I guess it has to go in the bell jar because, apparently, the MAWD doesn't "go" till there's a change (not specified) in pressure. This is where/how we find how the MAWD kicks data after landing/touchdown.
4) Change "Movement" to incorporate your servo routine. ^^^
Once that's working 100% then you can remove the DEBUG from the Main: dO..LOOP and you have your flight-ready example.
modified program = Dylan's work in Post# 11
*** - programming still to be done
^^^ - programming still to be done
I think this is where we are now, #3 and #4 above. Does that seem right? Dylan, I'll let you and PJ and Andrew piece the program together from here (#3 and #4?)
So it seems like the controlled altitude worked well. Now we must run it in the Bell Jar... Unless you did it for that trial already Mr. Kibler.
Doesn't it still need manual data entry if I run it in the bell jar though? Won't you have to change the MAWD GET subroutine to like it was before so that it works in the bell jar without manual data entry? (see PJ suggestions and my last post)...
Well that is correct, so I will have to change the program. But then might as well as move on to steps 3 and 4. I will submit the changed program with what I believe will work....
Well that is correct, so I will have to change the program. But then might as well as move on to steps 3 and 4. I will submit the changed program with what I believe will work....
Does PJ agree that this is the next step? It seems like a logical next step... but you guys are a step ahead of me already! We seem really close here.
Test it in the Bell Jar. If it is automatic altitude instead of the controlled and you run it on the bench the altitude will stay at 00000. Here it is.
I have just checked my Private messages and it seems that PJ will not be on again until tomorrow. I think that we shall proceed without him for today.
OK, it runs fine on the bench and in the vacuum chamber. On the bench it measures everything except altitude. In the vacuum chamber it measures everything including altitude (see attached data.)
I'm not sure where that puts us because that's exactly what the ASP did before we started. I suppose the next step is to add a "movement" subroutine to see if the altimeter activates the servo at 0000000. We should use PIN 14.
I'm not sure where that puts us because that's exactly what the ASP did before we started.
Well Mr. Kibler,
These exercises made us able to know that the actual logic behind our program was correct. I will insert a movement program in place of the movement subroutine and report back.
This is the new program... It will run the motor attached to pin 14 counter clockwise for 1 second, then resume another set of data, followed by another 1 sec of movement. Of course after it has touched ground. But remember, you have to let it be above 1000 feet for 10 seconds before having it go under 1000 feet. So the program can check the altitude enough times before it starts checking for 0's.
In the vacuum chamber the servo runs every second from the time the BOE is turned on until it's turned off. It doesn't wait for the MAWD to activate it at 0000000. The MAWD doesn't seem to do much except measure and record altitude. It does that like it's supposed to.
I need to put things aside for the evening because I'm getting fatigued and I can't think this through straight. I'm not sure where things stand right now. Halfway there maybe??
Note that "feet = 0".
Looks like that makes the default feet data "0" when the MAWD shuts down (and when it's not working, pending activation by pressure change when sitting on the launch pad, too)
Can you nutshell your status for me?
The rocket has to stay above 1000_ft for 6 passes (ergo the thousandcounter, TC, = 6), so the asp-bot's assumption is genuine flight status achieved, whereupon all 00000 thereafter will be assumed genuine/on-the-ground indications.
I'm buoyed by these results posted, as I hope you all are, too.
The servo goes on all by itself?
It's supposed to be connected to P14 [X4 on the right side, next to the Vin_Vdd select, and that should be set right (V-dd?), too]
Might want to add a DEBUG to the Movement subroutine (??)
At present, it's:
Movement:
FOR movement1 = 1 TO 43 ' 0 TO 42 ??
PULSOUT 14, 850
NEXT
RETURN
Shouldn't there be a PAUSE before each NEXT, to keep inside the appx 20ms servo refresh repetition rate (50x/sec, 1 ea. 20msec)?
Movement:
DEBUG "movn", CR
FOR movement1 = 1 TO 43 ' 0 TO 42 ??
PULSOUT 14, 850
PAUSE 18 ' ???
NEXT
RETURN
PE -- Dylan, If necessary, verify your servo routine independent of the asp-bot software.
Something else to consider -- is P14 getting bopped, unintentionally, by something in the rest of the asp-bot software... making for an inadvertent servo pulse?
Something else to consider -- is P14 getting bopped, unintentionally, by something in the rest of the asp-bot software... making for an inadvertent servo pulse?
Would you suggest that they do a search through the program for any reference to "P14"?
Or are you suggesting that something else is making a pulse go out through that pin (despite not referring directly to that pin)?
"Or are you suggesting that something else is making a pulse go out through that pin (despite not referring directly to that pin)?" That's a possibility, accessing the output register, and thereby P14, (by the seemingly ineffable "somehow".)
The easiest way to tell, I figure, might be going back to "Step 1", BUT substituting their servo routine in the "Movement" subroutine.
Longer than a nutshell. A larger nutshell perhaps. A coconut shell?
1) BENCH TEST:
a) BOE outputs CO2 (mV), temperature, humidity, elapsed time, and "0" altitude as it should.
b) Everything records to Data Logger just fine.
c) Servo attached to P14 pulses every second beginning at BOE boot-up
2) VACUUM CHAMBER:
a) BOE outputs and records CO2 (mV), temperature, humidity, and elapsed time to the Data Logger as it should.
b) Altitude is also recorded to flash drive as it should be.
c) Servo attached to P14 pulses every second beginning at BOE boot-up.
d) Servo does not appear to be affected or activated in any way when the MAWD reaches 000000000000
e) BOE continues to read and write data at altitude = 00000000000000 as it should.
and "0" altitude
PJ said: Something else to consider -- is P14 getting bopped, unintentionally, by something in the rest of the asp-bot software... making for an inadvertent servo pulse?
Yes, I think this may, in fact, be the case. P14 is getting bopped by electromagnetic interference from elsewhere in the circuitry or program.
PJ said: The servo goes on all by itself?
Yes, right at boot-up it starts pulsing every second, seemingly in sync with data collection (which is every second or two.)
PJ said: Has the servo been connected all along?
No, only last evening when the ASP-BOT was bench tested and then tested in the vaccum chamber.
OK, the servo could only activate based on an actual pulse, not from ephemera like "EMI" or "interference".
Nothing in previous versions or applications have/has been connected to P14.
That it occurs "every second", regularly, is telling - it's coinciding with some process (then.)
My surmise is that the output register is getting "corrupted", unintentionally.
I'd always understood the issue to have been that Movement never executed based on the consecutive zeros plan, but now it's on repeatedly?
So, the once per second occurence is a new development?
Movement:
'movementCounter VAR Byte ' Moved to top of program.-D.L, March 19 2011
DEBUG "Movement has Started.", CR
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
RETURN 'No return was here. Causing returning to the program that called this subroutine impossible.- D.L., March 19 2011
'PAUSE 3000 'Unsure why this was there... [COLOR="red"]Could this of been the source of the problem to why the motors did not move once it red 8 0's?[/COLOR] No, it would of debuged the above statement even if the motors weren't moving.- D.L., March 19 2011
I'd always understood the issue to have been that Movement never executed based on the consecutive zeros plan, but now it's on repeatedly?
I don't think the movement program is getting activated at all at 00000000. Yes, the servo is pulsing like a femoral artery about every second, at least when I ran the program last night (bench test + vacuum chamber.). I'll repeat teh same progarm tonight to make such it wasn't connected wrong. But I'm certain it wasn't. Nothing else that I could see in the program uses P14.
So, the once per second occurence is a new development
No. It was doing the same thing during our last practice when Dylan and Andrew ran a simulation program (zerocounter + 1 ??)
I pointed this out to them and explained that the wheels (servos) can't be moving inside the rocket during ascent for all sorts of reasons. For example, if you're in the actual vacuum of deep space you'd get rotational torque... not good if you're trying to fly in a straight line. In our project the parachute's shroud lines go through holes in the wheel hubs and they're anchored on the robot's platform. If the wheels move (3 minute ascent, 26 minutes descent), the parachute lines are slowly strangling the robot second by second,1/32 of a turn at a time.
I agree that the servo wheels should turn only under command.
Neither the zerocounter nor thousandcounter subroutines (liftoff, checkliftoff) play with the I/O.
The "last practice"... sometimes you all are calling these sessions "practice", too, but you have your get-togethers as well.
I think we need to talk about revision levels, get back to the last rev level without inappropriate servoing and incorporate the "new stuff" until the problem (re. servos) re-surfaces.
And fine-tooth comb the wiring to the Stamp I/O (P0-15)
I agree that the servo wheels should turn only under command.
Neither the zerocounter nor thousandcounter subroutines (liftoff, checkliftoff) play with the I/O.
The "last practice"... sometimes you all are calling these sessions "practice", too, but you have your get-togethers as well.
"Practices" are the bi-weekly build sessions. Forum time is "on-line team time".
I think we need to talk about revision levels, get back to the last rev level without inappropriate servoing and incorporate the "new stuff" until the problem (re. servos) re-surfaces.
And fine-tooth comb the wiring to the Stamp I/O (P0-15)
Agreed. Isolate the variables, one by one. Slow and tedious, but necessary. I propose that we start with a template for the program-- a starting point-- then add to it and keep good a record of the revision history, and the name of the program. Sometimes I'm not sure which version of the program(s) we've adding to, or cutting-and-pasting from.
Re: the wiring, the servo pulsed every second on three different BOE set-ups during our last build session. That suggests it's not a wiring problm (unless all three BOE's were wired wrong, and in the same way.) However, it also pulses on last year's ASP, which uses the same BOE wiring and the same program.
Headed home; more from there later in the evening,
I'm restarting testing with Dylan's "MAWD GET MOVEMENT" program from post #46 in this forum:
Automatic_MAWDget_with_movement-April 7, 2011.bse
As a point of future reference let's call this "MAWD GET v.1" and add or subtract program code from this version. I'm using this as our starting point unless PJ wants me to go back to an older version. I'll post the results shortly.
Comments
Here we go. I just ran two programs. Both we credit to PJ for getting things rolling along very nicely.
I ran:
1) "Main_Program_with_Controlled_Altitude-April 6, 2011.bse" (post #11 in this forum.)
2) "ASP-BOT MAWD GET - April 6, 2011.bpe" (post #1471 in our other ARLISS forum.)
Both programs read out simulated altitude data beautifully when it's entered manually, in slightly different formats (see attached screen shots.) The Data Logger continues to record actual temperature, humidity, CO2 (mV), and time as it waits for manual data input.
"Main_Program_with_Controlled_Altitude" has no "movement" subroutine for the MAWD to activate.
"ASP-BOT MAWD GET" does have an actual servo movement subroutine at the bottom.
"ASP-BOT MAWD GET" theortically should have activated the servo connected to PIN 14 when a simulated altitude of 00000 feet was manually entered. The servo didn't move but I could have the code written wrong. I believe all the subroutines to make the servo move are somewhere in the "MAWD GET" version.
The simulated launch (data manually entered) seems very successful and the program seesm to work really well at this juncture. Where do we go from here, Rocketeers?
Standing by,
MK
:cool:
I think this is where we are now, #3 and #4 above. Does that seem right? Dylan, I'll let you and PJ and Andrew piece the program together from here (#3 and #4?)
Standing by,
MK
Doesn't it still need manual data entry if I run it in the bell jar though? Won't you have to change the MAWD GET subroutine to like it was before so that it works in the bell jar without manual data entry? (see PJ suggestions and my last post)...
???
Mr. Kibler
Does PJ agree that this is the next step? It seems like a logical next step... but you guys are a step ahead of me already! We seem really close here.
MK
:cool:
MK
Or wait for PJ's input?
MK
OK, it runs fine on the bench and in the vacuum chamber. On the bench it measures everything except altitude. In the vacuum chamber it measures everything including altitude (see attached data.)
I'm not sure where that puts us because that's exactly what the ASP did before we started. I suppose the next step is to add a "movement" subroutine to see if the altimeter activates the servo at 0000000. We should use PIN 14.
???
MK
:cool:
These exercises made us able to know that the actual logic behind our program was correct. I will insert a movement program in place of the movement subroutine and report back.
In the vacuum chamber the servo runs every second from the time the BOE is turned on until it's turned off. It doesn't wait for the MAWD to activate it at 0000000. The MAWD doesn't seem to do much except measure and record altitude. It does that like it's supposed to.
I need to put things aside for the evening because I'm getting fatigued and I can't think this through straight. I'm not sure where things stand right now. Halfway there maybe??
MK
It looks like there was much progress made. There's a servo glitch?
I was looking at the MAWDget, the flight-worthy version --
[CODE}
MAWD_get:
'
PULSIN MAWDin,1,iobyte '
PAUSE 10 '
'
feet=0
SERIN MAWDin,84,64,MAWDnot,[DEC5 feet]
MAWDnot:
RETURN
[/code]
Note that "feet = 0".
Looks like that makes the default feet data "0" when the MAWD shuts down (and when it's not working, pending activation by pressure change when sitting on the launch pad, too)
Can you nutshell your status for me?
I'm buoyed by these results posted, as I hope you all are, too.
It's supposed to be connected to P14 [X4 on the right side, next to the Vin_Vdd select, and that should be set right (V-dd?), too]
Might want to add a DEBUG to the Movement subroutine (??)
At present, it's:
Movement: FOR movement1 = 1 TO 43 ' 0 TO 42 ?? PULSOUT 14, 850 NEXT RETURNShouldn't there be a PAUSE before each NEXT, to keep inside the appx 20ms servo refresh repetition rate (50x/sec, 1 ea. 20msec)?
Movement: DEBUG "movn", CR FOR movement1 = 1 TO 43 ' 0 TO 42 ?? PULSOUT 14, 850 PAUSE 18 ' ??? NEXT RETURNPE -- Dylan, If necessary, verify your servo routine independent of the asp-bot software.
Would you suggest that they do a search through the program for any reference to "P14"?
Or are you suggesting that something else is making a pulse go out through that pin (despite not referring directly to that pin)?
The easiest way to tell, I figure, might be going back to "Step 1", BUT substituting their servo routine in the "Movement" subroutine.
Has the servo been connected all along?
Longer than a nutshell. A larger nutshell perhaps. A coconut shell?
1) BENCH TEST:
a) BOE outputs CO2 (mV), temperature, humidity, elapsed time, and "0" altitude as it should.
b) Everything records to Data Logger just fine.
c) Servo attached to P14 pulses every second beginning at BOE boot-up
2) VACUUM CHAMBER:
a) BOE outputs and records CO2 (mV), temperature, humidity, and elapsed time to the Data Logger as it should.
b) Altitude is also recorded to flash drive as it should be.
c) Servo attached to P14 pulses every second beginning at BOE boot-up.
d) Servo does not appear to be affected or activated in any way when the MAWD reaches 000000000000
e) BOE continues to read and write data at altitude = 00000000000000 as it should.
and "0" altitude
Yes, I think this may, in fact, be the case. P14 is getting bopped by electromagnetic interference from elsewhere in the circuitry or program.
Yes, right at boot-up it starts pulsing every second, seemingly in sync with data collection (which is every second or two.)
No, only last evening when the ASP-BOT was bench tested and then tested in the vaccum chamber.
MK
Yes
Yes, one servo is connected to P14 at X4 = red, white, and black wires
MK
:cool:
Nothing in previous versions or applications have/has been connected to P14.
That it occurs "every second", regularly, is telling - it's coinciding with some process (then.)
My surmise is that the output register is getting "corrupted", unintentionally.
At Initialisation, it gets set LOW: But it's changing states outside of the "Movement" subroutine".
Now to find when that occurs.
So, the once per second occurence is a new development?
Movement: 'movementCounter VAR Byte ' Moved to top of program.-D.L, March 19 2011 DEBUG "Movement has Started.", CR 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 RETURN 'No return was here. Causing returning to the program that called this subroutine impossible.- D.L., March 19 2011 'PAUSE 3000 'Unsure why this was there... [COLOR="red"]Could this of been the source of the problem to why the motors did not move once it red 8 0's?[/COLOR] No, it would of debuged the above statement even if the motors weren't moving.- D.L., March 19 2011I don't think the movement program is getting activated at all at 00000000. Yes, the servo is pulsing like a femoral artery about every second, at least when I ran the program last night (bench test + vacuum chamber.). I'll repeat teh same progarm tonight to make such it wasn't connected wrong. But I'm certain it wasn't. Nothing else that I could see in the program uses P14.
No. It was doing the same thing during our last practice when Dylan and Andrew ran a simulation program (zerocounter + 1 ??)
I pointed this out to them and explained that the wheels (servos) can't be moving inside the rocket during ascent for all sorts of reasons. For example, if you're in the actual vacuum of deep space you'd get rotational torque... not good if you're trying to fly in a straight line. In our project the parachute's shroud lines go through holes in the wheel hubs and they're anchored on the robot's platform. If the wheels move (3 minute ascent, 26 minutes descent), the parachute lines are slowly strangling the robot second by second,1/32 of a turn at a time.
MK
:cool:
Neither the zerocounter nor thousandcounter subroutines (liftoff, checkliftoff) play with the I/O.
The "last practice"... sometimes you all are calling these sessions "practice", too, but you have your get-togethers as well.
I think we need to talk about revision levels, get back to the last rev level without inappropriate servoing and incorporate the "new stuff" until the problem (re. servos) re-surfaces.
And fine-tooth comb the wiring to the Stamp I/O (P0-15)
"Practices" are the bi-weekly build sessions. Forum time is "on-line team time".
Agreed. Isolate the variables, one by one. Slow and tedious, but necessary. I propose that we start with a template for the program-- a starting point-- then add to it and keep good a record of the revision history, and the name of the program. Sometimes I'm not sure which version of the program(s) we've adding to, or cutting-and-pasting from.
Re: the wiring, the servo pulsed every second on three different BOE set-ups during our last build session. That suggests it's not a wiring problm (unless all three BOE's were wired wrong, and in the same way.) However, it also pulses on last year's ASP, which uses the same BOE wiring and the same program.
Headed home; more from there later in the evening,
MK
:cool:
Automatic_MAWDget_with_movement-April 7, 2011.bse
As a point of future reference let's call this "MAWD GET v.1" and add or subtract program code from this version. I'm using this as our starting point unless PJ wants me to go back to an older version. I'll post the results shortly.
Mark
:cool: