Welcome, Guest. Please Login.
Linuxslate.com Forums

<=== Back to the Linuxslate.com Homepage

Newest Forum Posts

Jan 18th, 2022, 4:43am
News: Welcome to the linuxslate.com forums. May 2020: Forum registration has been disabled due to recent advancements in bypassing captcha's and the resulting increase in spam on the forums. Registration may be re-enabled at a later date. In the meantime, if you would like to register, please email "john" at this domain, and I will manually create an account for you. Registration is for legitimate and relevant discussion only. Misused accounts will be deleted without warning.

1  Linuxslate.com Reviews & Commentary / Review Discussions / Re: Polimaster 1208M Gamma Detector Watch
 on: Jan 11th, 2022, 4:08pm 
Started by Administrator | Post by Administrator
As promised, here is a "Have I Found Anything Radioactive" report for the Polimaster 1208M Gamma Detector Watch:
I did find something radioactive, but unfortunately, I cannot tell you about it at this time.
What I can say is the following:
  • 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.

What's the point of posting about something I can't actually report on?
  • 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.
Reply Reply Quote Quote Notify of replies Notify of replies  

2  Mobile Linux Devices / General News / Re: Turtle Beach VelocityOne Flight Control and Li
 on: Jan 9th, 2022, 3:15pm 
Started by Administrator | Post by Administrator
XML Files for Turtle Beach VelocityOne Flight
Linked below are my current XML files that I am using with the Turtle Beach VelocityOne Flight Controller and Flightgear.
The files are set up for a Twin-engine aircraft.  Propeller Pitch/Engine Mixture controls are not implemented as of this posting.
Specifically, I have been using this with the P-61 Blackwidow.  (Scroll to "Northrop"), but it should be suitable for most twin engine aircraft.
Axis/Buttons Definitions (See XML files for specifics):
  • 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.

No LED's assigned, or currently functional as previously mentioned.
Click Here to download a .zip containing both needed XML files.
Other Misc Notes:
  • I cut the end off of the included allen wrench for more convenient use. (see prior posts)

Reply Reply Quote Quote Notify of replies Notify of replies  

3  Mobile Linux Devices / General News / Re: Turtle Beach VelocityOne Flight Control and Li
 on: Jan 5th, 2022, 9:36pm 
Started by Administrator | Post by Administrator
I now have the Turtle Beach VelocityOne Flight Control Yoke and Throttle Quadrant, along with my Thrustmaster T-Rudder working in FlightGear.
Steps to make it work:
1.  Connect the VelocityOne Flight Control to a Windows 10 PC (or XBOX), and use the FMD to Select PC as the Input Mode.  The VelocityOne Flight Control will then work on a Linux PC.
2.  Back up your installations version of  /usr/share/games/flightgear/joysticks.xml.  For examle:
sudo mv /usr/share/games/flightgear/joysticks.xml /usr/share/games/flightgear/joysticks_bak.xml 

3.  In FlightGear, add the following lines to /usr/share/games/flightgear/joysticks.xml.  These line must be added just before the </PropertyList> tag:
	<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"/> 

So with my Thrustmaster T-Rudder included, my /usr/share/games/flightgear/joysticks.xml looks like this:
<?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.

	<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"/>

(Substitue username, and fgfs path for your installation of FlightGear.)  You can point to /user/share/games/flightgear/Input/Joysticks/, but then you need to be root every time you want to edit the configuration files.
4.  Create the Files Turtle-Beach-VelocityOne-Flight-0.xml  and Turtle-Beach-VelocityOne-Flight-1.xml in your .fgfs folder, or in /user/share/games/flightgear/Input/Joysticks/.  Be sure the path specified in /user/share/games/flightgear/joystick.xml  is the correct path to the referenced files.
5.  Edit the Turtle-Beach-VelocityOne-Flight-0.xml and Turtle-Beach-VelocityOne-Flight-1.xml  files to set up the VelocityOne Flight Control as desired.

  • 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.  

Credit to these threads for getting me pointed in the right direction:
https://forum.flightgear.org/viewtopic.php?f=6&t=454&hilit=Proper+joysti ck+selection+and+less+weirdness
I will post my Turtle-Beach-VelocityOne-Flight-0.xml and Turtle-Beach-VelocityOne-Flight-1.xml  files once they are a bit more mature.
Reply Reply Quote Quote Notify of replies Notify of replies  

