Lame title. I know. Shut it.

I wasn't very busy yesterday and I got to thinking, most robots have one computer (or series of computers) which processes everything. And when the computer fails the robot comes to a halt.

I'm pretty popular with the redundant and bulky idea's, so why not include a second board with the same programs that checks the same data. One would have to split each data feed into two, so each board con process raw data.

But then there's the problem of duplicate boards having the same, duplicated glitches. I think one could work around this by having a second person, or crew, create the code for the second board. In my opinion, the way a program is written doesn't make it incompatible, it's the variables - You can't make a sub-program work for a master program if you aren't using common variables. As long as the two programs use the same number of matching variables then the two variables can be checked.

I am aware that if the two programs reach different values for the same variable, this method pointless. My main idea is that fact that if one board fails (i.e. no value for any, or one, variable) the bot can still march on from the data given by the second program.

This idea is just on paper until I can obtain a second STAMP =/
According to Apple, if it runs off Macintosh it can't possibly have errors ever because OSX is perfect in every way.
Though there is no infamous blue screen of death, I do occasionally get the "Rainbow Pinwheel of Doom." But after Force Quitting an unresponsive application, I'm good to go Very Happy

But the operating system of a robot isn't what I'm getting at here; it's the code and how to incorporate, I suppose, a fail-safe.
So the robot gets a second oppinio on everything? Wouldn't that system only protect it from one single crash? Once one program crashes, it's running off of a single program, so it's now just as vulnerable as anything else.
haha, Apple. What a moron.
jbr wrote:
So the robot gets a second oppinio on everything? Wouldn't that system only protect it from one single crash? Once one program crashes, it's running off of a single program, so it's now just as vulnerable as anything else.


Basically :(

One could add a third & fourth program, the third would do the same work as the first two, and the fourth would decide which answer is most common out of the three - i.e. two lefts and one right, thus go left. I need to give this more thought, but I figured I'd post it for idea's :)
Bad idea, won't work. The AI in a robot doesn't just "solve variables". It literally processes everything from all the inputs and then moves the motors/speaks in response. Granted, those are variables, but it isn't solving them (since there isn't a "correct" answer). Having two systems fighting for control of the robot would be a HUGE hassle and would likely introduce at least 2 orders of magnitude more bugs and problems than it would solve.

Also, if you have a redundant system that takes up more room and consumes more power. If the room for a spare PC is created, then that PC would be put to better use to share the load from the first AI program and not to create conflicting results.

It makes far more sense to simply have a watchdog program monitor the AI one, and in the event of a crash or lock (determined by some arbitrary timeout value), kill the program and restart it.

Of course, the AI program shouldn't crash to begin with, so solving those bugs should be the primary goal, not inventing crazy, rube goldberg style hacks to solve a straightforward problem.
Kllrnohj, for all his negativity, brings up a good point. If you could run very similar (but not identical) programs for the robots behavior in parallel, and each independently draws a conclusion of what to do next in response to an input, you can simply do what the majority of the programs indicate should happen next. Our brains have a similar cascade/majority mechanism.
Yes, he does.

KermMartian wrote:
If you could run very similar (but not identical) programs for the robots behavior in parallel ... Our brains have a similar cascade/majority mechanism.
This is what I was aiming for. I probably didn't make it very clear, though.

My main goal was to creat to boards with different, but similar, programs. The variables those programs come up with get fed to a third board - which I didn't feel was necessary to add in my post(s) - which checks all variables against their counter part. If everything checks out, the wheels turn.
some18kanal0n3 wrote:
Yes, he does.

KermMartian wrote:
If you could run very similar (but not identical) programs for the robots behavior in parallel ... Our brains have a similar cascade/majority mechanism.
This is what I was aiming for. I probably didn't make it very clear, though.

My main goal was to creat to boards with different, but similar, programs. The variables those programs come up with get fed to a third board - which I didn't feel was necessary to add in my post(s) - which checks all variables against their counter part. If everything checks out, the wheels turn.
Indeed, but I'm talking about possibly even larger scale, ten or one hundred threads (CUDA or something similar, of course) that all vote on the next move.
KermMartian wrote:
Indeed, but I'm talking about possibly even larger scale, ten or one hundred threads (CUDA or something similar, of course) that all vote on the next move.


OpenCL of course since its hardware agnostic Wink
some18kanal0n3 wrote:
Yes, he does.

KermMartian wrote:
If you could run very similar (but not identical) programs for the robots behavior in parallel ... Our brains have a similar cascade/majority mechanism.
This is what I was aiming for. I probably didn't make it very clear, though.

My main goal was to creat to boards with different, but similar, programs. The variables those programs come up with get fed to a third board - which I didn't feel was necessary to add in my post(s) - which checks all variables against their counter part. If everything checks out, the wheels turn.


Which just simply doesn't work. Your idea of program redundancy that isn't redundant is simply bad. Its also at least twice the programming work. If you figure at least a year developing the first program, another year would likely solve way more bugs than spending another year developing another slightly different AI and then "checking results". Of course, there isn't any actually way TO check results, so even if you had two slightly different programs, there is no real way to use both at the same time to create redundancy.
Is that why GLaDOS didn't work?
Hahaha. No. GLaDOS, she... She started getting nervous after you escaped.
DShiznit wrote:
Is that why GLaDOS didn't work?


As per the Portal lore, GLaDOS's individual pieces did separate, distinct tasks. That is not the same as what some18kanal0n3 is proposing. I would also challenge your claim that GLaDOS "didn't work" when it very clearly did. It very much was sentient and self-aware, after all Wink
Yeah but her compassion core failed... Anyway I had an idea regarding this. What if you just had one complex and powerful motherboard that handled everything, and a small very simple board that only monitors a simple electrical "heartbeat" sent to it from the main board. When that heartbeat stops or becomes erratic, the second board terminates and restarts the primary one, keeping the machine functioning indefinitely, or until the main board completely fails(at which point the second board would panic and set off an alarm/trigger an auxiliary board/alert maintenance).
DShiznit wrote:
Yeah but her compassion core failed... Anyway I had an idea regarding this. What if you just had one complex and powerful motherboard that handled everything, and a small very simple board that only monitors a simple electrical "heartbeat" sent to it from the main board. When that heartbeat stops or becomes erratic, the second board terminates and restarts the primary one, keeping the machine functioning indefinitely, or until the main board completely fails(at which point the second board would panic and set off an alarm/trigger an auxiliary board/alert maintenance).


What you are describing is called a watchdog. It would only help in the case of a hardlock or crash on the primary system, not on invalid/incorrect results.

Also, having the watchdog simply be another process on the primary system would accomplish the same thing.
Kllrnohj wrote:
Also, having the watchdog simply be another process on the primary system would accomplish the same thing.
The same thing I was saying initially?
some18kanal0n3 wrote:
The same thing I was saying initially?


No. A watchdog simply detects when the program crashes or locks up. Essentially it is the following:


Code:

while true
    pid = run(some_program)
    while (isRunning(pid) && isResponding(pid))
             sleep(100ms)
    kill(pid)


Regardless, it really doesn't help or even do anything unless the AI program frequently crashes. Even then, it is at best a very temporary band-aid, and far from a solution.
True, cause more than likely that bug is going to happen ever after a reboot. Unless it's a memory error, but I doubt that would be a cause since robot programs don't typically store data, but rather process current events.

So any bug would be a coding error and thus repeat every time; unless it was a sensory overload, but the chances of fixing that upon reboot error doesn't have good odd's.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 2
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement