What this VI is intended to do is give a direction and distance to travel, if your robot is at the pixel point “reference” and you want it to go to the pixel point labelled “target”.
The distance part is working fine, but the direction clearly isn’t.
It runs properly, but some part of my math isn’t correct.
Any help would be greatly appreciated; this is part of the control system for telling a robot where to go.
Other stuff I’ve done (mostly working) can be found at http://sotabot.com/robot/programming.html
I don’t understand the units and coordinate system you are using, but you usually want to take atan of y/x instead of x/y. Give that a try.
Another suggestion is to use the atan2 node. Atan can’t give you correct quadrant info all the way around the circle since y/x and (-y)/(-x) look the same as an input. Same for distinguishing (-y)/x and y/(-x). It also helps you keep from flipping them.
Using divisions of 360, seems like it might give degrees. The diagram then computes the angle as the (atan result in radians) * 180/2pi. But to convert to degrees you’d either use 360/2pi or 180/pi. Without understanding the coordinate systems I can’t say for sure this is a bug, but that also looks funny to me.
I’m using pixels in a picture, so I’m dealing with the 4th quadrant with the y axis negated.
And you’re right. It should y÷x (rise÷run). Still doesn’t seem to work, unfortunately.
I might try building a VI to find the closest match to any given real number so that I can use an array for this instead of the atan function.
EDIT:
For simplification (and because at this point I just don’t need 360 divisions), I’m using 24 divisions (every 15 degrees). I might change it to 72 or 360 later.
Setting divisions to 360, I think I was able to get it working the way you want by making the following changes.
Use Atan2.
Drop the conditional amount you are adding, and add div/2 all the time. Let Atan2 do this for you.
Multiply by (div/2)/ pi. Or make sure your units are correct. They seemed to be off by 2x.
The other changes shown in the picture are just to show some other ways of doing things.
You can do math on arrays and clusters. In many cases such, this allows you to have fewer wires and think in terms of points, rects, etc. I added a picture control to hover over to quickly get an easy to control input to the code.
I didn’t use your pythag VI simply because I didn’t have it. I deleted the file stuff to clarify the code.
Also, you can of course use integers if you like, but they are much more error prone, and in many cases aren’t any faster. Similarly, using file I/O to load values rather than compute them will likely be hundreds or thousands of times slower than computing it.
Thanks!
I found that 3/4 * “divisions” should be added to the angle returned (instead of 1/2 * “divisions”), assuming you want zero to be up.
I’m certainly glad using the ATAN function is faster than using an array, however, I’m curios as to why that might be. Is the time-consuming part in the opening of the file, or the recalling of it?
Anyways, thank you! It works now, and I can get on to implementing it. Where would I look to find that mouse pointer control?
The picture control is in the graphs submenu. I drew a rect that included negative numbers and positive numbers, then scrolled it to have zero centered.
The property node for the picture control will easily give the mouse position, or you could use the event structure to get mouse info.
I apologize if these VIs aren’t included in your LabVIEW package (they may only be available in the Full and/or Pro installations). You might want to consider converting your XY Cartesian coordinates to polar coordinates and using LabVIEW’s complex math capabilities (see the attached VI in LabVIEW 8.2 format).
Well, that’s certainly an easy way to do it! It’d also make it simple to do the reverse: place objects the robot sees on the field on this image itself. Thank you!
And yes, I do have the full version, which is part of why I can deal with images in the first place.
I wanted to make a few other points about the VI that I offered for consideration. I made use of a few features in LabVIEW that are super useful. I recognize that other languages have similar features but these really shine in LabVIEW (IMHO).
Polymorphism - almost every VI that NI provides (especially in the various math routines like add/subtract/multiply/divide) support automatic detection of data type with support for a WIDE array of inputs. For example, the “multiply” VI can operate on fixed x fixed, float x fixed, float x float, array x array, array x scalar, cluster x cluster, etc. You might be surprised to learn that almost ANY data type can be multiplied. In my example, I subtracted the two clusters of position directly without needing to unbundle them and wire them separately
Clusters (aka structures in C) - VERY USEFUL!! THESE ARE YOUR FRIENDS!! This is a great way to encapsulate a set of data (including disparate data types)
Thanks to both of you, I was able simplify my robot tracker VI so that it didn’t operate on any subVIs (and most likely operates a lot more efficiently because of that). This “robot tracker” VI simply plots the path of both driven sides of a 10px wide robot. This could be useful in autonomous mode, to tell where on the field the robot is.