4  Mobile Linux Devices / General News / Re: Turtle Beach VelocityOne Flight Control and Li
 on: Jan 3rd, 2022, 4:25pm 
Started by Administrator | Post by Administrator
Once set to PC mode (See previous post), the VelocityOne Flight Control is recognized in Linux.
Using jstest-gtk, the VelocityOne Flight Control appears as 2 joysticks -- The Yoke and the Throttle Quadrant -- as indicated below:

Other notes/comments:

  • 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.

Update:  Sorry for this being a little dis-jointed, but I am actually posting as I work on this to get it out there, and possibly to get some fixes in the next Turtle Beach firmware.
The main problem I am having right now is that both the Yoke and the Throttle Quadrant have the same vendor and model identification.
udevadm info /dev/input/js0 or udevadm info /dev/input/js1 both return:
Note that in the jstest-gtk screen shot above, they are both identified as Turtle Beach VelocityOne Flight.  They are both identified the same way in the Flightgear Joystick Configureation screen.
Just setting up one at a time doesn't work, because it seems that even with the USB-C-to-C cable between them removed, Linux still sees both devices -- of course the throttle quadrant doesn't work.
I am trying to fix this with a udev rule, but I have not been successful yet.  The easiest solution (for the user) would be for Turtle Beach to fix the fact that both HID devices have the same model indication.  For example if the firmware was changed so that the Yoke had ID_MODEL=VelocityOne_Yoke, and the Throttle Quadrant had ID_MODEL=VelocityOne_Thrt,  this issue would be eliminated.
That said -- with a combination of manual editing of XML files and the Flightgear Joystick Configureation menu, I have gotten it to work.  In addition to the Velocity One Flight Controller, I was also using my Thrustmaster rudder pedals.  I was able to fly the twin engined P-61 Blackwidow around the feild very nicely, with working individual throttle controls, and a working pitch trim wheel.  I have to say that while I stand by my above comment that the throttles should be a little stiffer, the overall feel of the VelocityOne yoke is excellent, and much nicer than the CH Products yoke.
Specific configurations, with suggested XML files will be posted in another reply soon.
One last note for now:  The right hat switch is not recognized due to limits of the Linux HID drivers.  It is unlikely that this will be remedied any time soon.  Other than that, all axis and switches on both the Yoke and Throttle Quadrant are recognized by jstest-gtk.
To join in this conversation, please request an account using the email address at the top of this page.
Configuration files for Flight Gear will be covered in the next post.
Reply Reply Quote Quote Notify of replies Notify of replies  

5  Mobile Linux Devices / General News / Turtle Beach VelocityOne Flight Control and Linux
 on: Jan 3rd, 2022, 3:54pm 
Started by Administrator | Post by Administrator
I purchased a Turtle Beach VelocityOne Flight Controller with the hope of using it with Linux and Flight Gear.
I was prepared to do some axis and button assignment, and I have gotten various USB controllers working with FlightGear (fgfs) in the past.  In fact, I only purchased the VelocityOne since my CH Products Flight Yoke has several physical issues due to years of use from myself and the previous owner.
Note: for reasons well beyond mere mortals, Google Search is currently returning a "printable" version of this thread.  The correct URL for this page is:  http://linuxslate.com/cgi-bin/forum/YaBB.pl?num=1641243248
Sadly, unlike the CH Products yoke, the VelocityOne is not a standard USB HID device.
Major Update.  This post was pre-mature.  Out of the box, the VelocityOne Flight Controller was not regonized by my Linux PC (Ubuntu 20.04).  I got no display or lights, However;  when connected to a Windows 10 PC, the display (FMD) became active, and I was able to switch the unit from XBOX to PC mode using the FMD.  It was then recognized as 2 standard USB HID devices and sound devices by Linux.  Please see the 2nd and 3rd posts.  Note that as of this writing, it is likely that if the unit is set back to XBOX via the FMD, it will need to be connected to a Windows PC to allow it to be set back to PC mode.
It is reported as follows in lsusb -v
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

Here is a grab of syslog when it is connected.
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

Reply Reply Quote Quote Notify of replies Notify of replies  

6  Original Projects and Builds / Other Builds and Projects / Re: Telepresence Robot Build - With Code!
 on: Dec 29th, 2021, 10:22pm 
