I have to solve a problem with EV3, using language C with ROBOTC.
I am trying to find a ball in the field, grab it and drop in the triangle area.
I'm using a ultrasonic sensor in front of the robot.
My solution for now is:
Turn 360 degrees and find the closest object. After finding the ball, I would like to drop it in the reserved area. That's ok.
The big problem is:
How can I distinct the balls with the triangle area?
After grabbing the ball, I need to drop in the trinagle.
How about the walls? How can I differentiate?
Steps:
Turn 360 and find the closest ball.
Go to the triangle.
Drop it.
Turn 360 and find the closest ball.
And so on.
But with sonic sensor, I can't distinct what's the triangle area and balls.
Can you help me the best way?
It's following the images:
Related
I have a table containing geometrics points (called [Polygon_Centre]) and distances (called [Desired_Radius]). Anybody know which Snowflake function I could use to create polygon circles from this?
I'm trying to achieve a similar result to the Trade Area tool in Alteryx if anybody is familiar with that.
I was hoping for something like the following (which doesn't work):
ST_MAKEPOLYGON('Circle', [Polygon_Centre], [Desired_Radius])
Does anybody know how to create a circle polygon from a given centre point and radius in Snowflake?
Thanks everybody. I've found and used the following solution:
Calculate 120 points around the circle mathematically
Turn this into an ordered list with ST_COLLECT() (the order is critical and the start and end must match)
Use ST_MAKELINE() to turn these points into a line
Create the circle with ST_MAKEPOLYGON().
Given that I know the lat/lng of a person's location, I can find the geohash of where they are. But I want to also find all the geohashes that within their "view".
So if I know the lat/lng and radius, let's say from a google map view, I want to know all of the geohashes that included within that space. I know that I would have to choose a number of units. Let's say 5 units, which I believe is ~3803m per geohash.
Is there an easy way to do this? I could come up with a crude algorithm, but I don't know enough about geohashing to complete each step.
Let's say we're at Buckingham Palace (51.501364, -0.141890), and our "view" has a radius of 1km.
In theory I could do this. Assuming I have a library that can turn lat/lng into a geohash, and vice versa.
Given that we know the center of the map, find the corners (1km NW, 1km NE, 1km SW, 1km SE).
I could then calculate the geohash of top left corner. ADD ~3803m East, calc the geohash. Repeat until the geohash is equal to the geohash of the top right corner.
I could then go down the right side doing the same thing until I reached the bottom left corner. Do the same on the right side. Then fill in the middle, going from the square one below the top left corner, go across until I reach the right side. Back to the left but one block down, and go across again. Back until I finally reach the known bottom right corner.
This may work, I think it would be slow, and not entirely accurate. I'm sure there's an easier way to do this. Does anyone know of a formula or algorithm that could solve this?
Given a lat/lng and radius(R), find all the geohash squares (of an N length), that cover the square who's edges are R meters from the center (lat/lng).
Thanks! Any partial answers or help/formulas working with geohashing would be greatly appreciated!
I'm currently working on a project where I want to draw different mathematical objects onto a 3D cube. It works as it should for Points and Lines given as a vector equation. Now I have a plane given as a parametric equation. This plane can be somewhere in the 3D space and may be visible on the screen, which is this 3D cube. The cube acts as an AABB.
First thing I needed to know was whether the plane intersects with the cube. To do this I made lines who are identical to the edges of this cube and then doing 12 line/plane intersections, calculating whether the line is hit inside the line segment(edge) which is part of the AABB. Doing this I will get a set of Points defining the visible part of the plane in the cube which I have to draw.
I now have up to 6 points A, B, C, D, E and F defining the polygon ABCDEF I would like to draw. To do this I want to split the polygon into triangles for example: ABC, ACD, ADE, AED. I would draw this triangles like described here. The problem I am currently facing is, that I (believe I) need to order the points to get correct triangles and then a correctly drawn polygon. I found out about convex hulls and found QuickHull which works in three dimensional space. There is just one problem with this algorithm: At the beginning I need to create a three dimensional simplex to have a starting point for the algorithm. But as all my points are in the same plane they simply form a two dimensional plane. Thus I think this algorithm won't work.
My question is now: How do I order these 3D points resulting in a polygon that should be a 2D convex hull of these points? And if this is a limitation: I need to do this in C.
Thanks for your help!
One approach is to express the coordinates of the intersection points in the space of the plane, which is 2D, instead of the global 3D space. Depending on how exactly you computed these points, you may already have these (say (U, V)) coordinates. If not, compute two orthonormal vectors that belong to the plane and take the dot products with the (X, Y, Z) intersections. Then you can find the convex hull in 2D.
The 8 corners of the cube can be on either side of the plane, and have a + or - sign when the coordinates are plugged in the implicit equation of the plane (actually the W coordinate of the vertices). This forms a maximum of 2^8=256 configurations (of which not all are possible).
For efficiency, you can solve all these configurations once for all, and for every case list the intersections that form the polygon in the correct order. Then for a given case, compute the 8 sign bits, pack them in a byte and lookup the table of polygons.
Update: direct face construction.
Alternatively, you can proceed by tracking the intersection points from edge to edge.
Start from an edge of the cube known to traverse the plane. This edge belongs to two faces. Choose one arbitrarily. Then the plane cuts this face in a triangle and a pentagon, or two quadrilaterals. Go to the other the intersection with an edge of the face. Take the other face bordered by this new edge. This face is cut in a triangle and a pentagon...
Continuing this process, you will traverse a set of faces and corresponding segments that define the section polygon.
In the figure, you start from the intersection on edge HD, belonging to face DCGH. Then move to the edge GC, also in face CGFB. From there, move to edge FG, also in face EFGH. Move to edge EH, also in face ADHE. And you are back on edge HD.
Complete discussion must take into account the case of the plane through one or more vertices of the cube. (But you can cheat by slightly translating the plane, constructing the intersection polygon and removing the tiny edges that may have been artificially created this way.)
The following problem is an exam exercise I found from an Artificial Intelligence course.
"Suggest a heuristic mechanism that allows this problem to be solved, using the Hill-Climbing algorithm. (S=Start point, F=Final point/goal). No diagonal movement is allowed."
Since it's obvious that Manhattan Distance or Euclidean Distance will send the robot at (3,4) and no backtracking is allowed, what is a possible solution (heuristic mechanism) to this problem?
EDIT: To make the problem clearer, I've marked some of the Manhattan distances on the board:
It would be obvious that, using Manhattan distance, the robot's next move would be at (3,4) since it has a heuristic value of 2 - HC will choose that and get stuck forever. The aim is try and never go that path by finding the proper heuristic algorithm.
I thought of the obstructions as being hot, and that heat rises. I make the net cost of a cell the sum of the Manhattan metric distance to F plus a heat-penalty. Thus there is an attractive force drawing the robot towards F as well as a repelling force which forces it away from the obstructions.
There are two types of heat penalties:
1) It is very bad to touch an obstruction. Look at the 2 or 3 cells neighboring cells in the row immediately below a given cell. Add 15 for every obstruction cell which is directly below the given cell and 10 for every diagonal neighbor which is directly below
2) For cells not in direct contact with the instructions -- the heat is more diffuse. I calculate it as 6 times the average number of obstruction blocks below the cell both in its column and in its neighboring columns.
The following shows the result of combining this all, as well as the path taken from S to F:
A crucial point it the way that the averaging causes the robot to turn left rather than right when it hits the top row. The unheated columns towards the left make that the cooler direction. It is interesting to note how all cells (with the possible exception of the two at the upper-right corner) are drawn to F by this heuristic.
I'm trying to make basic street maps for a game, in C. Each block is represented by a 1 or 0 in an array. In the image, 1 is white, and represents street. Black is zero and represents a building block. The street has to be one block wide everywhere, and you can get from any piece of street to any other piece of street.
I've tried a few quick algorithms but they don't give me variation like in the image. One method I tried was to choose random horizontal and vertical lines, but then I get an uninteresting tartan-type plan.
I tried flipping random bits over the whole image, but then it's messy to verify if all street pieces are reachable, and fixing them if they are not.
My next best guess is to generate random line segments horizontally and vertically, instead of full lines, but then I'm pretty sure that still might generate isolated street pieces.
I could use a genetic algorithm to generate candidates, but I really don't want to go to that trouble if there's a far simpler solution.
Is there an obvious solution I'm not thinking of? The solution should be able to generate the given image, as well as other variations.
Start with a queue with one rectangle in it, the whole map.
Loop: Take a rectangle from the queue.
If the rectangle is small enough, then (with some probability) do nothing and you are done with that rectangle.
Otherwise, pick a long side. Cut that side with a street (modify the array) and add the rectangles on either side to the queue.
There is some flexibility when you decide whether a rectangle is small enough, and how you decide where to cut a rectangle. You can avoid leaving 1x1 squares by not cutting 4x1 or smaller rectangles. You could let there be a chance you keep a 3x5 rectangle, and a chance you cut it.
Create the map by drawing a building in say the upper-lefthand corner. That defines two streets and recurse and build the rest of the map that way.
As a concrete example, let's go with your example where you have a 13x9 grid.
Starting at (1,1) randomly select a building size. Let's say as in your example, I get a 4x2 building. Ok. So now I add streets around that. Then I recurse and create maps for the 4x6 region to the right of that and the region 8x9 grid below. So at first I have:
xx 111111
xx 111111
xx 111111
xx 111111
222222222
222222222
222222222
...
Where "x" marks the location of a building, "" a street. "1" is one region I still need to make a map for. "2" is another region I need to make a map for.
Now let's work on the 4x6 region marked with 1's to the right. At its (1,1) position of that region or absolute position (1,4). I select a 1x2 building randomly. So now after putting a street around that I'd have:
xx xx 3333
xx 3333
xx 44 3333
xx 44 3333
2222222222
2222222222
2222222222
....
And so on. Note that the 2x2 region 4, subdividing further will add a street on added to another street. If you don't want this, then don't subdivide once you get to a region that is 2 or less.
You can check for isolated street peaces, for example, by using DFS (http://en.wikipedia.org/wiki/Depth-first_search). Then, you could connect those pieces by connecting two closest(or any other) points by making segments towards each point.