|
|
| |
Do you need help to spy on someone or something? Are you worried about a
cheating partner or spouse? Find out and catch a cheating partner with facts and
evidence to back it up, do you need help recover lost or stolen passwords, track
and monitor GPS location, etc; for all your spy and hack related services; find
( wizardbrixton at Gmail dot com ) on the internet for help and solution to all
your spy and hack needs, Social media hacks Find them on online using your
desktop or PC via your browsers URL box. They are the best, services rendered is
100% guaranteed to contact them on ( wizardbrixton at Gmail dot com ) on
WhatsApp +1- 80723 40428
|
|
| |
Does the EV3's "Medium Motor" work with the NXT?
-Iain
|
|
| |
In lugnet.robotics.nxt, Iain Hendry wrote:
> Hi all,
> Does any of this make sense? Am I totally overcomplicating what I'm trying to
> do? Surely I can't be the first person to want two or three motors to arrive at
> a destination at the same time. :)
>
> Thanks for any suggestions,
I recently had a MOC where I wanted to do something similar (only 2 axes
though). After spending a little while on it, I gave up, and just moved both
axes at the same speed until both reached their target. Means they usually
arrive at different times, but as it was only a minor part of the program, I
decided that was acceptable. I may go back and revisit at some stage.
ROSCO
|
|
| |
Iain Hendry wrote:
> I figure I need to figure out what the error of each axis is (how far
> it is from the setpoint), and let the motor that moves the furthest
> "drive" the other two as slaves. Divide the error of the other 2
> motors by the error of the "drive" motor and use that with the
> HiTechnic PID block.
That sounds like a sensible solution.
Play well,
Jacob
--
Jacob's LEGO trains:
http://lego.sparre-andersen.dk/Transport/Tog/
|
|
| |
Hi all,
I'm only just now making the transition from RCX to NXT. The power of the new
servos is really something. For years I've "hard-coded" my own servo code to
couple a rotation sensor to a gearmotor to do setpoint-based positioning for
manipulators (pick and place robots). That is to say, I have a task running for
each motor on the RCX, watching it's current position, and a variable (a
setpoint) of where I want the motor to be. If there's a difference, the motor
moves and sets a flag when it's done.
I like to program these "drive" tasks so they run in the background, and my main
loop of code can just be a repetition of:
-Set the positions
-Tell it to go
-Wait for it to get there.
I want to do the same thing with NXT, but I want to go a step further. Let's
say I have a 3-axis cartesian robot. I know where I am (using the rotation
sensor block), and I can set a variable (a setpoint) for each of the 3 axes.
But now I want all 3 axes to move together so they all end up at the same
setpoint at the same time.
I figure I need to figure out what the error of each axis is (how far it is from
the setpoint), and let the motor that moves the furthest "drive" the other two
as slaves. Divide the error of the other 2 motors by the error of the "drive"
motor and use that with the HiTechnic PID block.
Does any of this make sense? Am I totally overcomplicating what I'm trying to
do? Surely I can't be the first person to want two or three motors to arrive at
a destination at the same time. :)
Thanks for any suggestions,
-Iain
|
|
| |
Hi I'm trying to read direct command sent to NXT via Bluetooth (i.e. via
SetOutputState) in a NXC program.
the goal is to remote control an NXT robot with a mobile phone, having the
program direct access to the data sent to the robot.
i.e. I want to know the direction and speed of both motor sent to the robot.
is this possible or maybe I have to use other type of message?
thank you
Cristian
|
|
| |
> you 4 have only 4 NXT
...I meant "you can have only 4 NXT" !!!
Philo
|
|
| |
> I don't know what the numeric limit is, but there is a limit of some sort, as I
> heard that Monster Chess ran into it and the central computer has to continually
> set up and tear down connections to the 32 different pieces, it cannot be in
> constant contact with all of them at once. So the limit has to be less than 32,
> for sure.
>
> I vaguely recall mention of 7? Not sure.
>
> Hopefully Steve H or another MC builder will comment
As far as I know the only limit is that you 4 have only 4 NXT connected together
at one time, one master and three slaves. This explains why the Monster Chess
that contains at least 32 NXT must constantly make and break connections. But
you can have a much higher number of NXT operating in the same room (eg. the
Monster Chess) without problems. There can be many masters talking at the same
time to 3 slaves each. One thing I heard (didn't experiment myself), the
discovery phase can take a VERY long time if there are many BT devices in the
same room. But if the NXT know each other this is not an issue either.
Philo
|
|
| |
In lugnet.robotics.nxt, Larry Pieniazek wrote:
> I vaguely recall mention of 7? Not sure.
Class is over and I'm still wondering why we could not fire up more than 5
bluetooth connections. Actually, these were NXT to NXT connections. The
RaceCar project at nxtprograms.com served as the basis for the RC Bluetooth
connections.
We tried quite a few things to get more than five students on at a time. We
know that when one disconnects, then another can grab the available connection.
We tried using another message box, making the BT connection down the hallway
and far from the classroom, etc.
We made sure firmware versions were the same. We mixed up the NXTs. We made
sure all the NXTs had at least 7.5v, etc. etc.
When I get home, I'm going to write a simple counter and display program and
have it run on as many pairs of NXT (I have 24). I'll report what I find.
|
|
| |
In lugnet.robotics.nxt, Edwin Pilobello wrote:
> I have a class of 10 kids each trying to fire up a remote control via bluetooth
> to their respective robots. Seems there is a limit of 5 connections to a room?
> Can anyone confirm?
I don't know what the numeric limit is, but there is a limit of some sort, as I
heard that Monster Chess ran into it and the central computer has to continually
set up and tear down connections to the 32 different pieces, it cannot be in
constant contact with all of them at once. So the limit has to be less than 32,
for sure.
I vaguely recall mention of 7? Not sure.
Hopefully Steve H or another MC builder will comment
|
|
| |
I have a class of 10 kids each trying to fire up a remote control via bluetooth
to their respective robots. Seems there is a limit of 5 connections to a room?
Can anyone confirm?
|
|
| |
OK, so I'm on my second ever NXT project, and I am wondering if this is even
possible. I have a program that currently has 3 WAIT Blocks, each set to
different lengths of time (4 sec, 2 sec, 1 sec) at different points. What I
want to do, to add more realism, is have that wait time be a random amount of
time between 1 and 5 seconds. The WAIT block, when set to time, seems to have
no method for input. Is there any other way to do this?
Thanks!
Chris Eyerly
|
|
| |
I have both 1.0 and 2.0 NXT sets, and I'd like to have all of the models from
both versions of the software to appear. I thought I could install both and I'd
get both sets of models, but I can't install the 1.0 software- it tells me that
I need at least 256 MB of memory, when I've got 4 GB. Is there some set of
files I can copy over from the disc that will give me the other models?
|
|
| |
In lugnet.mediawatch, John Neal wrote:
Thanks John, that’s really cool. BTW if anyone is having trouble with the page
in that link, try this one instead:
http://www.wired.com/gadgetlab/2010/10/legobot/.
Also added a couple of other groups.
ROSCO
|
|
| |
On 8/28/2010 12:30 PM, Brian Kendig wrote:
> I'm getting back into Mindstorms after a long hiatus. Let me resurrect this old
> thread, to see what the answer is in 2010. :-)
>
> What text-based languages are most mature and best-supported these days for
> programming RCX and NXT? Is RobotC still preferred, are NBC/NXC still the best
> out there, or has another language/environment taken the lead in popularity?
Last year I tried using RobotC on an RCX, and found it to be buggy and
no longer maintained. It worked very well on the NXT, but I was looking
for something affordable that I could use in a classroom environment,
and that made it easy to switch between the RCX and NXT bricks. Cost
was an issue.
I haven't regretted the decision to go with Bricx Command Center -
outstanding support from John Hansen.
-Wayne
|
|
| |
I'm getting back into Mindstorms after a long hiatus. Let me resurrect this old
thread, to see what the answer is in 2010. :-)
What text-based languages are most mature and best-supported these days for
programming RCX and NXT? Is RobotC still preferred, are NBC/NXC still the best
out there, or has another language/environment taken the lead in popularity?
|
|
| |
In lugnet.robotics.nxt, Chris Eyerly wrote:
> I am hoping to build a race timer mechanism using my NXT and
> 4 touch sensors.
I'm not sure how much time you have, or what resources... but you might be able
to do this with a single set. If you put an arm on each motor, such that "track
A" would hit a peg and turn the motor clockwise, but "Track B" would hit a peg
on the other end of the arm, turning that motor counterclockwise. By "watching"
the motor encoders, you could determine when each peg is hit (or at the very
least, which was hit first). With three motors, you could in principle run six
tracks (not that you need to).
Freeing up the sensor ports allows you to actually have a "start timer" as well:
shine a laser across the track so that the movement of any car will break the
light beam, and then reflect that laser off a small mirror to shine in a light
sensor at the finish line. When that beam is broken, the NXT "starts the clock".
Note that the cable length is a real problem here (which is why having such a
"wireless" method, a laser shining the length of the track) is handy.
OK, yeah, probably much more than you needed... but I got curious :).
--
Brian Davis
|
|
| |
In lugnet.robotics.nxt, Kevin L. Clague wrote:
> You might be able to come up with a simpler algorithm, but
> this one should be very reliable.
Well, just for diversity here's a slightly different approach. Make the first
block a "Reset Timer" block, then split the program into four sequences. Each is
simply a "Wait for Touch Sensor", followed by "Read Timer" block with the result
wired into a variable block: "Time1", "Time2", "Time3, or "Time4". after all
these timers are non-zero, just compare them to determine the winner.
You could have each sequence beam display its own time on a certain line on the
LCD "as it happens", which would be fun to watch. Note also that for alternative
implementations of this, four parallel sequence beams might not be needed -
after all, even with four sequences "in parallel", the NXT is really only
watching them one at a time. By using the the "Wait" block you get around this
slightly (the FW is watching the sensors, not your program), but there's always
going to be a sequential evaluation of the sensors... it then becomes a question
of how often the sensors are polled, vs. how close you realistically think the
race is going to be.
--
Brian Davis
|
|
| |
Thanks Kevin! That gives me a good start. once I get some sort of working
model, I'll share with world for some good old fashion criticism.
Chris
|
|
|