Started by Administrator | Post by Administrator
20 x 4 LCD Display
It has been mentioned previously in this thread that it would be desirable to have a simple display on the Telepresence Robot for information like the Robot's IP address, battery voltage, etc.  It may also be useful to allow the remote user to display simple messages such as the remote user's name, or the organization the remote user represents.
To this end, I went to Sky Craft Surplus in Orlando, FL., and purchased 2 LCD displays.
This post will concentrate on a 20 character x 4 line display that was inside some sort of digital audio device. The surplus device was being sold for US$ 9.95.  So in addition to the display, I got the steel chassis, a small PC-like power supply, an optical drive, fan, and various other potentially useful parts.
The display is very similar to the one shown here:

20 x 4 Alpha-numeric LCD display removed from surplus equipment
I had quite a bit of difficulty finding the Datasheet for this display, or any specific information on connecting it to common Arduino modules.
So I thought I would do a simple write up on getting these boards working with Arduino.

  • 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.

Here is the pinout from the Datasheet and corresponding Arduino Pins and Functions:
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

The code is equally simple.  These displays work with the standard Arduino provided LiquidCrystal Library; however, some special characters or display functions may need changes to code to appear on the display as desired.
Here is sample code to display a childish message using all 4 lines (rows) of the display:
#include <LiquidCrystal.h>

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

void setup() {

lcd.begin(20, 4);

void loop() {
  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);


The display connected to an Arduino Nano, and displaying a childish message.
Another note on the picture:
-- Yes, I tack soldered the wires directly to the Arduino Nano.  Pins and connectors would have been better, but this was just for a quick test.  It will be properly connected to the pins on the ESPDuino on the Robot.  The holes on the Arduino NANO can be easily cleaned, and pins soldered in.
-- This requires almost all of the digital I/O pins, but most of the pins used on the Robot currently are Analog pins.  I don't anticipate a problem, but the actual design of connecting the LCD to the Robot has not been done yet.
-- Another solution would be to leave the LCD connected to the NANO, and write a simple serial or I2C - to - parallel program, but in addition to the extra hardware, this would require maintenance of 2 sets of code.
Look for an update -- and updated Robot code -- once the LCD is attached to the robot.
Reply Reply Quote Quote Notify of replies Notify of replies  

7  Original Projects and Builds / Other Builds and Projects / Re: Telepresence Robot Build - With Code!
 on: Dec 25th, 2021, 1:41pm 
Started by Administrator | Post by Administrator
Comments on The Code.
This is post #3 of this thread.
The code is too large to fit in a post.  A public version can be downloaded here.  (<---Link to be added soon)

  • Substitute the Access Point Name and the Access Point password in lines 37 and 39.
  • The IP address of the Navigation Camera (Typically must be inserted in the HTML code in line 118.

Navigation Camera Setup:
As mentioned, the Navigation Camera is implemented via an inexpensive webcam connected to an OpenWRT mini-router.  If the OpenWRT router you use is not for configured for the web cam, details can be found here, and will not be further covered in this thread.
Deficiencies and Improvements:
(No special order)

  • 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.

Join in the Discussion!
Are you building a simiar project?  Using some or all of the provided code?  Suggestions for improvements?
Please email "john" at this domain, and I will create an account for you.  You email will not be made public.
Reply Reply Quote Quote Notify of replies Notify of replies  

8  Original Projects and Builds / Other Builds and Projects / Re: Telepresence Robot Build - With Code!
 on: Dec 25th, 2021, 12:30am 
Started by Administrator | Post by Administrator
In this section, I will describe the Robot Control Software.
A Few Words about Security:
Before I begin discussing the software, I should emphasize that this is a home (hobbyist) project.  It is not a commercial product nor intended to be one.

  • 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.

In other words: Don't implement what is described below in a secure network, or as a commercial product. Think when you build software.
User Interface:
As mentioned in the previous post, the Telepresence Robot may be located far away from the operator.  This means that common remote control methods such as those used for a Radio Controlled (R/C) car or a connection over Bluetooth would not be applicable.  However, basic Bluetooth code such as found here was used as a starting point.
It was also desired to have the Robot Control universally accessible, and not require software development on multiple platforms or operating systems.  

User Interface during use of the Telepresence Robot.  Image property of Linuxslate.com
This means that the Robot Control is via a web app that resides on the robot.  All one has to do is initiate a standard HTTP connection to the robot's address, and they will be presented with the interface shown above.  Note that the person-to-person interface is provided by a Google Hangouts session in another window.
Implementing the user interface in this manner was more complex than originally thought.  It is implemented as a ESP8266WebServer running on the ESPDuino board.  The ESPDuino web server delivers an HTML page that in turn contains CGI and Javascript.
The concept of Javascript and CGI embedded in HTML, which in turn is embedded in Arduino C code was a bit much for my son to follow, and frankly a stretch for my programming skills.  I'll just say that both of us got really good at reading through several levels of escape characters.  
Esentially, movement is controlled by starting the respective motors on a mouse down event, and the motors are stopped on a mouse up event for each button.
An iFrame at the top contains the separate video connection, and another iFrame just below that serves as a basic instrument panel showing the main battery voltage and the strength of the wireless signal.
In the next post:  The Code.
Reply Reply Quote Quote Notify of replies Notify of replies  

9  Original Projects and Builds / Other Builds and Projects / Telepresence Robot Build - With Code!
 on: Dec 24th, 2021, 11:47pm 
Started by Administrator | Post by Administrator
My son built a Simple Telepresence Robot for a Summer / Stay-at-Home project.
What follows here will be a basic description of the Design, the Finished Robot, and a Basic Description of the Code.

Basic Telepresence Robot.  Photo property of Linuxslate.com
Design Goals for a Basic Telepresence Robot:

  • 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.

Use Cases:
What is different about a Telepresence Robot, and a "normal" Zoom Call, or other Teleconference?
The main difference is that the remote user can move around an area at the remote location;  much as the remote person could if they were actually present.  Here are some possible scenarios to help the reader understand the difference between Telepresence and a Teleconference.

  • 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.  

In the next section, we will talk about the software implementation.
Reply Reply Quote Quote Notify of replies Notify of replies  

10  Original Projects and Builds / Other Builds and Projects / Re: Poor Man's version of the Monster GO DJ
 on: Dec 2nd, 2021, 2:58pm 
Started by Administrator | Post by Administrator
Previously in this thread, I have mentioned other products similar to the "Poor Man's Go DJ".
I have since come across 2 additional products that are even more similar -- Both bearing the "Technical Pro" brand name.  These units are particularly pertinent to this thread, because these units seem to share the idea of using simple, generic music player modules.

Technical Pro DJ2USB.  Photo from Manufacture's website
An even more basic unit seems to exist, or have existed:

Technical Pro DJ4PB.  Photo from eBay vendor
Given how basic the players look in both of these units, I'm going to say that they probably have similar or more limitations than either the original players used in the "Poor Man's Go DJ", or the new, color screen media players currently installed.
I want to be clear that I have never seen either of these Technical Pro units in person, and of course never used them, but I am confident that as with the project described in this thread, the Technical Pro offerings also lack features such as:
  • Beat detection
  • Speed Control, or Pitch Bend, Brake, etc.
  • Scratching
  • A-B looping
  • Waveform Display

Note also that they do not seem to share the USB or SD card slots.  Like the "Poor Man's Go DJ", separate media for each player appears to be required.
I would hope that at the vary least, the media players display time remaining, but unless Technical Pro developed or modified the players, these decks (and it's quite a compliment to call them "Decks") may suffer from the same awkwardness as the players originally used in the "Poor Man's Go DJ".
I'd like to point out the fact that the DJ4PB has 2 microphone inputs with separate level controls, and Bluetooth on one of the players.  The DJ2USB has analog tone controls (although "High" and "Low" only, no Mid Range).
They appear to support only MP3 and WAV file formats.
There is no indication that either of these units will run from Batteries.
Am I publicly bragging or dissing Technical Pro here?  Well -- Yeah -- Maybe a little.  The "Poor Man's Go DJ" has been a very successful project.  It has more features, and likely better sound (when playing a better quality FLAC file) than the Technical Pro offerings.  It also has the 8 sound effect/beat/sample player.
The Technical Pro units win in terms of a mountable metal chassis, and microphone inputs.  I should also mention that they do have more elaborate player mixers, that do have features like scratching/etc.
However, while Technical Pro has some very compelling and desirable Karaoke mixers/amplifiers, for casual events, they are not really known for living up to the "Pro" in their name.
Reply Reply Quote Quote Notify of replies Notify of replies