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]

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.

[Rapt0r9]

Well, I was considering setting up a relay to select which motor the victor would be assigned to. By using a spike, we can cut the number of victors that we need in half, thus helping to reduce the weight of the robot. The spike can also serve as protection to prevent both victors from outputting voltage to the motor at once.

I was reading up on the dashboard packet structure earlier today and I think that we should defiantly be able to write something that will give the drivers feedback as to why the bot is responding awkwardly. We have always tried to integrate a laptop into our controller to use with dashboard, but we never got around to it.

[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-884-speed-controller-robots.shtml

[Al Skierkiewicz]

Well, I was considering setting up a relay to select which motor the victor would be assigned to. By using a spike, we can cut the number of victors that we need in half, thus helping to reduce the weight of the robot. The spike can also serve as protection to prevent both victors from outputting voltage to the motor at once.

A few things will get in your way on this implementation. The first and foremost, the Spike is only rated for 20 amps. This rating is determined not only by the fuse but by the ratings of the contacts used on the internal relays. If allowed under the rules (and I do not believe under the current rulebook this would be allowed) a stalled FP, or Chalupa motor would turn a Spike into ash in a matter of a few minutes. Certain failure modes of the Victors would produce a dead short on the output, so just wiring in parallel would also cause more harm than good. Finally, custom circuits (i.e. a high current relay) are not allowed, under the rules, to be placed between the Victor and motor nor is a custom circuit allowed to directly control a motor.
Some teams have problems with Victors yet most do not. I could spend a few hours talking about Victor failures but essentially all failures can be reduced to just two causes. 1. Foreign material in the Victor causes internal shorts. Keep metal shavings, gear debris and drill dust out of electronics. 2. Excessive and repeated currents at 100 amps or above caused by drive train design, loose or intermittant elctrical connections, lack of calibration in multimotor systems and improper driving technique. This abuse causes extreme internal heat in the active devices resulting in electrical failure.
I would spend more time trying to deduce which failure mode is causing your Victors to die and correct the problem at the beginning of robot construction. If you have a correctable problem and ignore it, you will reach a point where your backup to the backup will also fail leaving you with a non-functional robot. Murphy says this will occur in the last match on Einstein on Saturday afternoon. I would rather have a functional robot and a medal than three dead Victors.

[Rapt0r9]

In the past we have had problems with cables coming loose from the Victors and Spikes. This has cost us a couple matches and this idea would primarily be in place to prevent this from occurring. It looks like using a spike wouldn't work as Kevin mentioned, but I am still considering using the motor diagnostics, even if it is just for feedback to the drivers.

I was also considering setting up a DPDT switch on the robot and using that to switch the connection of the motor to the victors. Basically the common leads would go to the motor's positive and negative lines and the victors would be connected to the throw leads. The switch can then be actuated by an electrical soleoid which would throw the switch. It is kind of a jimmy rigged relay, but it is a physical relay, so the victors would never be outputting to each other, or to the motor at the same time.

[Al Skierkiewicz]

Again, current rules do not allow custom circuits between the motors and the output of a Victor. Switches must be considered as a custom circuit in my opinion when used in this way. Electrical solenoids are also not allowed under the current rules. I am hoping that this rule will change in the future by having a few solenoids provided as part of the kit.

[MrForbes]

In the past we have had problems with cables coming loose from the Victors and Spikes. This has cost us a couple matches and this idea would primarily be in place to prevent this from occurring.

It seems to me that adding MORE wiring connections is not the best way to solve problems caused by faulty wiring connections.

[EricH]

In the past we have had problems with cables coming loose from the Victors and Spikes. This has cost us a couple matches and this idea would primarily be in place to prevent this from occurring.
It seems to me that adding MORE wiring connections is not the best way to solve problems caused by faulty wiring connections.
I concur. Make sure that your PWMs and power wires are secure. Check before every match if you need to. Come up with some way of securing connections before looking into other methods.

[EricVanWyk]

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.

[EricVanWyk]

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.

[MrForbes]

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]

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.

[artdutra04]

A "smart" electrical system that monitors its status and reports to you which breakers tripped/failed is nothing new.

In fact, it was in the kit of parts for two years (http://www.ifirobotics.com/circuit-breaker-panel.shtml). :)


// Along with the Van Door motors, the IFI Circuit Breaker rounds out my two most missed Kit of Parts items.

[Rapt0r9]

Well, While I think I have an idea of what to do at this point. While it isn't absolutely necessary, it could prevent us from dying in a key match. In the past, we have lost matches, and championships, because of a speed controller's failure.

The redundancy is there to ensure that we have a temporary fix until we take the robot off the field and can trouble shoot the problem.

[Al Skierkiewicz]

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.

The Spikes do use relays in an "H" bridge connection with an addition that allows certain output states that the Victors do not allow. The power input does power the internal logic as well as the relay inputs.

Remember that the Victors use power MOSFETs that have protection diodes built into their design. Trying to drive one into the open output of another may have catastrophic results for both devices.

A simple method for securing the PWM cables for both the Victor and Spike is to make a small bend in the cable and bring it right down to the mounting surface next to the device. Then use a tywrap to secure it in place. The PWM cannot be pulled out without cutting the tywrap. We use punched aluminum for our mounting panels which makes tieing things down very easy and lightweight.

Please remember, that we as mentors sometimes are considering things beyond your individual ideas when we respond. It is never our intention to stifle ideas. In this particular case, your desire for backup is sound, there is just no way to justify this idea under the current rules, the additional weight and space for components and complexity of the design. All of us have had heartbreaking failures due to simple problems. We lost a Championship match once because a pushon crimp connector on the fuse panel popped off. In another match a wire pulled out of a crimp on connector due to an improper crimp. To correct these problems, we now secure all wiring, and solder all connectors (using heatshrink for insulation), check all screws after every match to be sure they are tight and run function tests to make sure everything is working before we send it out. In spite of all of this, Murphy still strikes. In a division title match at Championships, we thought we had forgotten to put a charged battery on the robot only to find out that damage from an earlier collision had caused a dead short in one of our motors. Stuff happens!