To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.robotics.nxtOpen lugnet.robotics.nxt in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 Robotics / NXT / 160
159  |  161
Subject: 
RE: Tacho Limit and Braking
Newsgroups: 
lugnet.robotics.nxt
Date: 
Mon, 2 Oct 2006 20:54:17 GMT
Reply-To: 
<dickswan@sbcglobal.net*stopspam*>
Viewed: 
11953 times
  
John Hansen wrote:

In NBC it is one line of code.

Rotate(OUT_A, 45, 75); // motor port, angle, power

You can do just about anything with one line of code if you count user
subroutine and user macro calls as "one line". The "Rotate" macro in
your example expands to four lines of code that sets up and calls a user
program subroutine that is another 40 lines of code. The RobotC two-line
code example had no calls to user subroutines/macros.


This is incorrect.  There is no "setout" opcode in RobotC.

You're correct on this one. My original note should have indicated "a
'setout' like" opcode rather than simply enclosing setout in parenthesis
which I meant to indicate the same meaning.

Both NXT-G and RobotC firmware use the same I/O Map structure; RobotC
provides a higher and more abstract level of access than the "setout"
opcode which simply twiddles a bunch of I/O Map fields. RobotC's
approach is similar to what you've suggested with "Rotate" subroutine
that masks the complexity from the user.

However, I thought the key point of my original note was the strong
performance provided by RobotC on motor positioning. I've posted some
examples on "youtube" that are referenced below. It would be great if
someone posted a similar video for the NBC "Rotate" performance.



Using NBC you can control your motors however you wish, including
smoothly slowing down and braking precisely at the target encoder
value."

No. I don't think you can.

I think you missed the point -- RobotC does not brake when the target
encoder is reached; it slows, via a PID controller based on distance
from stopping point, the motor in advance to smoothly stop at the target
position. This is the capability that you cannot achieve with current
NXT-G. While it may be possible in NBC, I suspect it will be extremely
"messy" in with an implementation would possibly rewrite portions of the
motor drivers in NBC assembly code.

I tried, but couldn't, to duplicate the following RobotC functionality
in NXT-G code. This code move forward six degrees about every half
second, somewhat like the movement of a minute hand on a mechanical
watch.

while (true)
{
  //
  // Loop continuously moving the motor forward
  //
  nMotorEncoderTarget[motorA] = 6;  // move 6 degrees
  motor[motorA]               = 100;// motor speed
  wait1Msec(500);                   // short delay
}

With NXT-G, the motor was continuously overshooting the target value.

http://www.youtube.com/watch?v=mX48UXrTPuY shows the performance of
RobotC when trying to move 6 degrees forward. It moves six degrees
without any overshoot.

http://www.youtube.com/watch?v=ldUt9HRYNa8 is the best that I was able
to achieve with a NXT-G "motor move" block. The program consists of a
infinite loop containing a MOVE block followed by a WAIT block.

I'm sure there is a large audience of NXT users that would appreciate
sample code for NXT-G or NBC that can duplicate the RobotC performance.
Achieving good motor performance and precise positioning is a lively
topic on the nxtasy.org forums with several currently active threads.

Of course, successfully achieving the above is only a partial solution.
The RobotC solution works equally well whether the distance is "6" or
"600" degrees. And it works equally well for speed "15" and easily as
"100". And it works equally well in single and dual synchronized motor
mode.

If anyone has already solved this with NBC or NXT-G, can they please
post a code example that provides the same kind of smooth movement and
graceful (no overshoot) stopping for all four of the situations --
distance 6 or 600, speed 15 or 100? And can you also post if you try to
solve this challenge and get the same overshoot performance that I
found.

A lack of response might indicate that it is indeed a difficult problem
requiring a little bit more than "one line of code".

And of course the solution should also be general purpose and apply to
"dual motor" synchronization mode.

And, please include in your response an accurate count of lines of code
including the "user" subroutines.



Message is in Reply To:
  Re: Tacho Limit and Braking
 
(...) This is incorrect. There is no "setout" opcode in RobotC. RobotC uses a proprietary commercial alternate firmware with a completely different set of opcodes and virtual machine functionality than the standard NXT firmware. Unfortunately, the (...) (18 years ago, 2-Oct-06, to lugnet.robotics.nxt)

6 Messages in This Thread:


Entire Thread on One Page:
Nested:  All | Brief | Compact | Dots
Linear:  All | Brief | Compact
    

Custom Search

©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR