• As we know, some buildings are made with materials that contain natural radioactive substances.
  
• This is not limited to drywall.  Radioactive materials can be found in the cement used to pour a buildings' floors.
  
• There is no threat at all to the general public from what I found.
  
• Even for people that could be exposed to the radioactivity that I found, levels are well below any level of concern.  They are far below levels in other places where people work/live continuously.
  
• There is some evidence that low doses of ionizing radiation can actually be beneficial. See for example: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6149023/
  In this case, the level of radiation above background could be so low as to not have any effect -- even beneficial.
  

• It shows the advantage of having a continuously wearable device that can alert you to acute radiation dose.
  
• It also clearly illustrates the difference between the Polimaster 1208M's reaction time, and it's sensitivity.  While it did take the Polimaster 1208M nearly 15 minutes to react to the situation I came across, it clearly showed me I was in an area with a higher than background ionizing radiation level.
  
• I'm not saying everyone needs to run out an buy a PM1280M, or drop $2K for an MTM Rad Watch.  I also do not get any sponsorship from any radiation detector vendor. However, I do suggest that people purchase a basic alpha, beta, gamma detector device, and use it to explore anyplace then spend significant time.  This includes homes, hotels, office or work areas, and prospective new homes.
  

• Yoke:
  
  • The Obvious -- Yoke for Roll and Pitch Primary Controls.
    
  • Rudders are not implemented since I have the Thrustmaster T-Rudder, as previously mentioned.
    
  • Left top-hat -- Look Around
    
  • Left PTT button -- Center View
    
  • B -- Parking Brake
    
  • X and Y -- Flaps Up and Down
    
  • Right PTT -- Radio 1 PTT (I do not know if it works)
    
  • No other Axis/Buttons currently assigned.
    
  
  
• Throttle Quadrant:
  
  • Center 2 Throttle Levers -- Engine 1 and Engine 2 throttle
    
  • Pitch Trim Wheel -- Pitch Trim
    
  • Buttons:
    [Mag Inc][Mag Dec][              ]  [              ][Gear U]
    [Starter  ][              ][              ]  [              ][Gear D]
    
  • No other Axis/Buttons currently assigned.
    

• I cut the end off of the included allen wrench for more convenient use. (see prior posts)
  

sudo mv /usr/share/games/flightgear/joysticks.xml /usr/share/games/flightgear/joysticks_bak.xml 

	<js n="0" include="/home/user/.fgfs/Input/Joysticks/Turtle-Beach-VelocityOne-Flight-0.xml"/>
	<js n="1" include="/home/user/.fgfs/Input/Joysticks/Turtle-Beach-VelocityOne-Flight-1.xml"/> 

<?xml version="1.0"?>
<!--
	To override or add "named" joystick drivers list them in
	<js-named> entries with paths relative to the directory where
	the joysticks.xml file resides (first example). Such "named"
	drivers are only picked up if one of their <name>s matches
	the joystick hardware (see output of the js_demo application).
	These drivers have precedence over already existing drivers
	with the same <name>. (You can also add a <name>default</name>
	entry to the driver to make it the default choice.)

	The second example shows how to load a driver directly to
	position 0. This will then be used for the first joystick on
	your system and FlightGear will not overwrite it.
-->

<PropertyList>
<!--
	<js-named include="Input/Joysticks/Local/X45-modified.xml"/>

	<js n="0" include="Input/Joysticks/Local/joystick_0.xml"/>
-->
	<js n="0" include="/home/user/.fgfs/Input/Joysticks/Turtle-Beach-VelocityOne-Flight-0.xml"/>
	<js n="1" include="/home/user/.fgfs/Input/Joysticks/Turtle-Beach-VelocityOne-Flight-1.xml"/>
	<js n="3" include="/home/user/.fgfs/Input/Joysticks/Thrustmaster-T-Rudder.xml"/>
	
</PropertyList> 

• This will disable the built-in FlightGear Joystick editor.  Turtle-Beach-VelocityOne-Flight-0.xml and Turtle-Beach-VelocityOne-Flight-1.xml must be edited manually.  Reference: https://wiki.flightgear.org/Input_device
  
• When the Turtle Beach VelocityOne Flight Control is plugged in, the Yoke always seems to be /dev/input/js0, and the Throttle Quadrant always seems to be /dev/input/js1,  so this should work consistently even though both sections have the same name.  You may need to insure that the VelocityOne Flight Control is plugged in before plugging in other joysticks/rudder pedals if you are using other such devices.
  
• You may want different sets of files for different aircraft you fly.  They can be organized within folders within .fgfs/Input/Joysticks, and then simply copy the .xml files for the particular aircraft to .fgfs/Input/Joysticks/
  
• As mentioned, the right yoke upper hat switch is not supported.  This is not likely to change any time soon.
  
• It seems that the 1st of the 4 throttle levers is not recognized by Linux/jstest-gtk or Flightgear.  This seems to be a firmware issue.  There are only settings for single engine and twin engine in the FMD menus.  In other words, from what I can see, this issue is not limited to Linux/Flightgear.  We can hope this will be fixed in a firmware update from Turtle Beach. Fans of the Boeing 727 or Ford Tri-motor will be relieved to know that 3 throttle levers are useable in Linux/Flightgear.  
  
