 | | | | | | |
| |
|
I ordered mine from Target online. They had a deal for 10% everthing, so with
tax and shipping it still worked out to less than $250. The web site says
delivery for end of July, but I received mine on June 30.
So far have built only the demo Tribot and have been fooling with the
programming to see what can be done. Some things take experimentation as
everything is not fully documented. I need a place to ask questions/discuss
issues. Is this the right forum?
Current questions/observations are:
1) wrote a little program to make the bot twirl in place (one wheel forward
and one back at same time). Is there any real difference in starting one
moter after each other and starting them both in parallel? I can't see one.
2) I changed the prog to start when I clap and keep twriling until I clap
again and then change directions every time I clap. I noticed that the sound
sensor "bounced" like a push switch. I had to wait first for quiet and then
wait for noise before switching.
3) I noticed that motor power is not the same as motor speed. I set power to
1% and the bot would not move (too heavy) but if I picked it up the whells
would turn slow. So then tried to move slow at 100% power by looping many
times of 1 degree movement at 100% power but this was not a smooth motion -
it just jerked along forward. I wonder how to accomplish this.
4) I can't seem to get a parallel processes within a loop. The NXTG software
doesn't let me. Although I can make user block with parallel processes and
then put in a loop.
5) I can already see that I'm going to get tired of the graphical interfact
and will want to use a more normal programming system.
That's it for now.
--
View this message in context: http://www.nabble.com/Have-you-got-your-NXT-yet--tf1861916.html#a5146101
Sent from the LEGO Robotics forum at Nabble.com.
| | | | | | | | | | | | | | |
> 3) I noticed that motor power is not the same as motor speed. I set power to
> 1% and the bot would not move (too heavy) but if I picked it up the whells
> would turn slow. So then tried to move slow at 100% power by looping many
> times of 1 degree movement at 100% power but this was not a smooth motion -
> it just jerked along forward. I wonder how to accomplish this.
If you check "Control: Power Power", the motor speed will be regulated. At very
low power settings (<10) it may be somewhat unstable. This checbox is available
with "Motor" block, not "Move" block.
> 4) I can't seem to get a parallel processes within a loop. The NXTG software
> doesn't let me. Although I can make user block with parallel processes and
> then put in a loop.
Unfortunately, you're right...
Philo
| | | | | | | | | | | | | | | | |
In lugnet.robotics, Philippe Hurbain wrote:
| |
| |
I can’t seem to get a parallel processes within a loop. The
NXTG software doesn’t let me.
|
Unfortunately, you’re right...
|
I’m not so sure. Try the following technique on your copy, in case something
is broken in my version of the editor. To make a parallel sequence, you just
drop an orphan block (one not attached to an existing sequence) and then wire a
sequence beam to it by holding down shift while clicking on an existing sequence
beam to draw out a new one. The catch? Those elastic loops shrink-fit around
the inner code, leaving no “blank” sheet inside the loop to drop the orphan
block. What you need is a “crowbar” (I think Kevin introduced me to the term) to
open up the loop:
Notice the crowbar (I think) needs to be attached to the primary sequence in the
loop. Do all the wiring etc with the crowbar in place (and you could expand the
crowbar still further by dropping things into it), and then when the program is
finished pull out (delete) the crowbar. The loop will shrink to fit when the
crowbar is removed. It may (for several parallel sequences) hide some of the
code. But it will still work. In some cases, you can simple open the datahub of
a Draw block to get enough room to drop a simple second sequence.
Note that this example doesn’t actually do what I thought it would do. I would
have thought that the loop does not wait for the completion of the lower
sequence, but it seems it does. To put it another way, the loop only loops after
*both* sequences within it finish.
--
Brian Davis
| | | | | | | | | | | | | | | | |
| |
Notice the crowbar (I think) needs to be attached to the primary sequence in
the loop. Do all the wiring etc with the crowbar in place (and you could
expand the crowbar still further by dropping things into it), and then when
the program is finished pull out (delete) the crowbar. The loop will shrink
to fit when the crowbar is removed. It may (for several parallel sequences)
hide some of the code. But it will still work. In some cases, you can simple
open the datahub of a Draw block to get enough room to drop a simple second
sequence.
|
Hi Brian,
Indeed, it does work.
But you better not have to add some blocks in front of of a split beam (inside
or outside a loop)!
Philo
| | | | | | | | | | | | | | | | |
In lugnet.robotics, Philippe Hurbain wrote:
| |
But you better not have to add some blocks in front of
a split beam (inside or outside a loop)!
|
With that particular example, it seems I can drop a Sound block in front of
the loop as a whole, or even in front of the original Sound block within the
loop just prior to the sequence beam split. But in general, you’re correct - I’m
doing something here that the editor isn’t really designed to handle nicely, and
a lot of odd and weird behaviors can result if you’re not careful. This is one
of those cases where it’s best to figure out exactly how to structure and draw
the program *before* beginning. And even then, I often delete just about all the
wires to manually re-wire to “force” the programs to look clean to my eye.
--
Brian Davis
| | | | | | |
