Mech project

= Mech project =

Background
Mechs are huge mainly bipedal weapons platforms that outperform conventional tanks in mobility and firepower.

Roots of Mechs are in japanese mecha anime, where complex robots are explored in variety of different forms. Ref Macross, Gundam, NGE, etc. Mecha were imported to the West with the strategy board game, Battletech.

Battletech was later implemented as a computer game, first as a board game (ref mechforce) and then as a simulator (ref mechwarrior series). Nowadays Mech games are futuristic war machine simulators.

Idea
Most mechgames have limited immersion; player still uses gamepad, keyboard and/or mouse to do all the operations. This setting was successfully broken by Steel Battallion game on Xbox. The game had it's own dedicated controller, with two joysticks, gear shifter, pedals and plethora of switches and buttons. This gave the game additional depth and immersion. Especially the start of the game, where the player is thrust upon the controls with no instructions what-so-ever.

What we'd like to do is the re-implement a next-generation Steel Battallion experience with available and/or DIY hardware. This page details various devices available or envisioned for this task.

Basic design
Basic idea is to modify a basic desktop computer system to mimic Mech cockpit. Building a real cockpit could be a nice continuation to this project.

Basic setup is:
 * Desktop monitor for main display.
 * Two joysticks, one for each hand.
 * Instruments panel.
 * Speakers for ambient sound.
 * Optional pedals for foot control.
 * Optional headset for voice communications.

Control scheme:
 * Idea of twin joysticks is to keep your hands immersed in the simulation.
 * Force-feedback provides tactile feedback on the events and forces affecting the Mech.
 * Movement and terrain causes Mech to sway.
 * Weapon systems, hits and explosions shake the Mech.
 * Movement:
 * Forward/backward, left joystick front/back.
 * Turning, left joystick turn. (Some mechs/vehicles can't turn while stationary.)
 * Strafing, left joystick left/right. (Some mechs/vehicles can't strafe.)
 * Torso/turret turning, right joystick turn. (Torso/turret turns around on some mechs/tanks.)
 * Torso/turret aiming, right joystick forward/back/left/right.
 * Additional controls:
 * Left joystick throttle dial controls "auto-cruise"; when you lock movement stick you can program it to process forwards.
 * Right joystick throttle dial controls "posture"; higher posture gives most visibility, high posture has best movement speed. Low postures give more stability.  Lowest posture can be used to get up when Mech has fallen down.
 * Panel provides all additional controls, so a keyboard is not required.
 * Optional pedals can handle balance and jump jets.

Left hand should continuously control mech movement. Right hand controls aiming and can be released to operate control panel. (For left-handed pilots the scheme can be reversed.) This means right hand joystick control should be passive enough to be releasable at any moment. Both joysticks should have dedicated lock-button. In addition, panel has general joystick activation switch used to immobilize the mech.

Features
Main power
 * Function: Initial panel activation
 * Implementation: Key switch, (avainkytkin, virtalukko?)
 * Function: Reactor ignition
 * Implementation: Start button, unlocking press button. Optionally lighted.
 * Function: Mobility switch, used to maintain fixed stature, f.ex. to ease targeting. De-activates control joysticks to free hands.
 * Implementation: Locking press button / toggle switch. Optionally red/green lights.

Emergency action
 * Function: Self-destruction
 * Implementation: Unlocking press button with lid.
 * Function: Ejection, evacuate pilot.
 * Implementation: Unlocking press button with lid.
 * Function: Emergency stop (shutdown reactor, prevent catastrofic overheating)
 * Implementation: Industrial emergency-stop button, with lid.

Display
 * Function: Status display
 * Subfunction: Status view, systems damage.
 * Subfunction: Weapons layout view
 * Subfunction: Inventory view
 * Subfunction: Mission briefing view
 * Subfunction: Radar view
 * Implementation: Mini display (320x200+ resolution)

Defensive mechanisms
 * Function: Electronic Counter-Measures (ECM)
 * Implementation: Activated with toggle switch, targeted using hat-switch on joystick. LED for status?
 * Function: Point-defensive systems (LASER, LMG)
 * Implementation: Activated with toggle switch, targeted using hat-switch on joystick. LED for status?
 * Function: Flare, IR-lock evasion.
 * Implementation: Unlocking toggle switch to launch, LEDs for stock data?
 * Function: Chaff, radar-lock evasion.
 * Implementation: Unlocking toggle switch to launch, LEDs for stock data?
 * Function: Radio jammer, prevents radio communications. (direct optical links still for communications)
 * Implementation: Toggle switch, LED for status.
 * Function: Active lock warning (radar contact, radar-lock, laser-lock)
 * Implementation: Bank of warning LEDs (light with text?), auditory signals.

Jump jets
 * Function: Provide airborne mobility to Mechs.
 * Implementation: Toggle switch to enable, readiness LED.
 * Implementation: Triggering and controls using pedals? Or joystick?

Clock radio (:-P)
 * Function: Time display, radio channel selection, alarm texts.
 * Implementation: 7-segment LED-display.
 * Implementation: Encoder for channel selection. Few non-locking buttons.  Toggle switch to turn radio on/off.

Joysticks
Joysticks nowadays should be USB-connected, and must have support for right and left handed playing (since you'd always have one joystick on the left and one on the right..) Also, the joystick should preferably have force-feedback.

The best candidate so far is: Saitek Cyborg Evo Force. Supports both hands and has force-feedback. Also quite cheap and widely available.


 * Rapid-fire trigger
 * 5 fire buttons
 * 8-way hat switch
 * 3D twist for rudder control
 * 2 shift buttons
 * 4 base buttons
 * Single spring gimbal mechanism
 * 3 position handle adjustment to suit all hand sizes
 * Single spring action for use with non-Force Feedback games

Audio
There are three channels of audio signalling:
 * 1) Ambient sound, as heard within the cockpit.  This can use regular desktop speakers.
 * 2) Voice communications, used for communications.  This should _not_ use desktop speakers, unless the voice is especially piped through mechs speakers.  Normally the player should have, for example, a dedicated bluetooth headset for voice communications.
 * 3) Low frequency effects channel.  Used to pipe low frequency effects signal to simulate cockpit shaking.