• Warning/Indicator Lights are not supported. This is not likely to change any time soon.  If you have any information on controlling the lights, please join and post (instructions at the top of these pages.  The color and brightness of the general lighting, and the warning/indicator lights can be controlled via the FMD menus.  
  

• VelocityOne Flight Control is built very well, and generally feels sturdier and nicer than the CH Products yoke.
  
• The Throttle levers are a little "Loose" -- Compared to both just how they should feel as a Human Interface, and Really Loose as compared to the throttles on a actual large aircraft.  There is no way to lock the throttles together.
  
• There is a very light detent for what could either be interpreted as a "Flight Idle" limit, or moving the throttles to "Cutoff". It can't really be used as reverse since there is no movement passed the detent for reverse thrust control.
  
• There are no thrust reversers, or provisions for throttles with thrust reverse levers.  (Note that the both the Thrustmaster TCA Boeing Throttle Quadrant, and the Honeycomb Bravo have thrust reverse levers.)
  The VelocityOne Flight Control comes with a nice, long, fabric covered USB A-to-C cable, (and a C-to-C cable to connect the throttle quadrant.)
  
• The brackets to hold it to a desk, table or other surface are strong, and well designed.  There should be no problem securing the VelocityOne Flight Control to almost anything.  The one stupid thing is the fattened end of the included allen wrench, which prevents it from being used to quickly drive the screws in or out.   I will probably either cut the end off the included allen wrench or get a normal allen wrench of the correct size.
  
• The C-to-C cable included is long enough for the throttle quadrant to be mounted someplace other than onto the yoke.  However, a shorty C-to-C cable would be nice for when it is attached to the yoke --  or better yet, and internal connection between them.
  

Bus 001 Device 015: ID 10f5:7001 Turtle Beach 
Device Descriptor:
  bLength		    18
  bDescriptorType	   1
  bcdUSB		   2.00
  bDeviceClass	    255 Vendor Specific Class
  bDeviceSubClass	  71 
  bDeviceProtocol	 208 
  bMaxPacketSize0	  64
  idVendor	     0x10f5 Turtle Beach
  idProduct	    0x7001 
  bcdDevice	     10.04
  iManufacturer	     1 
  iProduct		    2 
  iSerial		     3 
  bNumConfigurations	1
  Configuration Descriptor:
    bLength		     9
    bDescriptorType	   2
    wTotalLength	 0x0040
    bNumInterfaces	    2
    bConfigurationValue     1
    iConfiguration	    0 
    bmAttributes	   0xa0
	(Bus Powered)
	Remote Wakeup
    MaxPower		  500mA
    Interface Descriptor:
	bLength		     9
	bDescriptorType	   4
	bInterfaceNumber	  0
	bAlternateSetting	 0
	bNumEndpoints	     2
	bInterfaceClass	 255 Vendor Specific Class
	bInterfaceSubClass     71 
	bInterfaceProtocol    208 
	iInterface		  0 
	Endpoint Descriptor:
	  bLength		     7
	  bDescriptorType	   5
	  bEndpointAddress     0x01  EP 1 OUT
	  bmAttributes		3
	    Transfer Type		Interrupt
	    Synch Type		   None
	    Usage Type		   Data
	  wMaxPacketSize     0x0040  1x 64 bytes
	  bInterval		   4
	Endpoint Descriptor:
	  bLength		     7
	  bDescriptorType	   5
	  bEndpointAddress     0x81  EP 1 IN
	  bmAttributes		3
	    Transfer Type		Interrupt
	    Synch Type		   None
	    Usage Type		   Data
	  wMaxPacketSize     0x0040  1x 64 bytes
	  bInterval		   4
    Interface Descriptor:
	bLength		     9
	bDescriptorType	   4
	bInterfaceNumber	  1
	bAlternateSetting	 0
	bNumEndpoints	     0
	bInterfaceClass	 255 Vendor Specific Class
	bInterfaceSubClass     71 
	bInterfaceProtocol    208 
	iInterface		  0 
    Interface Descriptor:
	bLength		     9
	bDescriptorType	   4
	bInterfaceNumber	  1
	bAlternateSetting	 1
	bNumEndpoints	     2
	bInterfaceClass	 255 Vendor Specific Class
	bInterfaceSubClass     71 
	bInterfaceProtocol    208 
	iInterface		  0 
	Endpoint Descriptor:
	  bLength		     7
	  bDescriptorType	   5
	  bEndpointAddress     0x08  EP 8 OUT
	  bmAttributes		1
	    Transfer Type		Isochronous
	    Synch Type		   None
	    Usage Type		   Data
	  wMaxPacketSize     0x00e4  1x 228 bytes
	  bInterval		   1
	Endpoint Descriptor:
	  bLength		     7
	  bDescriptorType	   5
	  bEndpointAddress     0x87  EP 7 IN
	  bmAttributes		1
	    Transfer Type		Isochronous
	    Synch Type		   None
	    Usage Type		   Data
	  wMaxPacketSize     0x0040  1x 64 bytes
	  bInterval		   1
 

Jan  X  HH:MM:SS host kernel: [ 3190.076846] usb 1-1.6: new full-speed USB device number 19 using ehci-pci
Jan  X  HH:MM:SS host kernel: [ 3190.187402] usb 1-1.6: New USB device found, idVendor=10f5, idProduct=7001, bcdDevice=10.04
Jan  X  HH:MM:SS host kernel: [ 3190.187404] usb 1-1.6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jan  X  HH:MM:SS host kernel: [ 3190.187405] usb 1-1.6: Product: VelocityOne Flight
Jan  X  HH:MM:SS host kernel: [ 3190.187405] usb 1-1.6: Manufacturer: Turtle Beach
Jan  X  HH:MM:SS host kernel: [ 3190.187406] usb 1-1.6: SerialNumber: 00000120DE082312
Jan  X  HH:MM:SS host mtp-probe: checking bus 1, device 19: "/sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.6"
Jan  X  HH:MM:SS host mtp-probe: bus: 1, device: 19 was not an MTP device
Jan  X  HH:MM:SS host mtp-probe: checking bus 1, device 19: "/sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.6"
Jan  X  HH:MM:SS host mtp-probe: bus: 1, device: 19 was not an MTP device
 

• While of course I have only tested this with the display I have, I believe what is here should work with boards marked as
  EDT 20-20072,  EDT 20-20072-2, EDT 20-20072-5, EW20400YMY, Winstar WH2004A, Raystar 2004A,  Raystar 2004A-LLH-JSV, RC  QC2004A and others.
  
• The datasheet for the same or compatible device is here.
  
• This is an 8 bit parallel device.  All 8 lines must be used.  There is (apparently) no support for 4 bit mode as with similar 2 line displays.
  
• This pinout is similar but not the same as other similar displays.  In particular, the last 2 pins (pins 15 and 16) are not used and should be left open.
  

Arduino    LCD   Function
GND             1     Ground
5V              2     5.0 VDC LCD Supply
GND             3     Operating voltage for LCD (Contrast Adjustment?)
D12     12      4     RS
GND             5     R/W
D11     11      6     E (Enable)
D2       2      7     DB0
D3       3      8     DB1
D4       4      9     DB2
D5       5      10    DB3
D6       6      11    DB4
D7       7      12    DB5
D8       8      13    DB6
D9       9      14    DB7
15              Vee    - Leave unconnected
16              K      - Leave unconnected
 

#include <LiquidCrystal.h>

LiquidCrystal lcd(12, 11, 2, 3, 4, 5, 6, 7, 8, 9);

void setup() {

lcd.begin(20, 4);
}

void loop() {
 
  lcd.clear();
  lcd.setCursor(0, 0);
  lcd.print("You are ugly");
  lcd.setCursor(0, 1);
  lcd.print("and your mother");
  lcd.setCursor(0, 2);
  lcd.print("dresses you");
  lcd.setCursor(0, 3);
  lcd.print("funny.");
delay(500);
}
 

• Substitute the Access Point Name and the Access Point password in lines 37 and 39.
  
• The IP address of the Navigation Camera (Typically http://192.168.1.1:8080?action=stream) must be inserted in the HTML code in line 118.
  

• As mentioned -- Security issues. See previous post.
  
• If not fixed by another method such as a remote (3rd location) server, the issue of determining the Robot Control IP address could be mitigated by including an LCD or OLED display.  In addition to the Robot Control IP address, Other information could be displayed locally, such as the battery voltage, the remote operators name, or other information to be presented to others at the remote location.
  
• Similarly, the AP name and password are hard-coded.  This should be able to be set by a "helper" at the remote site. This could be implemented by an initial point-to-point WiFi connection, or via a display and a simple possibly detachable keyboard.
  
• There is currently no communication between the Robot Control (Code on the Arduino), and the Router that functions as a web cam.  The Web cam's IP address must be hard coded into the iFrame for video display.  This obviously needs to be fixed.
  
• onmousedown and onmouseup do not support touchscreens adequately.  Code needs to be added to support touchscreen devices.
  
• Navigation via physical keyboard arrow keys would be highly desirable. Code should be added to read physical keyboard input for navigation.
  
• More powerful motors than those supplied with the DOIT Car "Smart Tank" kit should be used.  
  
• Some sort of charging station and connection should be implemented.
  
• It was originally desired that the Robot should provide power to the Tablet.  It is easy to implement via a separate buck converter (on hand), but this has not been added as of this writing.
  

• No IT security is currently implemented. Anyone with access to the network at the robot's location can take control of the robot or view video from the navigation camera.  
  
• The firmware version currently used on the OpenWRT router has known vulnerabilities.  If the remote location's network was opened to the internet as described below, these vulnerabilities could allow an outside attacker to attack the remote network from the inside.
  
• A network connection to the IP address of the robot must be allowed (Open firewall or DMZ).  While this is also an obvious security risk, It can also be used to mitigate the above by letting only the operators IP address (or possibly MAC) to control the robot;  Although since the connection is not encrypted, an attacker could easily determine the address needed to spoof the connection.
  
• Access to the facilities IT infrastructure would be need to either assign a static IP address to both the robot control and video connections, or to determine the assigned (DHCP) IP addresses.  
  
• To implement this properly, a central server (most likely a 3rd location) would need to be set up to mitigate all of the above.  In other words, practical control of the robot would work just like the Teleconferencing software or other IoT (Internet of Things) devices like Thermostats, etc.
  
• In order to explain the need for IT security in commercial products further, consider this.  One may not think that the robot control commands would need to be encrypted or obfuscated assuming that actual control of the robot was secure; But consider this:  Someone accessing the commands used to drive the robot around a given facility would eventually be able to construct a map of that facility -- including where the robot was used frequently -- which could reveal the locations of important things inside that facility.  Commanding should be encrypted and padded.
  
• The chosen Teleconferencing software (and thus it's security/privacy) is not modified or affected by the Robot Control software.  The Teleconferencing software does not utilize or connect through the vulnerable router or the robot control connection. The teleconferencing hardware/software is merely along for the ride.
  
• It is also assumed that "good" WiFi access exists throughout the building or facility where the robot is used.
  

• The Telepresence Robot should allow the operator to communicate with and interact with people at a remote location as if the operator were present at that location.
  
• In other words, it is just like a Zoom, MS Teams, or Google Hangouts/Chat call, but the remote caller can move around from place to place.  Their presence is not fixed to a stationary device, or carried by another person.
  
• As with the Teleconference call, the call is not limited to the same area or "range" of a point-to-point connection.  The Telepresence Robot can be anyplace that there is an adequate internet (WiFi) connection.  This could be in a different building than the operator, or even on a different continent.  It is different than "Radio Control".
  
• The Telepresence Robot should be able to move over types of flooring commonly found in a business environment, including carpet, tile, or bare floors.  The Telepresence Robot should be able to move over discontinuities typically found in such an environment like thresholds or entering/exiting an elevator.  For this implementation, there was no requirement for the Telepresence Robot to navigate steps. It was desired to have some outdoor capabilities such as moving over a surface made of paving stones.  The Telepresence Robot should remain stable on such surfaces, including accessibility ramps.
  
• The caller should be close to eye level with other participants.  This was implemented as a compromise between seated participants and standing participants.
  
• It is assumed that the operator has access to a PC, phone or tablet with internet capability, however the operator may not have the ability or permissions to install special software or an "app".  The robot is controlled via a standard Web Browser. Standard teleconferencing software such as those mentioned above is used for the Audio/visual call.
  

• A retail store operator who is quarantined at home due exposure to a contagion (such as COVID-19) could continue to greet customers at the store entrance, interact with them, and guide them toward the products they wish to purchase.
  
• A hotel employee could guide guests to their room, or answer room service calls while continuing to have a real presence in the hotel lobby.  Guests may be more comfortable having a robot come to their room than an actual human.
  
• A product purchaser could monitor the production (and possibly testing) of a product for procurement at their convenience and without the attendance or possible influence of an employee of the company producing the product.  The purchaser could move within agreed limits to monitor the production or testing process as they choose.
  
• An employee could monitor a process in a hazardous area from a remote (safe) location.  They could move so as to observe the process from different vantage points without needing multiple fixed cameras, or the required bandwidth of numerous cameras.
  

• The Basic Telepresence Robot is implemented as a "DOIT" Smart Tank Chassis.
  
• The Robot control was implemented as a DOIT provided ESPDuino and 2/4 motor controller daughter card.  This provided easy USB connectivity for software development and uploading, as well as ESP 8266 WiFi connectivity (Upper Center of above picture).
  
• Due to the motors used and the desired power, a separate 2 Motor Controller Board from Banggood was used. (Upper left of above picture).
  
• Remote video for navigation is provided by an inexpensive Web-cam (Lower Center of above picture), and OpenWRT router  (Lower Left of above picture).
  
• Power is provided by a common hobby type lithuim-ion battery.
  
• The motor controller function of the daughter card is currently not used, but the card is retained for future use for features like manipulators, camera pan/tilt functionality etc.  
  

• Beat detection
  
• Speed Control, or Pitch Bend, Brake, etc.
  
• Scratching
  
• A-B looping
  
• Waveform Display