And other arcane mutterings.
After meeting a dead-end in AIMos with the image recognition based on pixels, I realised I'd have to find a way to either make them triangular to use Euclidean math on them, or, find a way to make Euclidean math work on polygons with 4 sides to match the Cartesian geometry of a photo. Digital images are pretty lazy, just a grid of dots with integer dimensions reduced to a list of colours and a width and height.
It isnt immediately obvious but that isnt how a computer handles a pixel on screen because of scalable resolution. Once inside, it has 4 corners with coordinates 0,0 , 1,0 , 1,1 and 0,1 and happens to be square and the right size to fit under a single dot on the display. The display is designed for this, and modern monitors can even upscale less pixels to give a decent approximation of a lower resolution image.
This interpolation, averaging of values, can also be used to reshape an image by getting rid of the pixels completely, which turned out to be the answer to the problem.
Cardware's internal rendering system hybridises Euclidean and Cartesian geometry to produce a bitmesh, which is a resolution-independent representation of a digital image. It cant improve the resolution of the image, so it works underneath it, using several polygons to represent one pixel and never less than one per pixel.
This is achieved by using the original resolution to set the maximal size of the polygons, and then averaging the colours of the underlaying pixels. Then whenever that polygon is reshaped, it maintains the detail contained in it as well as the detail between it and its neighbours independently of the screen grid. Taking the maximum length of the sides and using that as the numeric base for the averaging does this a lot faster than Fourier, even Fast Fourier routines to abstract and resolve the pixel boundaries.
Because the system now has an abstraction of the image, it can be played with so long as the rules of its abstraction are obeyed. Everything is in clockwise order from out to in, or left-to right and down as per writing, and has logical boundaries in the data that obey Cartesian rules. This means I can use Pythagorean maths, but handled like Euclidean triangles with unpolarised angles that are simply relative to each other.
Triangles are unavoidable, but I struck on the idea of making them 4 sided so they handle the same as squares and dont require special consideration. A zero-length side and a zero theta does not interfere with any of the maths I've used so far, and only caused one small problem with an old routine I imported from AIMos. That was easy to write a special case for, and isnt really part of the maths itself, but part of the display routines.
Here's a stalled draw from the Python POC code showing the quality the system can achieve. I was expecting Castle Wolfentstein, but this is going to be more like Halo, near-photographic resolution, and fast too.
The Python that draws this is the calculation routine with pixels obtained from the source map and re-plotted. Once the polymap has been deformed by the mesh and rotated into place those pixels will be polygons and the holes will disappear. The original was 800x600 and takes around 12 seconds to fully render. Once in C++ this will come down to a fraction of a second for a photo quality shell-render of the entire robot, maybe a few frames a second if I'm careful.
Not in a Pi though, so compromises will have to be made...
Yeah I know, walking, I'm not ignoring it.
Actually this maths is all related directly to it as well as the recognition system and the perceptual model I'm trying to build...
OK so now I know where the actual centre of a triangle is without an awful lot of messing around. That's an equilateral and quite easy to calculate, but a right-angled triangle, of which you find two of in a square will give you two centres if you're using rectilinear shapes. To find the centroid of that you'd need to then calculate the angle and distance between them and halve it to get the true centre, and only if its regular. Using this knowledge can test for regularity of a shape though, which Cartesian math cant as easily.
The last shape is irregular, which can easily be determined from the centroid not being on any line.
Obviously, summing the coordinates of the above shapes as triangles, or as rectinlinear shapes makes no difference because Xn + Xn +Xn / 3 is the same as Xn + Xn + Xn + Xn / 4 and the same with the Y coords.
If you happen to have a Z coordinate too, it will find the centroid of a solid object.
Whats the Centroid anyway, and whats it got to do with anything?
Well, if you take a piece of card and cut an equilateral triangle accurately enough, mark the centre accurately enough and give it a bit of a head-start by curving it slightly, it will balance comfortably on the sharp tip of a pencil.
The Centroid of a plane polygon is its centre of balance, and the Centroid of a polyhedron is its centre of gravity.
Extrapolating that, the Centroid of the Centroids of a group of polyhedrons of equal density then, is the centre of balance for the group, and also the system's LaGrange Point for those interested in orbital mechanics.
And its most easily calculated by summing all the vertices in the model and dividing by the number of them summed. Weight distribution, because the mass of the robot is easily calculable, then becomes a ratio based on the Centroid in any plane and is done without even bothering with the angles of the joints, leaving me free to calculate Gimballing without tortuous trigonometry.
Weight distribution can be calculated directly by assigning ratios of unitary weight to the nodes in the mesh, then the true centre of gravity can be calculated using real-world measurements to back-up what sensor data is telling me. The above model would be very hard to calculate without using the meshcount and vertex distribution along with the meta of them being unitary and therefore equal..
The robot is defined as a chain of angles from floor to free foot through the hips, its just a single line, which is easy to hang the vertex list off of, and calculate weight distribution from independently of movement. The shape of the robot, defined by the corner vertices in relation to the centroids defines the robot's perimeter, which in turn defines its volume and therefore mass by relation to its weight, so the physics model for that is unnecessary, in a strange twist of fortune. I'm just guessing at the ratios for the above drawing, but all I have to do is weigh each real part, and because it is symmetrical assume it is of equal density and assign an nth of the weight to each vertex n and that can calculate the centre of balance in one simple equation, without trig.
Even I'm impressed. :-D