• (disco) in reply to another_sam

    The Isuzu Shuriken.

  • (disco) in reply to another_sam

    Compare and contrast with "rapid energetic spontaneous disassembly of the critical assembly", please.

  • (disco) in reply to ScholRLEA
    ScholRLEA:
    Compare and contrast with "rapid energetic spontaneous disassembly of the critical assembly", please.

    That's quite wordy, not so much imagery. I do like that "critical assembly" associates in my mind with "critical mass" in the nuclear physics sense, meaning your energetic disassembly might indeed be extremely energetic and, like the tiny flying circular saw blades, probably not something I want to be around.

  • (disco)

    Has nobody pointed out that the clamp() is pointless, since we've already asserted that parPosition is within range?

  • (disco) in reply to mott555

    In Thailand, food vendors using a lot of oil (like deep fried food) can sale used oil for half the price of new oil, making a nice side income.

    That used oil being then treated to be mixed in bio Diesel.

  • (disco) in reply to mott555
    mott555:
    Diesels can run on anything that's oily and not solvent-y (like gasoline).

    Fun fact: some of the most carcinogenic substances known to man are found in diesel exhaust.

  • (disco) in reply to another_sam
    another_sam:
    high-speed circular saw blades flying through the air
    [image]
  • (disco) in reply to Luhmann

    Saw blade, coming through!

  • (disco) in reply to dkf

    It beats making your crowbar dirty

  • (disco) in reply to ScottJ

    I suppose that vaeAssertRelease is a function that "asserts" in the sense of "issue a warning if the constraints aren't met", not in the sense of "exit the function / halt the process if they're not met".

    (Btw, vae is Latin for woe)

  • (disco) in reply to Steve_The_Cynic

    Yeah, the Therac-25 immediately popped into my mind when I read that article. The detailed paper is quite an interesting read for the WTF connoisseur.

  • (disco) in reply to Gurth
    Gurth:
    Steve_The_Cynic:
    this person was immensely distressed when his car ejected the fan from the engine compartment through the (closed) hood.
    Why? He wouldn’t have much to fear from it, given that the engine fan in a car tends to be mounted vertically :)
    Um, because it was his car and now (a) there was significant damage inside the engine compartment (that had caused the fan to depart) and (b) there was an unscheduled slot in the hood.
  • (disco) in reply to Yazeran
    Yazeran:
    Well was it me, I would have been annoyed that I didn't get it on video :smile:
    Well, this would have been back in the early-to-mid 1980s, when videoing everything wasn't quite as common as it is today. But yes, I'd agree with that as well.
  • (disco) in reply to ScholRLEA
    ScholRLEA:
    Compare and contrast with "rapid energetic spontaneous disassembly of the critical assembly", please.
    SL-1?
  • (disco) in reply to george_gonzalez

    Did you call OSHA or its functional equivalent?

  • (disco) in reply to Steve_The_Cynic
    Steve_The_Cynic:
    You just need to let the hardware designers express the paranoia they should automatically feel when someone says, "the software can take care of that."

    And you need the software developers express similar level of paranoia they should automatically feel when someone says “the hardware cannot be damaged by out-of-limits inputs”. Because, you know, hardware can have bugs too. Worse, hardware can fail due to wear and failure of something that only acts as protection may easily go unnoticed.

    Yes, critical hardware should have hardware protection from invalid inputs, but the software still should have protection from giving them.

    … of course the hardware executing the software is another thing that might have bugs. And bugs at every level have to be guarded against. So then a complete system is something like pair of boards, with different chipsets, running the same logic implemented by two separate teams and cross-checking their results, with the whole thing being duplicated, or triplicated. And then the logic is split over several such systems and each validates the data from the other components…

    Protoman:
    TR :wtf: is not checking for integer overflow in such critical software:

    Yes, they do. If max_pos < min_pos (which is the symptom of overflow), then parPosition >= min_pos and parPosition <= max_pos cannot be satisfied, because x ≤ max_pos < min_pos ≤ x → x < x and that can't ever be.

  • (disco) in reply to another_sam
    another_sam:
    Steve_The_Cynic:
    charming phrases like "uncontained turbine failure"

    This brings to mind lovely images of tiny high-speed circular saw blades flying through the air. Sounds like something straight out of a B-grade horror movie.

    Unfortunately, what it usually means is chunks of jet engine sprayed in all directions. The casings are supposed to be strong enough (and have enough Kevlar) to keep this junk inside, but this protection doesn't always work, and the escaped pieces do all sorts of interesting (for NTSB-related definitions of "interesting") things to aircraft. And sometimes *directly* to people in those aircraft. (Directly as opposed to indirectly by causing the aircraft to crash.)
  • (disco) in reply to Steve_The_Cynic

    Ah, so he was distressed by the thought of how much he would have to pay to get the damage fixed, and not by the fan itself as it came tearing through the car’s sheet metal panels? Sounds about right for modern people, yeah.

  • (disco) in reply to Steve_The_Cynic
    Steve_The_Cynic:
    ScholRLEA:
    Compare and contrast with "rapid energetic spontaneous disassembly of the critical assembly", please.
    SL-1?
    Good guess, actually. As it happens, while the phrase 'energetic disassembly' was first used to describe the explosion inside the TMI-2 reactor, this is a formal description of a nuclear weapon detonation, 'critical assembly' being the term for the process of 'assembling' the fissile material into supercriticality.
  • (disco) in reply to Gurth
    Gurth:
    Sounds about right for modern people, yeah.

    :giggity:

    Or for us: Fuck the billion bucks damage - as long as none of my code appears on this site!

  • (disco) in reply to ScholRLEA
    ScholRLEA:
    Good guess, actually. As it happens, while the phrase 'energetic disassembly' was first used to describe the explosion inside the TMI-2 reactor, this is a formal description of a nuclear weapon detonation, 'critical assembly' being the term for the process of 'assembling' the fissile material into supercriticality.
    I'd argue that the word "spontaneous" doesn't belong in the description of a weapon.
  • (disco) in reply to Steve_The_Cynic
    Steve_The_Cynic:
    I'd argue that the word "spontaneous" doesn't belong in the description of a weapon

    +1'd this. It would be much better to have a "spontaneous money generator". On the one hand, you get money unexpectedly, like those gifts you expect your online buddies to Mystery Gift you every day. On the two hand, it forces you to budget and not rely on the money generated. On the third hand, Get a job moron! There isn't enough lawn for you to fall on!

  • (disco) in reply to Steve_The_Cynic
    Steve_The_Cynic:
    I'd argue that the word "spontaneous" doesn't belong in the description of a weapon.
    Good point, I may have been wrong on that; it may be the term for a pre-detonation (where energetic fission takes place before the critical assembly is complete, leading to a fizzle), or for an accidental detonation. I'm pretty sure it would be the latter, thinking about it, but I'm not sure.
  • (disco) in reply to mott555

    Hm, didn't know they had it on big engines that far back. TIL.

  • (disco) in reply to another_sam

    You only get to do that a couple of times before the valves heading down hit the pistons heading up...

    Of course, that will drastically limit the engine speed.

  • (disco) in reply to Bulb

    "And you need the software developers express similar level of paranoia they should automatically feel when someone says “the hardware cannot be damaged by out-of-limits inputs”. "

    And on hearing that the first thing I'm going to do is pick a few control inputs and drive them stop-to-stop a few times, rapidly, to see what happens.

  • (disco) in reply to gordonjcp
    gordonjcp:
    You only get to do that a couple of times before the valves heading down hit the pistons heading up...

    How far do the valves actually bounce? I've never known. Anyway, they'll only hit the pistons on an interference engine. Usually when people experience valve bounce they back off pretty quickly. It's unnerving if you're not expecting it.

  • (disco) in reply to Tsaukpaetra
    Tsaukpaetra:
    It would be much better to have a "spontaneous money generator". On the one hand, you get money unexpectedly, like those gifts you expect your online buddies to Mystery Gift you every day. On the two hand, it forces you to budget and not rely on the money generated. On the third hand, Get a job moron! There isn't enough lawn for you to fall on!
    And then you'd get audited by your local tax authorities and investigated by the police, who would probably suspect you of dealing drugs. And might in some locations be able to confiscate all the money, as well as any of your assets that they think might have been paid for (even in part) with the suspect money.
  • (disco) in reply to Scarlet_Manuka
    Scarlet_Manuka:
    audited by your local tax authorities and investigated by the police

    So long as you couldn't provide proof of license for the device. Is there a patent for it yet? Someone's had to submit one...

  • (disco)

    Today at work I read something from a car manufacturer that claims to be one of the best ones of the world that they forbid to hand over cars delivered the previous or this week before they've got a software update because otherwise the car could suffer damage.

    Failsafe hardware seems to be unaffordable.

  • (disco) in reply to PWolff
    PWolff:
    Today at work I read something from a car manufacturer (that claims to be one of the best ones of the world) that they forbidrefuse to hand over cars delivered within the previous week or this week before they've gotreceived a software update, because otherwise the car could suffer damage.

    Wow, my context parsing really stumbled over this sentence; several times actually. So here's my interpreted version. ... FTFY?

  • (disco) in reply to Tsaukpaetra

    The manufacturer started a new production line last week. The first cars are already delivered to the retailers, others are on their ways. But the manufacturer forbids the retailers to give the cars to the clients (the final buyers of the car).

    I think my text serializer needs some debugging.

  • (disco) in reply to PWolff

    I did eventually understand it, I just required multiple passes before the rasterization completed into a usable picture. :stuck_out_tongue_winking_eye:

  • (disco) in reply to Tsaukpaetra
    Tsaukpaetra:
    Wow, my context parsing really stumbled over this sentence; several times actually. So here's my interpreted version....FTFY?

    Thanks, I was having a rough time understanding his post. Your effort saved me a spot of trouble.

  • (disco) in reply to Steve_The_Cynic
    Steve_The_Cynic:
    Seriously, never, ever rely on software to protect hardware.

    First of all, the hardware protection usually happens in firmware, which is just built-in software. Someone had to write it.

    And secondly, if you have a robot with 2 or more arms with overlapping ranges, or even 1 arm if its joints provide sufficient range of motion, how can you ensure, in the hardware, that no 2 parts of the robot can ever try to occupy the same region of space at the same exact time? That has to be done in software.

    ScottJ:
    Has nobody pointed out that the clamp() is pointless, since we've already asserted that parPosition is within range?

    Assertions could be disabled, in which case the assert is a no-op and you need the clamp.

  • (disco) in reply to anotherusername
    anotherusername:
    how can you ensure, in the hardware, that no 2 parts of the robot can ever try to occupy the same region of space at the same exact time?

    well... for the single arm case that's just a matter of using some sort of physical interlock to restrict range of motion to one joint based on the relative positioning of other joints. it would be hella complicated and a right pain in the arse to build and maintain. particularly since you would have to make ti fail safe instead of fail deadly

    you could probably come up with a simmilar arrangement for N arms, but the complexity would rise in a superexponential manner.

  • (disco) in reply to accalia

    Adding a ton more moving parts tends to drastically increase size, cost, and the number of possible points of failure.

  • (disco) in reply to anotherusername
    anotherusername:
    Adding a ton more moving parts tends to drastically increase size, cost, and the number of possible points of failure.

    Natch.

    nevertheless, it is possible. just not practical.

  • (disco) in reply to accalia

    Also, consider that whatever physical interlock system you create to stop the motion must be stronger than the source of the motion. The robot may be capable of moving loads weighing many hundreds or thousands of pounds, and all that force is going to go slam against whatever brakes you built to try to stop it.

  • (disco) in reply to Steve_The_Cynic

    And kids, this is why it's a bad idea to ingest a bird.

  • (disco) in reply to anotherusername
    anotherusername:
    Also, consider that whatever physical interlock system you create to stop the motion must be stronger than the source of the motion. The robot may be capable of moving loads weighing many hundreds or thousands of pounds, and all that force is going to go slam against whatever brakes you built to try to stop it.

    yes, but again that doesn't make it impossible, merely extremely impractical.

  • (disco) in reply to accalia

    The added size of the interlock system, however, can reduce the dexterity of your robot to the point where what you want to do might not be possible, even theoretically. You don't have any materials to build it from that will be strong enough to do what you want to do in the available space you have to do it.

  • (disco) in reply to anotherusername
    anotherusername:
    The added size of the interlock system, however, can reduce the dexterity of your robot to the point where what you want to do might not be possible, even theoretically.

    Tell you what, show me a siutuation where my proposed solution will not work, and where the situation can not be altered so that my proposed solution can work without altering the functional result of the system.

    until then i still see no reason why the physical interlocks are impossible. Merely, as i have said multiple times, merely impractical.

  • (disco) in reply to accalia
    accalia:
    Merely
    accalia:
    merely

    RAWR REDUNDANT @SLOOSE SMASH RAAAAAAAWR.

    Sorry, I'm not sure what all that was about...

  • (disco) in reply to sloosecannon
    sloosecannon:
    RAWR REDUNDANT @SLOOSE SMASH RAAAAAAAWR.

    under the laws of mathematics, yes

    Under the laws of common grammar i was merely, i say, merely being emphatic in my statement.

  • (disco) in reply to accalia
    accalia:
    merely, i say, merely

    *twitch*

  • (disco) in reply to sloosecannon
    sloosecannon:
    *3389dae361af79b04c9c8e7057f60cc6twitch3389dae361af79b04c9c8e7057f60cc6*

    you might want to get that looked at....

    ALSO! BONUS DISCOMARKDOWNBBML BUG! discovered while doctoring your quote for teh lulz

  • (disco) in reply to accalia
    accalia:
    Tell you what, show me a siutuation where my proposed solution will not work, and where the situation can not be altered so that my proposed solution can work without altering the functional result of the system.

    You yourself said "complexity would rise in a superexponential manner". I pointed out already that your complex interlock would also have to be extremely sturdy, and therefore (even if you had the time and money to design it) would take up a lot of extra space. You may not have that space; your robot still has to interact with the rest of the real world, which can't be scaled up in size.

  • (disco) in reply to accalia

    :wtf::wtf::wtf::wtf::wtf::wtf::wtf::wtf::wtf::wtf::wtf::wtf::wtf::wtf::wtf::wtf::wtf::wtf::wtf::wtf::wtf::wtf::wtf::wtf::wtf::wtf: Really?

    EDIT: Oh, you just put that in yourself. I thought we had a regression...

    EDIT EDIT: Wait, what?

    What the holy flying elgiu is that about?

  • (disco) in reply to sloosecannon
    sloosecannon:
    :wtf::wtf::wtf::wtf::wtf::wtf::wtf::wtf::wtf::wtf::wtf::wtf::wtf::wtf::wtf::wtf::wtf::wtf::wtf::wtf::wtf::wtf::wtf::wtf::wtf::wtf: Really?

    apparently so.

    3389dae361af79b04c9c8e7057f60cc6

Leave a comment on “A Hardware Switch”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article