Cluster Basic Complete

Like I said in my last post, I don't think is going to be a large project at all, but I hope I'm wrong.

So far, it has been as I predicted, the coding took me about 2-3 hours or so of actual coding and testing. I spent more time drinking water and talking to a friend online while I did the code then I actually coded, but it is done.

Cluster Basic is, well, basic. It avoids no obstacles, has no graph/grid structure it needs to index into because it has no obstacles, and it's easy enough to understand. The corner state of the box is there to be used, but isn't really used by the Cluster code. Because the Cluster doesn't actually care too much about where it's putting the members at. Because to it, the members are just a number stored in population that it checks against to make sure it has enough force to push with. You do need 2 members to push the box at all, even if 1 could do it by himself by force alone, in order to push in a horizontal or vertical line you require two members.

I'm going to type up a draft of a paper to accompany this project, and get it to the point where it adequately describes Cluster Basic, and put down all my ideas before I start working on Cluster with Obstacles.

New Project: Cluster

Alright, Cluser isn't a very good name so far, but I'll think of a better one. Anyway, the point is to have an object B (that is a box), and a goal point G, and a Cluster C of small workers that move the Box to the Goal by working together to rotate and push the box.

I've just started working on it, even though I did start working on something like it before, although I won't go into detail on it. Anyway, there are a few things I know I'm already going to do.

The box's state can be represented by an array that holds it's position and the amount of movement the box will move next step of the simulation, as well as the mass of the box. Also, if I want, I can create a boolean table that will tell whether a given part of the box is being pushed or not, this can be used by C to determine where to place it's members in order to push it. Makes sense?

Also, the Cluster will determine how to move the box based on the manhatten distance between it and the goal. So most of the time I expect the Box to be moving diagonally toward the goal. I'll create this project without obstacles first, but once I add in obstacles I'll probably move from an array to represent the space that C,B, and G live in to some type of Graph, and then I can start applying path finding algorithms (specfically Dijkstras A* algorithm) to the search space. Either that, or come up with my own way of dealing with it. (Minding that if I did want to use Graphs, obstacles would be nodes with HUGE weights/cost to traverse)

Alright, I've got the main ideas written in my notebook, and next I'll start coding up the classes and functions. I don't think this is going to be a very large project at all. Hopefully I'm wrong!

Runtime Analysis On Turret3D

Since I have yet to decide on another project, I decided to do some runtime analysis on my program. At first, I looked at just the complexity of the overall algorithm, and figured it to be O(n) where n is the max lookahead value for the targeting algorithm, but since that literally took 2 seconds of thinking to do, I decided to figure out the more specific runtime, so I started checking on the complexity of the mathematical operations used within my code. To save myself the effort of typing it all up, and because blogger doesn't support latex embedded math typescripting (I believe), here's a screenshot of part of my paper that I wrote up.

If you do the math, the numbers won't add up quite correctly, the reason for the addition complexity in the actual runtime (the first line in the picture) is because of the boolean checks used to test if the loop should terminate or not.

The runtime is dominated by it's multiplications, as well as it's loop of course. So instead of just O(n) it's O(n * multiplications * trig). But, the addition and boolean constant time operations are negligible really, but they're included for specificity's sake.

I really want to create something involving AI, or using some Genetic Algorithms. But I have yet to figure out exactly what I want to do

Finished and Completed

Well, my 3-dimensional turret program has been finished. And I've even written up an 8 page document detailing the... well, details. It's available in pdf form, and if anyone would like a copy, all you've got to do is send me an email or leave a comment on this blog.

The real question is, what should I make next?

Working

I got my turret working. Or at least, it certainly seems it is working. See here:

The x axis is the x axis from the 3d vectors and the y value are the z height of the objects. Red is an object falling straight down at some position and green is the projectile fired. It seems like what I've done worked. But it doesn't make sense to me yet why.

What I'm confused about is how I fixed my problems I've had before. I changed the z velocity of the projectile to be v*sin(theta) and when calling an update to the projectile, instead of adding the position to the equation of the height I add the velocity instead. Somehow this works, but I do want to look into the mathematics before I do this. I'll update this project one more time if it turns out that this solution is not a fluke. And then start on a new one. I'm thinking of possibly coding up Tic Tac Toe to get my feet wet in some artificial intelligence.

Math, a new plane to work on

Idea given to me by my Math friend Adam

So, as I think I mentioned, I was discussing how to do this with a friend. But until tonight I didn't have too much time to reflect on what he was telling me. He said, not exactly:  use the angle of elevation to make a connecting line between the target and the turret, then use that and the plane of the z axis to create a new axis. Since this is now a 2d problem solve it with newtons laws of motions that take gravity into effect. And kerpow.

Ok he didn't say kerpow. but I'd like to imagine that's what his brain said when it thought all of that up. He's basically a math genius. Anyway though, what I'm now encountering as a difficulty, is how to switch from my ox,oy axes to my original coordinate system. ox corresponds to the line connecting them, so it must be the magnitude of the position vector. As far as converting the y axis of my new axis back, I'm not entirely sure. Although, I have a feeling that the converstion isn't neccesary for going back, only to converting the targets coordinates into the new system. But after that, the angle of elevation + the new angle given to me by my equations should give me the 'real angle' to fire on. And that will give me my velocity vector's z component. (it's x and y are calculated by the angle the turret faces on the XY plane. Anyway, I believe, that the y component of my target will be 0 in the ox,oy axes. Because the line connects both turret and target. And if you look at the drawing above, it's abundantly clear.

now that the details are, once again, possibly worked out. Time to code!

Been a little while

It's been a while since I've updated the running blog on the status of the 3d turret. Right now, I'm still working out a few bugs. But, I should have it figured out as soon as I find the time to do it. I've been very busy with schoolwork unfortunately. Not to mention trying to read library books on computer science before I have to return them. I did think of something today which I thought was worth posting about.

A problem I was running into was that I was measuring the distance traveled by the objects by their magnitude at a given time. This, while telling me if one will get there or not, is nice, but it doesn't actually tell me the difference between the actual distances they're traveling. When the projectile is fired, it travels in an arc of sorts, but the magnitude of it's vector only tells me how far away from the turret it is. Which is not what I want, I can use that information to see if the object is in range or not, but not for the estimation and leading part.

so, this is what I came up with: I'll have a running total for the distance traveled by the objects as oppose to a straight calculation based on it's magnitude. Since this will only introduce 2 more variables, I don't think this will effect the complexity of the algorithm too much either. Which is nice.

My main mistake in not doing this first, was that I was thinking too 2D ish for this 3D problem. But now I should be able to make some more progress!