"Squaring" robot
 

Hello -

I've ran into a little bit of a roadblock. We've got two rangefinders - One on the left and one on the right of our robot. I am trying to read the values of both of them, and if the difference between them is not within an acceptable, predefined distance, move the drive motors accordingly to "square" the robot with the nearest wall.

Now, I've confirmed that the two Rangefinders are working, as I have a numeric readout within Teleop.vi. I've written this code into Pereodic.vi within a Flat Sequence Structure which is triggered by a joystick button press. Here's the odd part...If the rangefinders are within the difference defined, the sequence continues on to the next frame. However, if the rangefinders are NOT within the defined difference, nothing happens.

Any help/suggestions? Thanks.

EDIT - I attached a picture of the code in question. Anyone need it in a .vi?

Re: "Squaring" robot
 

You might need to add the VI - it's hard to read your wiring.

I do see a potential conflict. You have cases for:

• One greater than another
• Both within 5 of each other
• One less than the other

However, it is possible to be in more than one case simultaneously. If A is 2 greater than B, you'll trigger the first case and the second case. In the first case you set motor values of of .1*, in the second case you set motor values of 0.

The robot will dutifully apply both, so you'll rapidly be switching between some power and no power. This could stop your robot from moving at all.


*On a side note, many robots won't even move unless the motor powers are ~.3 or even .4 depending on robot weight, friction in the drive train, trying to turn, etc. Try ramping up the power temporarily to make sure that isn't the problem.

Re: "Squaring" robot
 

One way to make these conflicts more visible is by only having one "Drive" block at the very end that is always excuted, and have all this logic beforehand to determine what the inputs will be. That will ensure you never hit a scenario where two areas are trying to set different motor speeds.

That kind of layout also tends to make is easier to probe and figure out where the logic is going wrong.

Re: "Squaring" robot
 

I've rewritten the code in a very minimal fashion, trying to make it as clear as possible while removing all superfluous actions.

I believe this should work. It's within a bunch of other code which runs every 20ms. Will I need to add a delay within the While loop?

When the rangefinders are within 5 to -5 inches of each other, I want to set all motor outputs to 0. How might I do that other than what I've got in this new image?

Thanks.

Re: "Squaring" robot
 

I've got all my electronics mounted modularly on a board, and have no motors hooked up to the Jags. I'm just supplying arbitrary values and looking for a signal indicator on the Jags. (Flashing red/green)

Re: "Squaring" robot
 

Another quick rewrite. It's a bit different now, so I'll include the VI and a picture.

Re: "Squaring" robot
 

Attached are some simplified examples (didn't create the sensors, just made some variables for distance) that show what I mean.

Each case structure can "interrupt" the one before it, with the last one having priority. In this example, the last case structure is the "In Range" detection that keeps you from moving if you're centered enough.


*Some other small notes:
-It's better to get the references to motors/sensors once outside the loop and use them many times inside the loop. Calling into the refnum registry can be expensive if you're doing it all the time.
-Where does this code live? You said it's inside some other VI.

Re: "Squaring" robot
 

Ah, I see. Quite a clever way of working out the problem! I'll see if I can't implement it within my code.

This code is within Pereodic Tasks.vi, being run every 20ms. Am I able to place a Refnum Name outside of a while loop within Pereodic Tasks.vi and still have it work?

Re: "Squaring" robot
 

That code doesn't do what was described.

Let me describe what it does.

It compares and subtracts two range sensors. If the difference is more than 5, it starts a loop that never ends -- the loop termination is guaranteed to be False wired to the Stop terminal. Inside that infinite loop, it sets the steering repeatedly to the same value with a small delay of 1ms. The motor controllers will only update every 5ms (Jags) or 20ms (Vics) by the way.

Equivalent code is something more like this ...

It only sets the value once to either 0.1 and -0.1, the opposite, or in the True frame it sets it to 0 and 0.

Greg McKaskle

Re: "Squaring" robot
 

@Greg - I don't know what I thought I was going to accomplish with my first version of this code, it obviously didn't work! That can get really frustrating, really fast :p

I've created a piece of code very similar to what JohnGilb suggested, and I believe his code fits my physical needs best. I'll test it tomorrow and hope for the best.

Re: "Squaring" robot
 

It is all about the learning. Good job putting your work out there, and asking questions. This gives you, and many other lurkers, the ability to see several different solutions to the problem and understand the issues more thoroughly.

Good luck.
Greg McKaskle

Re: "Squaring" robot
 

Unfortunately, I had some problems today.

I placed an object in front of the left and right rangefinders at a difference which was within the tolerance written into the code. (5 inches in either direction), and the code would continue on to the next frame within the Flat Sequence.

However, once I placed it at a difference outside the tolerance, the code would pause (not move on to the next frame), and would not send values to any of our speed controllers.

I highlighted the execution to see what was wrong, and it appeared as if it was sending the motor output values I requested.

Any tips? Need a copy of the complete VI?

Dom