search

pombreda / nxt-python

Automatically exported from code.google.com/p/nxt-python
GNU General Public License v3.0
0 stars 0 forks source link

Motor class doesn't have the ability to accurately brake after it moves the specified distance. #2

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Connect a NXT brick
2. Move a motor

What is the expected output? What do you see instead?
The motor moves farther than it should, because it coasts after it goes 
the specified distance. Ideally, it should move the specified distance, 
then brake or coast (whichever the user wants it to do).

Please use labels and text to provide additional information.
The way to do this is the same way the NXT-G "IDE" does it:
1. Go specified distance.
2. Immediately go backwards a bit.
3. Check how for off the motor is from where it should be.
4. Correct the difference.
5. Repeat steps 3 and 4 until it is within about 3-5 degrees of perfect.

I'll be working on this. If anyone already has a program that does the 
same thing, say something!

Original issue reported on code.google.com by marcus@wanners.net on 31 Mar 2009 at 3:12

GoogleCodeExporter commented 9 years ago

Original comment by marcus@wanners.net on 31 Mar 2009 at 3:12

GoogleCodeExporter commented 9 years ago 
Braking is handled automatically by the firmware. All that is needed is a simple
tweak of the command sent to the NXT. See the docs on the NXTreme website for 
details.

Original comment by cwalke...@gmail.com on 28 Aug 2009 at 12:44

GoogleCodeExporter commented 9 years ago 
No, I tried setting the mode to BRAKE, and it didn't stop the motor, it just 
made it 
coast...

Original comment by marcus@wanners.net on 28 Aug 2009 at 10:09

GoogleCodeExporter commented 9 years ago 
Looks like I was incorrect. You managed to get braking working just fine with 
that patch.

I am experimenting with the best way to use the "examples" you provided to 
implement
stopping after a certain distance, and am having much better luck now, thanks :)

Original comment by marcus@wanners.net on 10 Sep 2009 at 2:54

GoogleCodeExporter commented 9 years ago 
The current solution seems to work well enough, though a better one would be 
nice.

Original comment by marcus@wanners.net on 16 Sep 2009 at 1:04

GoogleCodeExporter commented 9 years ago 
There is a brick-based program which will do exactly what we want. It is called
MotorControl and is available (with docs) here:
http://www.mindstorms.rwth-aachen.de/trac/wiki/MotorControl
While I don't have time to implement it right now, I think that it is a good 
idea and
should be experimented with if possible. The current functions of the library 
are
enough to be able to use it in a program, but this may not be the most 
user-friendly
solution.

Original comment by marcus@wanners.net on 13 Jan 2010 at 12:26

GoogleCodeExporter commented 9 years ago 
Just to give an update, there is improved code for this in the tubes for 
version 2.
rhn made it and while I have not tested it, I hear it is better than anything 
so far.

Original comment by marcus@wanners.net on 7 Jun 2010 at 1:06

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
I have tested the v2 motor code and find it to be very accurate (within about 5 
degrees) when using USB and less accurate but still usable (within 60 degrees) 
on bluetooth. As I believe that the performance can't get any better than this, 
I am going to close this issue.

Thanks very much to everyone who helped out with this!

Original comment by marcus@wanners.net on 18 Jul 2010 at 5:12

GoogleCodeExporter commented 9 years ago

Original comment by marcus@wanners.net on 20 Aug 2010 at 2:00

GoogleCodeExporter commented 9 years ago

Original comment by marcus@wanners.net on 6 Feb 2011 at 1:04