Well, here's a movie I haven't yet posted to this blog, that Jim has again hosted for me. DAZLR spins in place to try to locate targets, first "testing" the target with a pair of shots, and if the target doesn't run away (like my kids or cats do), it then advances on the position firing a stream of spheres. Also, if the object is outside the "safe" range, it is ignored (that's actually the reason DAZLR doesn't do an aggressive attack on the first big box; that's what it uses to establish its maximum range). Here's a sample (warning, it's around 7 Mb... yeah, I should have compressed 'em).
DAZLR in action
--
Brian Davis
7 comments:
awesome!!
Nice...
Some observations...
1) Nice use of the empty zamor sphere boxes.
2) I note that the bot rotates past a target and then returns a bit. Can you delve into that some?
3) Why'd it need a push for the second zamor box?
DAZLR rotates past the object so it can try to locate the *center* of the object. It notes the first position it sees the object at, and the last position, and then turns back to a location halfway between these two points to target the object more accurately. Since the US sensor can detect things slightly to either side, this turns out to be important.
For the second box, it didn't need a push: I actually had to dislodge a stuck sphere (the 1st tow "warning shots" on that box never fire because the spheres weren't feeding into the shooters).
Another thing I should mention is why it fires the second volley at the first box (after it knocks it over). The US sensor could still detect the much smaller end of the box that was still "visible" to it, and too close, so it fired again.
As for targets, you should see the thing slice through ranks of minfigs... :-)
--
Brian Davis
Pretty cool. I didn't know the NXT had a speech synthesizer. Can't wait to get mine.
I'm almost certain that wasn't synthesized speech, but was instead a x.WAV file, which is the generic format for any sound file you want to store on the NXT.
Most are going to be short and sweet though... space considerations.
-=-
I figured the rotate past & back thing was some sort of centering algorithm. It's gotten me to thinking about what it would take to mount the sonar to a motor and then use the discovered angle to align the firing mechanism with a target. Generally it would be more efficient (you could sweep the SONAR until you found something in range, versus rotatin the entire chasis). However, it would take an extra motor, one a gingle NXT doesn't have without relying on some sort of mechanical motor splitting device.
SONAR: 1 motor
Mobile platform rotation: 2 motors
Firing Mechanism: 1 motor
So then I think "Maybe make it a stationary turret instead..." Then you can restrict the rotation of the turret to a single motor.
THEN I start to get crazy, where you have two sonar outposts triangulating to a target and feeding the information to an artillery assembly which can change both vertical angle and direction in order to hit a target.
Curses, now I need two more NXT bricks!!!
-=-
So... Can Dazzler detect and accurately hit a single minifig?
You could have a turret with the US sensor on it, but I figured why bother using one of your precious three motors for that, when you can rotate the whole platform? The original intent was for a three-motor system that could locate and range a target, elevating the firing mechanism to a selected angle (one motor to handle both elevation of the launcher and firing the launcher, based on a splitter mechanism). I ended up simplifying because rapid-fire (which implies a large magazine and near-flawless sphere feeding) was simply more fun, and I wanted to stay as close as possible to using just a single NXT kit.
Can it detect a single minifig? Depends on the range I imagine (it's not assembled anymore, although I have plans). As to high-precision targeting, the spheres bounce somewhat and the two lauchers bracket the point that DAZLR points at, so it pretty much hammers an area rather than a point.
--
Brian Davis
Why not offset the sensor 20 degrees ahead of the direction of rotation (and, of course, subtract that from the back rotation). Then you would only need to rotate back if your target was > 20 degrees in FOV.?
if your bot can rotate either direction, you could rig up something that will "flop" the "predicting" sensor to the other side, based on the direction of rotation, no other motor is necessary. Implementation is left as an exercise :)
-paul
Post a Comment