Hmm... when I click up the MPEG, I get a second or so of somebody pushing a button on the NXT, but the robot doesn't move... is the video broken?
As to the actual challenge, interesting! I need to try to implement your code to see how it works. How much play do you get when returning the "pivot bumper" to its home position (is it reliably set to exactly zero degrees each time, or does it overshoot somewhat?)
One of the reasons I want to implement your code is the crashing of the NXT: check to make sure your batteries weren't low, because if you've found a way to crash the firmware and/or reset the NXT due to just a code issue, it's the first I've heard of it, and I'm *very* interested.
-- Brian Davis
Anonymous said…
Brian,
I guess you are right about low batteries being the reason for the reboot. The batteries are low. With the parallel tasks, the NXT needs to run all 3 motors, which probably caused a large enough voltage drop for a reboot.
The reason I didn't suspect this is that with the previous set of batteries, there were on-screen warnings, but not with this set. But it's probably the reason. I'll try the program with parallel tasks and fresh batteries.
With respect to the overshooting: it returns to the home position accuractly. There is overshooting, but if you leave the motor in the brake state for long enough, it eventually settles accurately on the home position. I think that a feedback mechanism in the firmware does this.
The video works fine on my machine, but I'll try to reproduce another with hopefully a better-supported format.
Anonymous said…
I replaced the video by a hopefully-better one and also added a video of the mechanism alone.
Thanks, the updated videos are nice to watch. And it's a very interesting implementation - I could see that you could in theory detect the angle of approach to the wall as well. I thought a little bit about your code, and eliminated some of the Switch structures while making it so that one version of code can handle both left and right deflections:
Note that you can "float" a motor by using a Motor block set to stop (no need for zero-force, zero-time Moto blocks), and you can make that overshoot problem (why you need a final Wait block) greatly reduced by using low power on the Motor block.
Position the sensor motor so that an L-block hangs down and sticks out to the front. Then use gears on the top for one side and the bottom for the other of the orange wheel to get CW & CCW rotation from the wiskers. You could put some sort of flex system on the L block or whickers so that one of them only rotates the motor to position A and the others rotate to position B. Then use a timer and position @ time to evaluate whether left or right or center was triggered. I dont know (yet) how to have these wiskers or bumpers rotate the motor when pushed, but give enough that the blocked bumper (position A) would not stop the whole unit. I'm thinking some sort of "knee" that bends only in one direction to allow the L-block to rotate alot when it hits because the wiskers would fold when the gears push them against the frame. But when preasure comes from the whisker the unit does not flex.
Anyways - this should free up a touch sensor.
Theoretically you should be able to use bumpers with different ranges of motion set on a timer to detect bumps from any direction using just the one motor... That's be an engineering night mare but the intelligence and capacity are there.
Or stick an Lblock off one of the arms near the pivot (so that it triggers, left or front&right).
What do you think happens when you set the variable to 1? The arm moves back to the starting point and 1 degree farther.
What if you change the direction of the Motor block and set the variable to 1? The arm now moves 1 degrees forward from its current position.
What if you set the variable to 0? The arm doesn't move at all, no mater what the direction of the Motor block.
It looks like there are three cases: 1) value 0 means no movement 2) Move block in the same direction of current rotation -> add onto that rotation 3) Move block in opposite direction of current rotation -> move to the position specified
Comments
As to the actual challenge, interesting! I need to try to implement your code to see how it works. How much play do you get when returning the "pivot bumper" to its home position (is it reliably set to exactly zero degrees each time, or does it overshoot somewhat?)
One of the reasons I want to implement your code is the crashing of the NXT: check to make sure your batteries weren't low, because if you've found a way to crash the firmware and/or reset the NXT due to just a code issue, it's the first I've heard of it, and I'm *very* interested.
--
Brian Davis
I guess you are right about low batteries being the reason for the reboot. The batteries are low. With the parallel tasks, the NXT needs to run all 3 motors, which probably caused a large enough voltage drop for a reboot.
The reason I didn't suspect this is that with the previous set of batteries, there were on-screen warnings, but not with this set. But it's probably the reason. I'll try the program with parallel tasks and fresh batteries.
With respect to the overshooting: it returns to the home position accuractly. There is overshooting, but if you leave the motor in the brake state for long enough, it eventually settles accurately on the home position. I think that a feedback mechanism in the firmware does this.
The video works fine on my machine, but I'll try to reproduce another with hopefully a better-supported format.
http://www.brickshelf.com/gallery/brdavis/NXT/NXT-G/pivotbumper.png
Note that you can "float" a motor by using a Motor block set to stop (no need for zero-force, zero-time Moto blocks), and you can make that overshoot problem (why you need a final Wait block) greatly reduced by using low power on the Motor block.
--
Brian Davis
Position the sensor motor so that an L-block hangs down and sticks out to the front. Then use gears on the top for one side and the bottom for the other of the orange wheel to get CW & CCW rotation from the wiskers. You could put some sort of flex system on the L block or whickers so that one of them only rotates the motor to position A and the others rotate to position B. Then use a timer and position @ time to evaluate whether left or right or center was triggered. I dont know (yet) how to have these wiskers or bumpers rotate the motor when pushed, but give enough that the blocked bumper (position A) would not stop the whole unit. I'm thinking some sort of "knee" that bends only in one direction to allow the L-block to rotate alot when it hits because the wiskers would fold when the gears push them against the frame. But when preasure comes from the whisker the unit does not flex.
Anyways - this should free up a touch sensor.
Theoretically you should be able to use bumpers with different ranges of motion set on a timer to detect bumps from any direction using just the one motor... That's be an engineering night mare but the intelligence and capacity are there.
Or stick an Lblock off one of the arms near the pivot (so that it triggers, left or front&right).
Look at the following code.
What do you think happens when you set the variable to 1? The arm moves back to the starting point and 1 degree farther.
What if you change the direction of the Motor block and set the variable to 1? The arm now moves 1 degrees forward from its current position.
What if you set the variable to 0? The arm doesn't move at all, no mater what the direction of the Motor block.
It looks like there are three cases:
1) value 0 means no movement
2) Move block in the same direction of current rotation -> add onto that rotation
3) Move block in opposite direction of current rotation -> move to the position specified
Can anyone explain why it is like this?