Lighting logic



  • More joy from the inherited project from hell.

    Our current project is basically a trainer for the military to teach people how to drive various vehicles. Tanks, Strykers, MRAPs, and cargo vehicles. It's interesting work, since a full motion platform is involved, as well as functional mock-ups of the vehicle drivers compartments. Hell, for one of the vehicles, it was actually more cost effective for us to buy entire pre-assembled cabs from the manufacturer and pull the dash panels out for use in the trainer, than to make our own!

    Anyway, the simulation runs on multiple computers. A host, a bunch of Image Generators, and an Instructor Operator Station (IOS) system. The IOS can control up to 16 vehicles at a time, and contains it's own graphical representation of the vehicle dash (gauges, annunciator lights, etc) that shows what is actually happening in the cab.

    Of particular interest is the annunciator panel. There are two events published by the vehicle-side simulation, one for the annunciator panel, one for all other dash lights (some of which exist on the panel, some of which do not). Our hardware layer takes those events, converts them to either CAN or J1587 format, and fires them off to the dash panels. The IOS also listens for those events, and turns on the proper bitmaps as needed to indicate the lights on the GUI.

    Except, whereas the hardware component just wants "Hey, is the light on or off?", the IOS wants the actual state of the subsystem. It then does its own logic to determine if the light is on, or off. In fact, even though it receives the 'Dash Lights' event, it ignores the values in there and instead looks for the switch/lever/button state changes directly.

    Why? Why would anyone write code like this? It's turning into a horribly complicated debugging mess.

    Sadly, we've not gotten permission to change it yet, even if it is just for the vehicles we are adding to the simulator. I'm half tempted to just change it so it monitors the actual light event, and then ask for forgiveness if anyone complains. Maybe once I get caught up on my tasks and don't have any, "I know this is last minute, but can you get this done in an hour?" things dropped on me.



  • Switch position, relay positions, and the light actually being on or off are three unique properties.



  • Except in this place, it's not. The message literally contains a list of all lights with either an ON or OFF state. There is no reason to duplicate the logic to determine if it's in that state in both the simulation side and the IOS side. Especially when the IOS is receiving the results of the simulation's output in either ON or OFF terms. It should just use that, as that is going to reflect what the hardware is doing.

    The GUI representation of the dash doesn't actually show switches, just the dash lights and gauges.


  • Discourse touched me in a no-no place

    Never mind that, TRWTF is that you haven't been sued by Apple for the name yet!



  • Maybe a stupid question, but why do you need a simulator to learn how to drive a truck or even tank? Seems like that should be one of those things where you just sit in the thing and practice.



  • @FrostCat said:

    Never mind that, TRWTF is that you haven't been sued by Apple Cisco for the name yet!



  • Trucks, depends on the size. Big trucks are expensive to buy just for learners and expensive to run. Learners are hard on machines, increasing maintenance costs and decreasing service life.

    Tanks are pretty expensive too.



  • I thought US army these days has hundreds of old tanks, trucks and such, that are no longer combat ready and are basically just rotting away.



  • Because with the numbers involved, running simulators, even full-motion ones with all the associated hardware, is cheaper than driving around in real tanks for the same amount of time. Simulators require a building, a bunch of people to run and maintain them, and some electricity; real tanks require large buildings for storage and maintenance, large numbers of people to keep them in running condition, huge amounts of fuel (and possibly ammunition), spare parts, warehouses and transportation for those spare parts, and all sorts of other logistics.

    From this article:

    It costs a lot of money for Soldiers to train on an M1 Abrams tank. Not only does it cost about $67 per mile to operate, but Sabot ammunition rounds cost about $1,175 each, and HEAT rounds cost about $830 each.


  • Ok fair enough.


  • Garbage Person

    And then you need a place to drive around. In a simulator, you can happily stage tank battles in downtown NYC if you really want.

    In actual tanks? Not so much.

    BTW, OP, if you're hiring, this sounds like something I'd enjoy a lot.


  • BINNED

    @Weng said:

    BTW, OP, if you're hiring, this sounds like something I'd enjoy a lot.

    I was going to ask if you were joking, but this does seem to be a step up from your current job.


  • Garbage Person

    No, seriously. Awful code is one thing, but it can be balanced somewhat by subject matter.



  • I don't know about trucks, but you can kill yourself or others in a tank pretty easy if you're not careful.



  • Concern for others, non bunny avatar? Who the Fuck are you, imposter?



  • Fine I switched it back. Anyway, I never wanted people to die-- how would I be able to call them idiots then?

    Also in the process found like 4 bugs with avatar uploads.



  • Only 4?



  • I used fiddler2 the other day to upload avatar A, upload avatar B, upload avatar C then used fiddler to reissue the requests several thousand times in a row, the results were pretty funny too.



  • Yeah, mostly related to what happens when you hit the fake-o "close" box with an upload in progress.

    Hint: not any of the 2 or 3 things you'd expect to happen.



  • Additionally, you can't use regular tanks for people who are just beginning to learn how to drive one.

    Just like the cars for driver's education, the educator has to have the possibility of taking control at any moment and also the ability to see what the trainee is doing.

    That's not possible in a normal tank. I've seen training tanks and they usually have a sort of "tower" atop the actual tank wherein the educator is located.



  • @another_sam said:

    Trucks, depends on the size. Big trucks are expensive to buy just for learners and expensive to run. Learners are hard on machines, increasing maintenance costs and decreasing service life.

    Tanks are pretty expensive too.

    This, and it's also easier to stage 'malfunctions' on a simulator than a tank. For example, the 'low oil pressure' malfunction. You wouldn't want to do this on real hardware, as it tends to be destructive. But in a simulator they can trigger it, the vehicle will respond as it should, and they can grade the trainee on their response to the problem.

    Also, some of these things are dangerous. Look up the Load Handling System on the M1120A4. It's a slick piece of equipment that could kill someone in a darned hurry.

    I will agree, subject matter does tend to help when working on a crappy code base. This one is a mess, it's something like 20 years old, but it's also fun to play around with during 'testing' 😄



  • @FrostCat said:

    Never mind that, TRWTF is that you haven't been sued by Apple for the name yet!

    Haha!

    Actually, considering how old the baseline is, I think we could sue Apple! It's been called an IOS since the 80s!



  • @blakeyrat said:

    Anyway, I never wanted people to die-- how would I be able to call them idiots then?

    "Those dead idiots..." only suggesting.



  • @CodeNinja said:

    it's also easier to stage 'malfunctions' on a simulator
    That might be why they have the stupid double-logic, so that there's a "convenient" extension point for an indicator to be spuriously on (due to a ground fault) or off (due to being burned out). While the vehicle under test obviously should not have that information, the instructor himself/herself might want it.



  • @TwelveBaud said:

    That might be why they have the stupid double-logic, so that there's a "convenient" extension point for an indicator to be spuriously on (due to a ground fault) or off (due to being burned out). While the vehicle under test obviously should not have that information, the instructor himself/herself might want it.

    Maybe that was the plan originally, but there is a whole malfunction pane with little green indicators that turn red when the malfunction is active. The dash lights part is supposed to be a 100% duplicate of what is on the actual hardware dash, which is supposed to be driven by simulation (Not everything is, since the dash panel's internal logic drives some things).



  • @blakeyrat said:

    I don't know about trucks, but you can kill yourself or others in a tank pretty easy if you're not careful.

    I could probably kill myself or others pretty easily in a truck. Heck, some of the methods are probably pretty similar.


Log in to reply