how can u do indoor navigation if u need geoposition? lat/lng

[sdetweil]

from the readme.. add a sensor

• point - latitude and longitude as GeoPoint;

what if all the sensors are in the same 20x20 room? lat/lng will be the same.
gps doesn't work indoors, and BLE doesn't have location in pre 5.1

I want to get directions from here(phone current location) to a specific beacon there.
no external to the room knowledge, no server,
only phone and beacons.

i have captured the info and good rssi info, and know the topology to get to the target, BUT, until I MOVE I don't know how I am facing the topology.. as ble only gives me 'distance'.. no direction..
until i discover the change in the shape of the triangle (phone to nearest and farthest) I won't know which way I am going...

close your eyes, and try this. walk into an arbitrary room, with unknown layout. phone finds all beacons.

if nearest/farthest get farther away, then i am pointed out of the rectangle.
if one gets smaller, then I 'might' be pointed out of the triangle.
if BOTH get smaller, I am pointed into the triangle.

[GVolosnyh]

Hi, @sdetweil

1. Any local coordinate system can be converted into a geographic one, knowing the coordinates of the binding point (the opposite is also true). One of the points inside the map, the geo-position of which you know, can serve as a binding point for your map.
2. The fifth decimal place for geographic coordinates gives an error of 1.1 meters in local coordinates, which is suitable for the size of your map.
3. For your demo application, you can use the services of our SDK and map creation services. For additional questions please contact us: info@navigine.com

[sdetweil]

Any local coordinate system can be converted into a geographic one, knowing the coordinates of the binding point (the opposite is also true). One of the points inside the map, the geo-position of which you know, can serve as a binding point for your map.

Thanks.. that sounded productive... except.. the only 'point' I have is the phone, and I don't need to be globally accurate, as long as all the points are calculated to the same error. and while I can calculate the other points, I don't have any bearing so those points are useless. as I don't know the spatial orientation of the map to anything real.

an example discovered topology

nfd = nearest to farthest distance (for example)
phone position is "latitude":30.123456789012345,"longitude":-97.43210987654321
i can calculate all the angles and the distance from phone to device (as compared to the reported RRSI)
as I have the distances for all the sides. but that is all I have

[GVolosnyh]

You are correct, but the current version of this library requires an binding point, since all navigation algorithms work in a geographic coordinate system. If you don't know the binding point, make it fake, convert the local coordinate system to geographic and run the algorithm, then convert the output solutions back to the local coordinate system using the gpsToLocal() public method. This hack should solve your problem.

[sdetweil]

I thought about this and tried to accomplish, but I end up at the same point.. the local coordinate system is RELATIVE to where the phone is (0,0) , but.. the orientation of the components, left/right/up/down, would result in different relative locations, and results from the goespatial coordinate translation

i can't see how to get the desired rotation of the phone to match the actual topology.

there are 1000's of different room topologies my application could be deployed in , and the only thing I know is the distances from the phone to the other items. if u rotate the above layout around the phone point (the ONLY potential binding point) the results are completely different.

[GVolosnyh]

Indeed, if you are trying to use the zone navigation algorithm, then it does not take into account your orientation and, in simple words, draws you to the nearest beacon. To work correctly with orientation, we use a particle filter that is exposed using a magnetometer and takes into account the orientation increment using a complementary filter for the prediction stage. As a result, after convergence of the particle filter, taking into account the location topology (usually within about 10 seconds), we get a stable orientation relative to the geographical north. But unfortunately, this algorithm has not yet been published on our github in terms of intellectual property.

[sdetweil]

thanks.. I am interested in your feedback on navigation to BLE beacons.. I have been unable to find a reliable mechanism for determining their location. RSSI is wildly unpredictable and I am unaware of any other approach that is useful.
IOS navigation to the 'nearest' beacon of a particular UUID.. (when multiple of the same are present in the same room)

I have some nice algorithms that work reliably with reliable RSSI, which I don't have.