An understanding of the Servo-moter control.

[Neffer]

Hi there

I am working on a moving vehicle, with a quite well odemetric, wich controls the robot. Because it is the information from the odemetric that controls the steering and power, it sends commands to the motor-control many times pr second.

First I just used the NXTOutputMulti in a loop, where the only things I want to change, is Steering and Power. I realized, it was only possibly to change the power, as in this example, where i ramp up the motor-power. But, then i tried to wire the TurnRatio, it seems that the NXT only use the first command, and then ignores the rest.

I usually used the "Sync Unlimited"-block from Toolkit, but I do not quite understand the way it works, and i want to optimize it so i uses as few resources as possible.

So:

what's the problem, and whats needs to be done, so it can update Power and TurnRatio very offend?

[BradyDuggan]

You can change the NXTOutputMulti property node to only set the TurnRatio and Power settings. Just right click on the unneeded elements and select "Remove Element". You will also need to wire up the "UpdateFlags" to tell the system what you've updated. You can find enumerated values by digging into things like the "Motor Unlimited" code (although, I'm sure your constant of 7 probably covers it too). You will need to set up the rest of the field at least once.. but you don't need to do it every time you set the motor power.

Removing all the extra range-checking and semaphore code that are in the Sync and Motor subVIs (like you've done here) will definately help out execution speed. Removing RegMode, Mode, and RunState from the property node within the loop probably won't sqweak out that much more performance.

Hope this helps.

Brady Duggan

[Neffer]

Thanks for your replay, and i have try a littel more, to scale down the "Sync Unlimited"-block.

I come to this stage:



But in the last 3 subVI's a lot of things happens, and i am not very sure, what is important, and what is not.
In all of the subVI's, this message can be read:

"In order to interact well with other blocks in the LEGO MINDSTORMS NXT software that access the Output ports, you need to do the following:
Before calling a NXTOutput property node, acquire the semaphores for any ports you'll be using. (PortSemaphore.Acquire.vi)
Check for semaphore requests while your motor control code executes, especially during any waiting loops. (PortSemaphore.CheckRequests.vi)
If a request comes in, release control of the motor and yield the semaphore in a timely manner. (PortSemaphore.Release.vi"

ok... If have understand this right, it means, that with this, multible blocks can have access to the Output-ports.
Is it then possible to scale down the motor-control even more?

Have anybody tried to make your own motorcontrol?

[Neffer]

Sorrey, I was a little too fast, with the last message. I tried to remove the last 3 subVI's and fore my big suprise, it still worked out, so i can't se what was wrong in the first place.
But i think i haved make some mistakes in the numbers.

But the question is still: How important is the last subVI's?

Thanks for help so far 🙂

[BradyDuggan]

Short answer: you can delete the three "thin" looking subVIs ("portsem acquire", "portsem check", "move release"). Unless you are making a block for the NXT-G software, you can basically ignore the motor semaphore stuff.

So the three "thin" looking subVIs all have to do with a semaphore mechanism that controls access to the motors. Since both LabVIEW and NXT-G allow for parallel programming (in fact, make it quite easy to do things in parallel. just drop things that way), you may need to account for two pieces of code wanting to use the same motor ports at the same time.

For example, say you drop two NXT-G "Move" blocks in parallel (use on of the extra sequence wires coming out of the Start block). Lets say the first is configured to go forward 360 degrees and the second is configured to go backward 360 degrees. Say the forward block fired first and turned the motor on forwards, then starts waiting it to reach 360 degrees. Almost immediately afterward, the other block fires and turns the motor on going backwards. Since no one is going to turn the motor on going forwards again, the first block would never finish. The motor semaphore VIs make it so if someone wants to use the same ports as your block, your block will be signaled so that it can abort its execution and yield control to the more recent block. The result is a system where the most recent request wins, and aborts all other motion on that port. Now... that's only if the motor semaphore VIs are used correctly in your block. If you plan on releasing an NXT-G block that controls the motors, please consider using the motor semaphore mechanism within it. The best examples come from the Sync_Time and Motor_Time VIs.

Hope this helps,

Brady Duggan
National Instruments