RAIV (Redundant Array of Independent Victors)

[Rapt0r9]

This is an idea I've been kicking around for some time. I am basically using the idea of a RAID 5 and replacing the drives with victors. The idea here is that when a victor fails, and we have had quite a few fail during competitions, the RC will acknowledge this and a spare victor will automatically take over the role of the broken victor. I figure if I use motor voltage sensors to monitor the voltage which each victor is outputting and compare that against the voltage which the victors are supposed to outputting, I can catch a failure in a victor. The only area I am skeptical is with wiring the secondary system of victors which will be acting as the "hot swaps". I am just curious to see what you guys think of this idea.

[Stuart]

the problem would be is you would have to connect multiple vics to a single motor. . . and thats against the rules. good idea though. . . as far as the wiring. not that hard. just connect the V+ pins to the output of a relay, then switch them by controlling relays.

[Tottanka]

It sounds like a great idea, only problem is, like you mentioned, the wiring.
It basicly means that u need to have your spare victors somehow connected to all victors, and when needed replacing only one of them.
I think you'd be better with having 1 spare victor for each indangered victor, though it causes other problems (weight, cost etc..)

[EricVanWyk]

I do like the spirit of this. Perhaps you can get halfway there and implement a system that will do the victor fault detection and report it to the driver. This way you know exactly what to fix before you even get off the field. If you couple this with a well designed electrical layout, you will be sittin happy while the rest of us are panicking.

The real important bit is to tell the difference between a popped breaker and a busted vic.

Good luck!

[Greg Marra]

Originally Posted by EricVanWyk

I do like the spirit of this. Perhaps you can get halfway there and implement a system that will do the victor fault detection and report it to the driver. This way you know exactly what to fix before you even get off the field. If you couple this with a well designed electrical layout, you will be sittin happy while the rest of us are panicking.

Even better, roll it into a custom laptop-based dashboard and don't leave anything up to the driver to figure out. It'd sure help to know when you're dropped a chain vs. lost electrical output to a motor, or when all your victors are non responsive vs not going anywhere in a pushing match...

[MrForbes]

Might also be worth looking into why you are losing victors. Perhaps some minor changes to the robot design, or to maintenance procedures, will eliminate the problem.

I don't recall our team ever losing a victor.

[Kevin Sevcik]

Ditto on our team never or very rarely losing a Victor. But as noted, this isn't legal for at least one very good reason. When a Victor is in brake mode instead of coast mode, it quite literally shorts the leads of the motor together so the motor goes into regenerative braking. So if your spare victor or failed victor is in braking mode, you'll rapidly have two failed victors. And if you make a mistake on whether one is broken and start up the second and they're not perfectly in sync, you could end up with current shorting from one to the other as their duty cycles don't sync up.

EDIT: You won't be able to use spikes like this. Spikes are solid-state "relays" not actual physical relays. So they take a constant 12V and GND on the input side that they need all the time at that polarity to operate properly. Then they just send 12V or GND to M+ and M- as dictated by the digital inputs. If you send a Victor output that isn't full on foward to a spike you'll just make it work weird and jitter if at all, if you're sending voltage in the forward sense. In the backwards sense, you'll probably just fry the poor thing. And wiring in physical relays instead won't be legal either.
In summary, the FIRST wiring rules are there for a reason, and it's almost always to protect your team's significant investment in IFI products.

[EricH]

Having an onboard diagnostic tool to detect when a Victor goes out would be a good idea. The problem would be getting the feedback. I'll leave that to the programmers to figure out.

The problem with swapping in Victors automatically if one goes out (other than the rules--both wiring and cost) is the cost of Victors. It's around $100. For a four-motor drivebase alone, that's $400. And then you need spares to replace the ones that die.

Best solution: find out why you are breaking Victors. An onboard detection system can help with that, but it would be better not to have to use it.

[MrForbes]

They are not that expensive...

http://www.ifirobotics.com/victor-88...r-robots.shtml

[EricVanWyk]

Originally Posted by Kevin Sevcik

EDIT: You won't be able to use spikes like this. Spikes are solid-state "relays" not actual physical relays. So they take a constant 12V and GND on the input side that they need all the time at that polarity to operate properly. Then they just send 12V or GND to M+ and M- as dictated by the digital inputs. If you send a Victor output that isn't full on foward to a spike you'll just make it work weird and jitter if at all, if you're sending voltage in the forward sense. In the backwards sense, you'll probably just fry the poor thing. And wiring in physical relays instead won't be legal either.

I am reasonably certain that the Spikes do use "actual" relays. Can someone verify / deny this for us?

In any case, I do agree that the Spike would make a poor choice of mux for this type of task. I think that the battery terminals also power the logic inside, which basically eliminates this possibility.

Another solution would be to simply wire the Vics in parallel, but control them independently. Keep the backup in high impedance (127), and control the other one. If the primary busts, put it at 127 and control the backup.

Again, none of this is competition legal, but I think it is a very good exercise to think through.

[Tom Bottiglieri]

Why not just design the system so it won't fail?
If you are drawing too much current, draw less.
If you can't draw less, get the heat out of there.

[AdamHeard]

I don't quite understand what is happening here...

He is pondering a pretty cool system that would provide a backup in the case of failure. Now, from what I've seen with my internships in engineering; fail safes and backups are encouraged.

Unfortunately it is against the rules and Victors are pretty reliable if used right... but don't give him a hard time for that.

[MrForbes]

Originally Posted by AdamHeard

I don't quite understand what is happening here...

Good question, I'm just applying the KISS principle, as usual.

I like the idea of using feedback to let you know when there's a problem with a Victor, and I like the idea of redundant systems....BUT....it also looks like (in this case) the problem might be better solved by figuring out why the Victors are failing, and preventing that from happening, as many other teams have done.

Perhaps a better approach to redundancy in this case, would be to redesign the drivetrain so it can still function reasonably well with a burned out Victor. That would provide the desired redundancy while keeping within the rules.

[AdamHeard]

Originally Posted by squirrel

Good question, I'm just applying the KISS principle, as usual.

I like the idea of using feedback to let you know when there's a problem with a Victor, and I like the idea of redundant systems....BUT....it also looks like (in this case) the problem might be better solved by figuring out why the Victors are failing, and preventing that from happening, as many other teams have done.

Perhaps a better approach to redundancy in this case, would be to redesign the drivetrain so it can still function reasonably well with a burned out Victor. That would provide the desired redundancy while keeping within the rules.

I'll agree with you if we are solely talking about a FIRST robot, but if we're talking about the lesson learned and experience gained in FIRST that can be used in the future, I stand by what I originally said.

Either way, I think both are valid points in their own context. And in something as simple (compared to the vehicles professional engineers are making) as a FIRST robot, Tom and yourself are probably right in minimizing the risk of failure rather than building in failsafes.

[EricVanWyk]

Originally Posted by Tom Bottiglieri

Why not just design the system so it won't fail?

Forgive me, but this is possibly the best quote I've read in a very very long time.