Displays
The most important part of mech user interface is the display. The main screen has to provide view of the world outside the mech, which has to include enough view to both facilitate mech movement and targeting data for the weapons systems.

Basically there are two main philosophies for the main screen display:
 * 1) Provide only the most important data and nothing else.
 * 2) Provide everything, grouped up by the topic.

Most video games go in the middle; trying to provide a lot of data, but are limited by the screen surface area.

The projected view of outside can be small as to reflect that the pilot has limited view of the outside world. Like a WW2 tank. This gives the player some anxiety about being able to monitor surroundings enough. The projected view can be panoramic, as to reflect that everything has been done to provide the pilot with all possible data. Like with EVAs in NGE. This allows maximum data with possibility of overwhelming the player.

Practical options for main display include:
 * Standard monitor. Flat-panels of variable sizes (from 18" to 50") are affordable and straight-forward to mount.
 * Video projector. Projects an image on a surface.  Limitation is that the optical path from projector to the surface must be clear of obstructions.
 * Rear projection, this is the standard way to do it. Screen may be mounted on wall, on tripod or whatever.  Rear projected, projector is on the same side as the picture is on.  Projection material is opaque.
 * Front projection. Projector is on the other side of the screen.  Screen must be freestanding and is somewhat transparent (light must come through it.)

Since video projectors throw the picture out on a surface, it gives opportunities to investigate different surface geometries. Note that to achieve prefect results, the projector should be customized to overcome the differences caused be inequal light paths. Examples of surfaces that can be projected on include parabolic, cylindral or spherical domes

Projection on a non-flat surface causes distortions to the image, which should be handled with pre-distortions. This is not quite easy, since the projections usually are non-linear, and hardware is geared towards linear projections. Two straight-forward ways of doing this are:
 * Fixing projection coordinates with vertex shader, but this may induce artifacts since straight lines are not all that straight fisheye projection. Real fix would require geometry elements to be subdivided based on the location in the projection, which is difficult to realize before projecting the coordinates.
 * Rendering multiple views and combining the results. This is the classical way of doing this.  Requires multiple renderings to texture and one pass to combine textures into a single view.

Links to related sites:
 * Fisheye Quake does software rendering to produce fish-eye rendered views. Does this by rendering multiple views and combining them into a fish-eye projection.
 * jDome, a swedish venture building domes for projection. They seem to ignore material creation side.  Not yet in mass-production.
 * iDOME, university startup, which I guess is based on the excellent research by Paul Bourke.
 * ELPAC, finnish seller of security products, including safety mirrors.
 * A recent dome project, based on blowed acrylic dome.

