| |
> 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
|
|
|
