Chief Delphi

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)
-   Programming (http://www.chiefdelphi.com/forums/forumdisplay.php?f=51)
-   -   RAIV (Redundant Array of Independent Victors) (http://www.chiefdelphi.com/forums/showthread.php?t=59417)

EricVanWyk 04-11-2007 20:03

Re: RAIV (Redundant Array of Independent Victors)
 
Quote:

Originally Posted by Kevin Sevcik (Post 649551)
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 04-11-2007 22:51

Re: RAIV (Redundant Array of Independent Victors)
 
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 04-11-2007 23:08

Re: RAIV (Redundant Array of Independent Victors)
 
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 04-11-2007 23:40

Re: RAIV (Redundant Array of Independent Victors)
 
Quote:

Originally Posted by Tom Bottiglieri (Post 649648)
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 04-11-2007 23:47

Re: RAIV (Redundant Array of Independent Victors)
 
Quote:

Originally Posted by AdamHeard (Post 649651)
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 05-11-2007 01:20

Re: RAIV (Redundant Array of Independent Victors)
 
Quote:

Originally Posted by squirrel (Post 649657)
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 05-11-2007 02:16

Re: RAIV (Redundant Array of Independent Victors)
 
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. :)


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

Rapt0r9 05-11-2007 17:00

Re: RAIV (Redundant Array of Independent Victors)
 
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 06-11-2007 07:51

Re: RAIV (Redundant Array of Independent Victors)
 
Quote:

Originally Posted by EricVanWyk (Post 649624)
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!


All times are GMT -5. The time now is 19:42.

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi