Commanding an object from a distance > 100m

I would like to control a robot from a distance greater than 100m away. When the object is within 20m, I can simply tell it what to do, but once it's left the area, I have to pray it will come back to me, because I can't talk to it anymore.

One way of doing it is to have it send me its coordinates so that I may go and retrieve it, or send another robot out to relay an instruction on my behalf. It seems ridiculous to have to send a message to my object over a distance via carrier-pigeon. Is there no way to IM the object using built in LSL?

I would appreciate any suggestions that anyone might have to offer.

Thanks.

M.

there are a few ways to do this, using out of world communications like http or xml-rpc, you could use email to the object (if you never plan to change it keys) or you can use strategically placed repeaters, that will repeat your message and the robot can pick it up.

It's interesting because it resembles RL infrastructure that way. I thought about that... and about the fact that I would have to negotiate with landowners to erect repeaters on my behalf. It does make it more interesting than simply having something within the API to do it, but it's certainly not convenient. I was convinced when I set out on this project that I would be able to send IMs to an object much like I am able to received them from an object.

As for the external email or RPC call, I think that's a little heavy for my application - the instructions I wanted to send were more frequent than that - dynamic path information that the object collects and uses in order to navigate.

I think if there were no IM concept at all in the game it would be interesting to set up a cellphone network infrastructure with towers less than 100m apart passing signals around on different channels. But IMs do exist and convenience always wins... BUT WHY NOT FOR OBJECTS? Oh well.

Thanks anyway.

Mendacio, this sounds like something I can help you with.

/invalid_link.html

If you don't need hosting, then we can talk about separate pricing for writing the backend communications script and integrating that with your robot.

Contact me in-world or [email]geuis.teses@gmail.com[/email]

You need an AWACS style blimp to try to float at the half way point between you and your robot! It'll be fun to write, and maybe add to the ambiance. You could have the blimp spawn another blimp when you're getting out of range, but taht wouldn't work in places where you can't create objects. So maybe the way to go is to have 3 blimps (or maybe "n" blimps) that position themselves evenly between yourself and the robot.

If the distance to the robot is D, and the number of blimps is n, then blimp 1's distance is D/(n+1), and blimp 2 is at 2D/(n+1)...

And the blimps could have little antennae with a blinking light...

I had considered this option and it does seem like a fun project. I thought of it as a kite string. Communication would travel up and down the string and be useful at each node in ensuring the string doesn't break. Perhaps I will endeavour to create such a beast. I will let you know.

If it's in-sim, you could use llKey2Name as a sort of communications. It wouldn't actually trigger an event at the other location, but it will allow data transfers.

Good luck with whatever you do!

This has sparked off in my head an interesting set of applications for this concept.

Distance measuring equipment, for example. Send out a stream of little red dots that talk to each other in a chain of command. The dot closest to the source that is also touching another object reports its position, which when subtracted from the position of the source will produce a distance.

Similarly - a directional long distance microphone - same principle: the closest dot to the source that is also touching an object establishes itself as the listener, relaying all channel 0 communications, for example.

There are also applications in robotics - such as, for example, a string of dots in which each dot controls its child dot (in this physical linked-list type arrangement). Commands issued to the first dot are received, interpretted and said dot then issues command to its child dot. The chain of command ultimately reaches the terminating dot and the whole system behaves in some organic fashion.

Interesting stuff.

I don't believe it works inter-sim, but I've been impressed with the
technique of using llRemoteLoadScriptPin as a communications device.
If you know the key, load the script on the target object. It can then send
out a link message that a script already resident on the target could
then act on.

Nifty keen.