Plans:
 * Quarter-sphere mirror bought (Riba/Done)
 * FullHD video projector possibly suitable for dome-projection (Riba/Done)
 * Construct miniature version of a dome. (Riba/Bisse/2016?)
 * Find out if local companies in Finland are capable of producing a half-dome. (either fiberglass or acrylic, probably)

Secondary displays
Mech simulations usually have lots of data to be displayed: Status indicators, damage location charts, radar screens, weapon status, ammo stock readouts, etc. To have this information on a separate screen together with the controls gives some extra immersion.

Displays are a lot more complex. Using small laptop or PDA as a display might work ok. Some manufacturers make dedicated displays for flight simulators. These could be reused for mech displays. The displays should be able to handle real-time changes, perhaps starting at few frames per second, for active changes and flashing indicators, etc. This requires an active connection to the computer that's running the game. Either via network (wifi, ethernet), USB (with some sort of fast image switching system) or other dedicated cable.

The main solutions are:
 * 1) Additional display, requires additional display card (or a multi-head display card, most today support at least dual-head) or a USB display card (USB-VGA-style).  This has lots of overhead required to run a complete X11 or framebuffer on the device, but also allows most clean implementation via regular multi-display support.  Multi-head cards may also allow acceleration on the additional display.
 * 2) Picture frame with image upload.  The displays rarely allow access to pictures while the frame is showing them (FAT doesn't allow simultaneous access), so it'd be restricted to non-realtime pictures.
 * 3) Hacked picture frame.  The all the picture frames are embedded systems with a small CPU pushing the pictures to the display and reading them from memorycard/usb/whatever.  By hacking the embedded system, it's possible to extend the functionality to real-time changes.
 * 4) DisplayLink enabled picture frame.  DisplayLink is a USB-technology that integrated USB display card into the display.  Can be used via suitable API, ref libdlo.
 * 5) Dedicated display-device.  These are easiest to control and have solid support, but are usually either text-based modules or expensive.

Links to possible display devices:
 * Philips SPF2017 7" Photoframe, cheap plain photo frame.
 * Transcend Photo Frame T.photo 720, cheap plain photo frame.
 * DoubleSight DS-70U Smart 7” LCD USB Monitor, actual USB-connected LCD monitor.
 * Samsung photoframes seem to support DisplayLink, ref
 * Linux with picture frames: Digital Picture Frames and Linux, Hacking the philips picture frame, Taking the DPF-407 apart, Ceiva Linux hacking
 * LCD4Linux, a project dedicated to interfacing all kinds of LCD status displays to Linux computers.

Other stuff:
 * MPD Cougar Pack, two-pack of buttons, but only plexiglass instead of screens. What a let-down!

VR alternative for cockpit
Virtual Reality (VR) using head-mounted displays (HMD) seem to have risen in popularity due to cellphones bringing down display prices. Cheap consumer devices are expected to hit the market in 2016. A VR headset could replace the actual displays with similar or even better quality. This has naturally few advantages and disadvantages:
 * HMDs have two independent displays, which enables stereo vision. The screen is trivial to make 3D.  This may give some extra immersion.
 * Often criticized drawback of HMDs is the lag in sensing head position and actually drawing the screen to match it. This may get better with higher quality displays (low-latency and higher refresh rate).  Only time will tell.  This effect causes nausea and headaches on some users.
 * Virtual cockpits are trivial to make. It's just software.
 * HMDs block normal sight, meaning you can't actually see your hands on the controls. HMDs try to avoid this by having custom controller devices with position sensors.  The custom controllers are not especially convincing.
 * Augmented Reality (AR), where HMDs just overlay more data on top of normal vision, averts this problem.

Plans:
 * Buy SteamVR [Riba/2016]

Additional controls
Steel Battallion used gear shifter and pedals to simulate mech movement with "car-like" mechanism; you selected a gear and pressed on accelerator to get it moving forward, and pressed brake to stop it.

Gundam P.O.D has two foot pedals that trigger jump and boost, respectively. Jump is vertical jump up with little horizontal movement, while boost is just horizontal movement forwards.

