We have a precise (±2cm) indoor navigation system (Indoor “GPS”) that is designed to provide real-time location coordinates for autonomous robots, vehicles.
Basics: You have stationary beacons (not Bluetooth or WiFi) every 10-50 meters. And you trace a mobile beacon on your robot with ±2cm precision. You get the coordinates either directly from the beacon on your robot via USB or UART or SPI or I2C; or you can get data from the central controller - depending on the needs of your system.
Detailed description of the protocol is available.
More information is on marvelmind.com/
I will be happy to provide you with more information, if needed.
The most important is that the system is readily available and you can get it within 5-7 days (shipping time)
The accuracy and precision of system would be degraded by beacon echos from walls and obstructions, just like with GPS. However, a casual glance through the web site did not reveal any discussion of the degradation of performance due to this effect. Can you point us to some?
Reflections from the walls do not have any impact. We took care about this
However, obstructions can impact, of course. The mobile beacon must see at least 3 beacons in order the system to function properly. The solution for this limitation is rather simple - to install more stationary beacons, if there is a chance of obstructions.
:::—)))
How more can we prove? We have posted so many different videos already. Surely, we are preparing additional demos. When they are ready, we will upload them ;–))
Besides, why would the reflections matter? By the time the reflections come, we have made the decision on the distance already. And the coordinates have been calculated )
Reflections have no impact.
Our solution is designed to provide robots with cm-precision coordinates and to be ready to use off the shelf. So it does.
[quote=“Jim Remington”]I simply don’t believe that. Publish the data proving, and the mechanism by which reflections from walls don’t matter.
So far, I’ve seen only unrealistic performance videos, with no test results backing the +/- 2 cm accuracy claim, either. What are you afraid of?[/quote]
I very much liked the “unrealistic performance videos” part. Thank you. We also like how it works now. Well, nearly 3 years of development.
There are quite a few pilots around the world ongoing. Hopefully, soon we will get the permissions to publish some references.
[quote]Hopefully, soon we will get the permissions to publish some references.[/quote]Very interesting admission! I look forward to seeing some actual data, professionally presented.
I can easily think of situations where beacon reflections will arrive before the apparatus has made a decision. For example, suppose you have three line of sight beacons, with a fourth beacon that is much closer than the other three, but for which the direct path is obstructed. A wall or obstacle reflection from that fourth beacon could easily arrive before any of the other three line of sight signals.
Another situation is where there are three beacons and the line of sight of one or more is temporarily blocked, say by a moving human. Reflections from walls could be misconstrued as direct signals.
In fact, there will be many interior situations where it is impossible to guarantee 3 line of sight beacons at all times. By your admission, the system will fail in such cases. How will a robot know when this condition occurs? Or do you simply forbid use of the system in situations where such possibilities exist?
It seems that in these and similar cases, a robot might even run amok.
Exactly these considerations have confounded the GPS system since its inception, and there is no simple solution. You are in the same situation, and there is no denying it.
First of all, thank you very much, Jim, for the intelligent discussion. I like it a lot. Thank you!
Concerning your comments:
This case you are describing is probable. There is a solution for that and that is already implemented:
If we have more than 3 beacons visible - 4 in this case, even if one is obstructed - we can verify the multiple distance triangles on their validity.
We know the distances between stationary beacons in advance, because the map was formed automatically and in advance. The triangle of distances that is calculated using reflected data will not fit into the geometry, when compared with other triangles. It is rather clearly seen and rejected by the algorithm. This is a known and expected and reasonably well solved problem.
When only 3 beacons are available and 1 is blocked, surely the calculated coordinates will be wrong. Solutions:
Provide coverage for than 3 beacons at any point, so blocking of 1 beacon won’t create a problem as described above.
Reject the data by the robot itself based on its inertial system and other sensors (recommended)
Use our own internal time-based filtering (possible, but not recommended). This solution can suit some customers where shadows or the robot is moving. However, it won’t work in static cases
Answering your concerns more broadly:
You can always find the way to trick and confuse the system. For sure you can. Any system.
Our indoor navigation system is designed to provide real data and in real environment. And it does. Practically does.
We don’t aim to substitute or eliminate other sensors on the robot. Rather complement them. Robot must not rely on any single sensory input. Robot must always do cross-correlation between different sensory inputs. And our system is not an exception at all. We are just providing precise location data that is very difficult to get in other ways.
I think we will spend some time and create a demo where a human blocks one of 4 stationary sensors and measured coordinates are not disturbed. Thank you one more time for the hint and the discussion
[quote]In fact, there will be many interior situations where it is impossible to guarantee 3 line of sight beacons at all times. By your admission, the system will fail in such cases. How will a robot know when this condition occurs? Or do you simply forbid use of the system in situations where such possibilities exist?
It seems that in these and similar cases, a robot might even run amok.
Exactly these considerations have confounded the GPS system since its inception, and there is no simple solution. You are in the same situation, and there is no denying it.[/quote]
Sure, if the robot drives under the table or hides somewhere really in the corner or something, the coordinates will be lost. And that is OK. Robot must not rely only on our data. The robot employs other technologies, odometry, inertial. Those system help to find the way out. But as soon as it is out, it need to know where it is, where to go, etc. Without our system the robot will be lost. And we immediately help.
That is exactly what our customers are using it for - for correcting and resetting other existing sensors. Combining the data and making the correlation is the key.
This was an ad-hock demo. It is shown as shot without any editing of any sort.
We just dropped at the shop to see how the robots in real life work. It turned out the robot’s SW development team was in the same building. Thus, we proposed to have an ad-hock demo of our system.
We deployed it in 1 min simply by putting stationary beacons on the shelves. Nothing was planned, or tested, or prepared, or optimized beforehand. We just dropped to the shop, put the beacons on the shelves and put the mobile beacon on the top of the robot and checked how it work in the absolutely unprepared environment.
If you want to convince skeptics, I suggest to put a professional, unbiased summary of the points raised here, a mention of the difficulties one might encounter in a realistic situation and the latter video on your sales web site.
You mentioned several time the phrase “unrealistic videos”… well, it sounds for me as a huge compliment
But which of the videos are unrealistic for you?.. I am just curious. Please, share the link. I can tell exactly the conditions they were shot.
And you are referring to the latter video… which one of those? Or both?
Well, frankly speaking, I don’t see these videos anyhow different than those we already have on our web site. The guys with robot wanted to see how our system would behave in extreme cases of shadow of shelves, etc. Thus, they sent robot far outside of the coverage area (very much on the right, for example; or on the top between shelves, where not beacons are visible at all). Still, since absolute distances were just a few meters, the system handled it pretty well, even when the robot was outside of the planned coverage.
Occasional jitter of the mobile beacon on these video is also very normal. We did not actually spend any time setting up the system, didn’t choose optimal angles for beacons, positions, heights - nothing. We had a couple of minutes to setup and we used them simply by attaching the stationary beacons to the shelves. Shall we had time for some tuning, the videos would be as polished as on our site.
Once again, these video were absolutely raw videos shot not for advertising - just for our own record - and I didn’t plan to show them until today
Concerning your advice to publish, as soon as we have permissions to publish, we will publish results of these and some other real-life deployments.
A human, walking around in a large, completely open space holding a receiver module up high, is not a realistic situation or even a very interesting test of the system.
Careful analysis of the positional repeatability in that situation could constitute a best-case performance baseline.
I see. Well, partially yes and no.
Look at the robot we put the beacon on. It had a mast. We didn’t put it there. It was already before us. Obviously, this was the best place for the mobile beacon. We did not have the opportunity to install stationary beacons on the higher places. All these certainly help.
It is always possible to find the situation when the system won’t work as perfectly as wanted. However, in the real life the most optimal available positions will be used, because the end users also want not to kill the system, but to get maximum possible out of it. Thus, the mobile beacons are recommended to be installed on the top of the robot. Usually, they are. And the robots are usually a size of human plus-minus. So, it is not so unusual to have the environment in real life as in our demo.
The feedback is taken and the interest is understood. We will put more efforts on posting more demos and videos in different setup and environment.
Thank you.