Another option for foot controls are rudder pedals from flight simulators. Ref Saitek rudder pedals.

In addition to basic controls, the user interface should feature "a plethora" of various gimmicks; hooded "missile"-triggers, switches, knobs, displays, etc.

Basic switches are simple to implement as USB HID devices with suitable microcontroller.

Sources:
 * Partco
 * Press buttons with lights
 * Lights with 3mm LEDs
 * Either colored hat + generic LED, a colored LED, or a multicolor LED.
 * Toggle switches
 * Rubber hats
 * Key switches

In general, water-resistant panels are more impressive. Switches and such should be selected to be more impressive, if that doesn't cause too great additional expenses. Though, the whole panel _won't_ be water-resistant, so don't try to test it :-)

Head-tracking
There are some mechanisms to track player head position. This can be used as advanced input mechanism (to trigger view-direction changes based on head movements) or as an 3D immersion technique (calculate head position relative to the screen and adjust rendering of the scene). Both methods have their uses.


 * "TrackIR" head-tracking devices are commercially available, commonly used for view direction changes with flight simulators (for example, IL-2 Sturmovik).
 * Wiimotes have been used to implement similar tricks. The Wiimote has IR-camera that picks few brightest points and reports them.  By attaching something IR-emitting or -reflective to player's head, the head movements can be tracked.
 * FreeTrack, freeware software that does head-tracking with webcams or wiimotes.

Cockpit
Building controls to an actual cockpit frame is the final step towards perfection. Classic mech arcade machines have used impressive cockpits. Most common simulator cockpit is a flight simulator cockpit. This usually includes realistic meters and controls. Cockpit can also simulate G-forces by tilting the cockpit. This is usually an option for high-end simulators.

Cockpit building possibilities:
 * Motion platform, system used to tilt the whole cockpit along with the user.
 * These kinds of mechanisms are quite involving to construct. If the cockpit is large and heavy, it may need hydraulics which are not suitable for hobby projects.
 * DIY Flight Sim Motion Platforms, a hobbyist with several working designs with electric motors.
 * SimProjects.nl, a hobbyist with several designs with electric motors.
 * Mounted surround sound speakers.
 * The audio LFE-channel can be used to "shake" the cockpit.
 * In effect, you mount a huge (in terms of weight) speaker element to your chair. The speaker doesn't need (and works better without) actual speaker cone.  The idea is to use LFE-channel signal to drive a huge weight around.  When this weight is tied to a chair, it transfers the momentum there, thus making the chairbound person feel all the shakes.
 * Buttkicker, a LFE-effect kit.
 * The phenomena is used by products like Bass Shakers (weighed speakers) and Tactile Transducers (linear motors).

All in all, constructing a proper cockpit requires lot of work and will not be considered in the first phases of this project.

Other props
A nice finishing touch for branding purposes would be either a brightly colored jumpsuit for the pilot, something akin to the plugsuits in NGE, or a military-style uniform, with custom insignia. Please note that spandex won't look good on everyone..

Links
References to implementations of Mech games...
 * MechWarrior 2, a classic.
 * Steel Battallion, Xbox mech game with custom controls.
 * Battletech arcade games, networked, cockpit with all goodies.
 * Gundam Panoramic Optical Display (P.O.D), is a networked cockpit with all goodies, with 180 degree panoramic view. Same tech has been used for Star Wars POD also.

Implementations on the web:
 * LinWarrior 3D, open-source mech-sim for Linux. Source available.  Seems quite rudimentary and dead.
 * Coldest, open-source mech combat game. Source available. Dead.
 * glAnts, an Ant Simulation Game. Source available. Dead.
 * Dark Horizons, indie community with freeware game and boardgame, etc.
 * Mech Warfare: Co-op, haven't produced any releases yet.
 * Exteel by NCSoft, free-to-play, items cost.
 * FightWinPrevail, hobbyist FPS, "cross between mechwarrior and quake3".
 * MetalDrift, vehicular combat, not proper mech.
 * MegaMekNet, java-based online strategy mech game.
 * Robotech Lab, a weblog for Macross & Robotech Games.
 * Ukrainian Rumble 2: Heritage, Mechanical FPS with destructible physics (inspired by MechWarrior), nothing much up.
 * Titans of Steel: Warring Suns, a mech combat strategy game, freeware.


 * MekTek, community site.