Goddard Surveillance Rover Prototype 1 Development 2018-19

Posted on 3 May 2019 by fgould

This blog is about my technological venture into hardware configuration that I hope will result in a working prototype. This is a hobby to experiment for what a final product could possibly be based on this design. The first concept piece I created can be seen at the following link: Rover Initial Concept Prototype Draft.

Many of the tests turned out to be unnecessary because there was a faster, already implemented solution that only required code to implement. An example of this is the fan-cooling temperature gauge and circuit board. Once I learned RPi reports this with a query, I could turn on the DC power to those fans, at any value up to 255 to start cooling the CPU. Below is the beginning of my journal that started in July after two months of learning curve experiments.

Pan/Tilt Initial Build Results

After soldering the Adafruit 16 Channel PWM/Servo Motors HAT 40 GPIO pins and 8 of the 16 channel three pin connectors (for a total of 64 pins on one board), the pan/tilt worked marginally and inconsistently. Below is a picture of the first successful test.

Thermometer and Cooling Fan Results

To be configured for outdoor use, a fan is an important addition that will at least move cooler air across the circuits once the temperature reaches 150 degrees Fahrenheit inside the unit. To create the circuitry for this feature, I consulted DigiKey who offers an online recipe and schematic editor for creating a thermometer and cooling fan. Below is the schematic I followed to create this feature.

This is the schematic I edited for my final design:

Once I created the breadboard version and it worked, by removing the resistor to the transistor, I created a soldered board that ended up like the picture left.

Fried RPi 3B+ and 16 Channel PWM/Servo HAT

Following the Adafruit 16 Channel PWM/Servo HAT and DRV8871 DC Servo Motor Driver Board installation instructions, I ended up shorting out one of the driver boards that scorched the breadboard, as illustrations follow.

Over time, it appears the 16 Channel HAT shorted out the RPi 3B+ board because it eventually stopped booting and only one LED light lit up and nothing else. These failures caused a redesign and delay for shipping and receiving new parts.

I continued to use these dead RPi and Adafruit boards so I could build rig pieces without stressing the prototype PCBs (Printed Circuit Board). This is where we waited for the RPi3B, RasPiRobot, and PWM boards to arrive on 20 July 2018, which they did, and Phase 1 restarted.

Built Devastator Tank Wheel Base

On 18 July, while waiting for replacement parts, I decided to build the tank wheel base as shown in pictures below. To view the build instructions Click Here.

Below are the wheels with spring shock absorbers mounts.

Below is the rear end where the components will be installed as modules.

Rover Redesign Phase 1 – Version #2

Because I fried a few boards, it became apparent an alternative configuration and boards were needed. Adafruit failed to deliver operable boards and refunded my investment in their products.

Below is a picture of the tested redesign configuration of the DC and PWM servo motors driver boards with Raspberry Pi 3B (not plus).

Note: this is the same SunFounder board was used after the level separators blew the Geekworm PWM/DC Motor board later. Also note that the breadboard contains the 360 PWM calibration circuits that are not connected in this picture to the motor.

23 July – The above configuration failed due to excess power noise caused by the RasPiRobot board that caused video disturbance and ejected the USB drive when attempting to use the PWM channels that resulted in the following message.

After removing the RasPiRobot board, PWM started working consistently for all servo motors, even one marked NFG worked that had failed using the original Adafruit 16 Channel PWM/Servo board.

This same day, I was able to build the new rig, as pictured below.

Then after installing and testing the Geekworm PWM/DC Motor board, the boards sagged (not shown in the picture above) because the lack of support on the top UPS board using only 10 pins for support and without the spacers, one can imagine how the boards will sag when the rover bounces on uneven surfaces.

Then I installed leveling separators between the boards and the Geekworm PWM/DC Motor board began to fail. Here is my report to the manufacturer who had no solution other than work around with a replacement board.

That’s when I decided to modify the M-F jumper wires by bending the Female connector to a 90 degree right angle. To intercept the GPIO pins, because the MoPower UPS does not have GPIO extension pins like the Geekworm HAT (and other similar HATs), these same right angle connectors are installed below the HAT, as shown in the picture below, following the intro paragraph.

Rover Redesign Phase 1 – Version #3

This design is essentially the same Geekworm PWM/DC Motor HAT, however replaced, but now has the 90 degree connectors to reduce the wasted space above the HAT (shown in the picture below).

This new design was made to confirm RPi 3B and 3B+ compatibility and to test the Geekworm HAT without metal separators. I finally found a nylon separator kit, although I only need a few pieces and will have a huge batch left over. These kinds of overages can be used on a second prototype build.

Today, 10 August 2018, we await the arrival of the RPi 3B+ board and Geekworm HAT. During this time, I created a duplicate base plate (plywood sheet) and installed the metal separators using the dead RPi and Adafruit HAT. Once the RPi 3B+ board and Geekworm HAT arrived, I installed the two boards ready to begin testing the new boards.

Remote Control Tablet

As mentioned above regarding the orders placed on 10 August, the Remote Control consists of a RPi 2 designed tablet with touchscreen and battery charging. Below is a link to their tutorial I followed.

Adafruit RPi 2 7″ Touchscreen Tablet Tutorial

These are the Remote Control parts (Flex Cable and SPDT Slide Switch excluded):

Raspberry Pi 2

7″ Touchscreen

Lithium Ion Polymer Battery

PowerBoost 1000 Charger

RPi Touchscreen Case (See Below)

Wi-Fi Dongle

RPi Touchscreen Case

For the remote control, I finally found that Adafruit tutorial with the recipe of parts needed to make it battery operated. What was unique about this project was the use of a 3D printed case. All I had to do was download the STL files from Adafruit’s website, upload them to the 3DHub.com site, and pay for shipping (total less than $30). Below is the original image of the printed parts (I chose red for fun!).

This turned out to be another variation on hardware integration where finding the right screws makes a whole lot of difference. The variances also require testing a screw to confirm it’s the right head shape: Flat or Round. Because the boards are stacked on the printed tray insert, a Round head can extend up into the back of a stacked board and short out the circuitry. They don’t mention this in the Adafruit tutorial.

So, what I finished the prototype design with regarding screws, I’ve listed below.

Tutorial	Actual
M3 x .5 x 6M	M3 x .5 x 6M
#2-56 3/8″	#4-40 1/4″

The problem with the first Metric screws (M3) was that Skycraft carried many varieties of this screw and the first I found had a washer fixed beneath the head that caused the head to rise even higher under the stacked boards. Upon further investigation, I found the same size without the washer and ended up with a more tight fit without possible shorting.

Once I got everything working, I learned I had soldered two wires wrong off the Power Boost Charger 1000. I made this mistake because I didn’t see the – and + signs behind a USB connector that was just setting in sockets and not soldered to the board. The green arrow in the illustration below is what I missed and fried the $20 board by soldering it to the 5V and GND pins next to where the switch is soldered. I took this expense on because I failed to confirm my solder points before I commit, like “measure twice before cutting.”

After I removed the extra piece and saw the electrical schematics, I re-soldering it in the right place, the battery never charged. So, I’m heading back to Adafruit to ask if I’ve burned another board and maybe a battery. Turns out I had fried the LiPO battery charger on the board, so I ordered a replacement. This was when support failed and could not offer an explanation why the battery was not charging. They refunded both of my last purchases and banned me from their site, indefinitely.

Rover Redesign Phase 2 – Version #4

This version change was forced by the RPi3B+ failure and the integration of the RPi3B, Geekworm HAT, and MoPower UPS. During this phase, I redesigned the 90 degree female pin connectors so that there was no black shield included with the contacts and only heat shrink shielded the contacts so less room was consumed by the black shields. This also reduced the labor and glue to hold the black shield, plus the installation was significantly easier.

Also during this phase, I migrated the 360 pan gimbal calibration circuitry to the soldered board along with the temperature switch for the fans. After deciding to migrate the fans from 5VDC to 12VDC, I migrated the fan power to the Geekworm HAT and removed the temperature switch. That way, once the thermometer read above the threshold, the code simply turns the fans on full blast. That’s when we learned one of the 12VDC fans had shorted out and no longer worked (nor could be repaired due to contact location beneath plastic shield).

While testing the PWM for the 360 calibration circuitry, I learned that my solder job had failed and decided it was time to delay the development of the 360 pan feature. Instead, for the prototype, once the 180 pan hits its left or right max radius, the code will instruct the wheels to turn opposite directions to continue the camera pan. This does not remove the requirement for the gimbal 360 pan because the camera should be able to provide 360 views for location and damage mitigation. Below are pictures of the rig with semi-operational features before implementing version #5.

Top of Semi-operational version #4 prototype

Front of Semi-operational version #4 prototype

Right side of Semi-operational version #4 prototype

Left side of Semi-operational version #4 prototype

After migrating to the 12VDC fans and delaying the 360 pan feature, sufficient pins and circuit board became irrelevant and were outside the MoPower UPS 10 GPIO pins requirement. This meant a GPIO 40 pin extension header could be removed and rewired to the Geekworm HAT extension header only (which is why their design failure requires any spacers for this development design).

Right side of Semi-operational version #4 prototype

Left side of Semi-operational version #4 prototype

Rover Redesign Phase 2 – Version #5

After removing the circuit board for 360 gimbal and cooling fans along with their wires, the content of the rover changed considerably, as shown in the pictures below.

During this phase of version #5, I wrote code to use the keyboard to drive the wheels and turn forward and reverse. What’s nice about these motors is when something is going in the wrong direction, like forward and reverse, it’s a simple reverse polarity on the power to fix the direction problem. I had to do that to the power supply wires to the motor connected to the HAT. Once I did that, my code turned the correct wheels (left versus right) and forward/reverse worked successfully. Next to version #6, batteries and secured rig to chassis.

Rover Redesign Phase 2 – Version #6

After creating the rig lock mechanism with Velcro, acrylic side slides, and front key-lock latch, I tried the battery driven vehicle but encountered a failure with the Geekworm HAT. Although it appeared like the previous board I fried, this time it recovered and operated accurately with shore power. I have sent a question to the manufacturer asking how to connect a battery to their board; it may need some kind of regulator. After searching the web for an answer, determined a UBEC needed to be added to regulate the power and it worked. Below is a picture of version 6.

Pan and Tilt Gimbal

Because of the 360 degree pan feature delay, I decided to search again for a python gimbal and found a 3D printer opportunity for a less-flimsy Adafruit gimbal. Below is their glamour shot picture of the parts that are max 4″x4″ and encloses the wiring.

I have sent email to a local 3D printer engineer asking if he can help with plastic residue refinement and tests, as well as contacting the designer of this gimbal via email to ask some specific questions. One question is where to find a switch that is listed in the parts list that I cannot find and how does the camera ribbon cable enter the mounting head’s electronics.

Rover Redesign Phase 4 – Version #7

This section skips a phase because of the many redesigns overlapping each other. This phase is an operational battery-powered prototype with full 360 degree pan and 180 degree tilt gimbal. This required building a wooden rim to hold the gimbal under the glass dome. The full rig design can be seen here. The camera dome design is illustrated below.

Based upon my design RFC (request for change), Ben Holler sent back the gimbal base that 1) fit under the dome (this I learned was serendipitous because I was removing unnecessary legs which would be more for a DSLR camera than the rover) and 2) rotated the screw holes to accommodate the camera ribbon cable. The ribbon cable issue is still under research once the rig dome has been built.

Here’s the current operational version of the rover, without and with the gimbal.

Dome Base Plate – Rig 3D Print Part – Version #8

Because the wood used for the Dome Base Plate cracked the dome due to difficult curves through hard grain, it made more sense to 3D print the part so that the dimensions and fittings are more precise. To do this, I used AutoDesk 123D Design app and built the dome structure plate with the original gimbal base plate.

Original Full Diameter and Depth: 166mm x 20mm, Radius: 83
Changed Full Diameter and Depth: 177mm x 20mm, Radius: 88.5
Dome radius channel to external base top: 70.5 x 15mm (used 71mm radius)
Camera base extrusion channel to dome radius and depth: 67.5mm x 15mm (used 67mm width)
Inner full opening: 22.5mm x 25mm (20mm exceeded to cutout hole)
Bolt holes 5mm and ribbon cable opening 18mm x 2mm

Here’s how it looked close to ready for print:

Next 3D Print Job September 2018

This section is to list the parts that need to be printed again and why.

Rover Dome Base Plate – Picture above was correct but not submitted for print because of errors with the edits. What was printed the center axis of the base is rotated incorrectly as well as the mounting bolt holes in the front and back are way too big.
Rover Acrylic Motor Driver Board – The holes for the micro PCBs are too close to each other and cause the bolts to jut out at angles. Needed to lengthen the main board and separate the left board’s right side from the right board’s left side.
Tablet RPi Holder – This is a design change from the original printed part that separates the RPi mount from the main mount that holds the display board and battery (see picture below).
Tablet Main Mount – This is a design change from the original printed part that remains after separating the RPi Holder.
Rover Gear 14 – Needed to reduce the motor axis shaft opening that allows slippage. Also needed to sand gear burrs on smaller flat side to prevent contacting other parts when moving.
Rover Gear 9 – Needed to edit the gear by flipping the treads or internal slot and to reduce the motor axis shaft opening that allows slippage.

——-

Gimbal Gears Analysis

After spending all day 21 September building the motor driver board test system and rebuilding the gimbal, testing it all and worked closer to expectation than before. Tested it again, this morning, to try calibrating the head to exact coordinates but it eventually failed and locked up, again. After examining the motor-free housing case, the problem appears to be caused by stepper motor gears problem, listed below.

Gear 9 – The gear extends too far over Gear 15 and thus out-of-alignment. Needed to edit the gear to tighten gear shaft opening, like Gear 14. Determined Nylon was best for this and Gear 14 due to heat from motor per Kyle’s recommendation. He said they were better for the heat and being more pliable.
Gear 15 Opening – Needed to be sanded to allow free-spin where it was jamming slightly when spinning. Could be both the gear and the opening.
Gear 14 – Needed sanding of burrs along the short diameter side to prevent catching opening when moving. Also needed tighter gear shaft opening, like Gear 9. Determined Nylon was best for this Gear.

Tablet Redesign – Revision #1

Because Adafruit was unable to support their products, I researched online for other UPS boards that would accomplish the same battery operations without their products. This created the opportunity to improve the original design and upgrade the motherboard to RPi model 3B which includes integrated Wi-Fi support that RPi 2 does not. The RPi 3B version will be the main upgrade for the Tablet Redesign Revision #2.

Below is the list of Revision #1 changes:

Lower the motherboard mount beneath the main mount structure. This helps provide more space for the new battery HAT to be installed on the top of the RPi. Add same screw holes to motherboard mount and add two new screw holes to attach the RPi mounting structure to the main mount.
Remove the PowerBoost mount from the main mounting board.
Add two screw holes to the middle of the case back and lid.
Close case side opening near PowerBoost mount, case over Ethernet connector, and remove switch.
Add bottom case opening to access the new battery board power switch.
Use #4-40×1/4″ screws for the main mount structure and back lid.

Pictures of remote control tablet:

7″ Touchscreen Display and Driver Board with Component Mounting Bracket

Remote Control User Interface with picture insert of future video feature

First Outdoor Field Test

Version 8 – Integrated System Complete

23 October 2018 is the date I finally integrated a majority of the parts that all successfully operate. Because the rover needs to be tested in a rough environment, I am holding off testing the larger camera. As a result of the Gimbal pan cable being too short to reach the bottom of the stacked boards, will have to move the DC Stepper Board to the top of the stack, directly beneath the Gimbal base. Currently, the Gimbal cannot go beyond 90 degrees right or it will rip the cable. Also, determined M5 bolts are too large to fit inside the 5mm hole in the Gimbal base (see missing in picture) and replaced that bolt with a M4 bolt.

Picture Above is Right Side of Rig

Picture Above is Left Side of Rig

Version 9 – Integrated System Redesign Complete

The redesign consisted of the following changes that were described in the journal section at the top of this blog. Recap, all worked with the exception of the streaming camera video boot and gimbal with python3, works with python2. Also, remote control tablet is functional with kivy UI. Full System backup of both devices today 12 November 2018.

Replaced wheels and fans connectors with JST 2.0 mini connectors.
Flipped and moved the gimbal stepper motor board to the top of the stack closest to camera. This was to solve the camera pan right that was stretching the cable too far.
Heatshrinked fans and wheels cables.

Version 10 – Integrated System Redesign Initiated

This R/RC redesign consisted of new tablet case (see below), additional board to remove the flipped ribbon cable to run flatly between boards, and upgrading the RPi from 3B to 3A+, thus removing the RJ45 connector and four USB slots. This version also includes three buttons on the base of the video window that allows the user to take a snapshot of the video image and the tablet screen (see RC image below) as well as recording video for a max of one minute, user controlled button.

New Remote Control Case – Version #2

Below are shots of the new tablet case that has been submitted to 3DHubs.com and FluxDesign, the latter redirected my order to a different provider, Walter’s World, on 16 December.

Remote Control User Interface Enhancement

Below is the tablet’s screen capture and still video capture generated pictures. The three new buttons under the video will be enhanced to look like the other buttons on the right, in the picture below.

Then after enhancing the User Interface with icons, the screen appears as illustrated below:

In this screen capture taken with the bottom right Shot button under the video, it displays the new icons on the top left and the three new capture buttons on the bottom center beneath the video display. There are two battery icons on the top left, R = Rover and RC = Remote Control that shows the rough amount left in battery capacity. The Rover battery icon is showing the alert battery icon indicating less than 20% capacity. The Remote Control battery icon is showing less than 80% remaining battery capacity. Note that for the Remote Control, this is only a rough indicator where you can see the actual amount above the Wheel Motors control to turn left. In this capture, the battery is actually 50% and should the go lower, the battery capacity icon will change to 50%.

The Wi-Fi indicator is also a rough indicator based upon the signal strength provided by the RPi and OS. The next icon to the right is the Rover communications indicator showing a green background when connected successfully or red background when there is no connection.

Then below the video display window, the three buttons are the Record the video stream for up to a minute on the Rover, but the user can stop the recording before that minute has recorded to Stop the recording. The middle button captures the video window, today, and plans are to enhance that to shoot the full resolution still video shot using picam and saved on the Rover.

Version 10 Rig Rebuild

Took the following photos when rebuilding the rig PCB configuration with the following changes:

Replace RPi3B with RPi3A+ – not visible in picture below.
Add new ribbon cable board to prevent curling cables sideways – see ribbon cable on center of left picture below.
Lengthen the 12V power cable so connector accessible from outside – see connector on left side of rig (next to ribbon cable), in left picture.

The Reconfiguration Bay is an old pool water hose vacuum with the wheels removed so it stands flat to flip the rig over for easy access to the electronic components. The boards in order from the top to the bottom in the left picture are:

NEW NOT SHOWN (this is a before shot of the rig) Camera Ribbon Cable Board
UPS and Battery Board (shown as top in this picture)
SB Component DC Motor Board for Fans and Wheels
Raspberry Pi 3A+
KOOKYE Stepper Motor Driver Board – for Gimbal
Home Built Fans/Wheels Power Connectors Board

Lengthening the 12V Power Input Cable to be accessible from the rear allows easier connection with the Battery Cable shown in the bottom left of the picture below. This picture also show the Fans and Wheels 4-pin connectors.

——-

Remote Control Internal Components – Version 10

While restoring the operating system and apps on the tablet that stopped communicating due to my attempts to connect it to the hotspot, I was able to take a few photos of the inside of the Remote Control and post them below. I also removed a portion of the RPi mounting plate so that the microSD card is accessible without disassembly. There are several minor modifications to the 3D print file that need to be made to loosen up and relocate some of the screw holes so the back panels fit more accurately. This can be seen in the first picture of the back panels and how they are slightly askew.

Migrating Wi-Fi LAN to R/RC Subnet

This section gives an overview of the hardware, research, and tests that were necessary to migrate to a R/RC Wi-Fi Access Point (AP) subnet. First, the hardware needed a wired Ethernet connection so that when I switched from the Goddard Wi-Fi Network to the Remote Control AP, I could still operate on the RPi through ssh (PuTTY) terminal, since the home Wi-Fi AP would no longer appear on the R/RC network. So for testing, I used two RPi 3B units, two RJ45 Ethernet cables, the HDMI monitor that normally runs the SlideShow all day, and the HDMI TV.

Once I got the dev units to startup with the Ethernet cables, I then went through online pages to figure out how to setup the Remote Control with hostapd on Arch Linux ARM. As mentioned in my journal, This research took many trials and reverting back to previous versions of OS builds on chips. Today is the first day to test the configuration that has worked when the Goddard Wi-Fi Network access point (Apple Wi-Fi router) rebooted and the R/RC continued to ping each other during the boot process.

At this point is where I needed to start switching networks using software instead of CLI (terminal) commands, I used the two dev units to simulate the switching before attempting to migrate to the operational Rover, in the first operational tests. Because the ping worked, I’m hopeful the Rover will be able to switch between the two networks. That’s why I created the network_switch.py service app to test on the dev Rover.

Rover GPS Time Sync Function

Because the Raspberry Pi does not include a realtime hardware clock and the Rover needs to boot in the field without Wi-Fi or any Internet connections, I had to integrate a GPS (Global Position System) to obtain the UTC time from satellites. I learned this from my initial field tests where the apps sat waiting for the system time to be set but there was no Internet access to obtain the NTP (Network Time Protocol) to sync the computer date and time. Although this took many hours testing different configurations, suggested solutions on other linux distributions, outdated information and a couple chatrooms, I was able to hack together an Arch Linux solution that follows integration standards.

Months before this need, I had ordered a GPS Module with TTL Ceramic Passive Antenna (shown above) knowing I would need it one day for R&D. Because I had kept copious notes on the Rover GPIO pins, I had four pins in a row reserved for power, ground, transmit, and receive signals from the satellites. Using a spare RPi 3B, I was able to cable and connect to the GPS with up to 7 satellites fixing inside our home. The next few weeks were spent configuring and testing until it was ready to install in the Rover. This required a wiring harness so that the unit was detachable and could be removed when working on the rig.

One important thing I learned in this research process is that PPS is not needed for the NTP timesync and GPS connection. Older online documentation suggests using that for the time pulse to the GPS that is no longer necessary with the later releases of gpsd, ntp, and systemd-timesyncd.

References – Tools and Workshop

Here’s our workshop for making wood and acrylic parts:

The above picture inspired the creation of the following list of tools needed to build this rover:

POWER TOOLS

Drills* – small Dremmel® drill for sanding and large drill for holes

Saws – table saw for large wood pieces, scroll saw* for round cuts (seen in photo that were replaced with 3D printed part) and acrylic pieces

Electric Sander* – to smooth rough wood saw cuts

HAND TOOLS

Screw Drivers* – extremely small and adjustable for flat and Phillips head screws

Compass* – for drawing circles on wood to cut

Soldering Iron – to solder wires to circuitry

Heat Gun – to heat shrink over solder joints

Tape Measure* – Inches one side, Metrics other side

Fine Files* – to sand 3D printer edges and openings, Husky® offers a great set

Needle Nose Pliers* – to pickup parts and tighten nuts and bolts

Hands-Free Stand with Magnifying Glass* – to hold things and allow two hands to operate on held item

Super Glue* – to lock the switches and nuts inside to Gimbal

Standard Pliers* – to unlock the main axis bolt

Vice Grip Mount* – to hold parts in locked place to solder or test

Magnifying Glasses – to see microscopic wires and solder

Needle Nosed Pliers and Dikes – to manipulate nuts & bolts and cut wires

* Pictured above or below.

Attributions

This section contains items and help with this project. Most have been collected through the years as gifts or purchased for Valencia College classroom exercises. The human-looking mechanical device with magnifying glass is used extensively for seeing microscopic parts and holding pieces to be soldered to add an extra “hand” to allow for other tools to be used.

The Lives of Others – College Critique

Posted on 11 September 2018 by fgould

Name: Frank Gould
Class: Advanced Film Program – Art of Cinematography
Date: 29 April 2011
Assignment: Review The Lives of Others Movie
Title: Apples, Oranges, Oscars, and Golden Globes

From the first frames of this movie, the audience is presented with a harsh reality of Soviet East Germany as the smooth camera dollies down a long and empty hallway where the painted walls have a line approximately as high as a human’s neck. As an officer escorts his prisoner down this hall, it appears as if they are both trying to keep their heads above this artificial paint line, metaphorically above water.

This same theme is repeated in most of the Stasi headquarter scenes showing a highly institutionalized 1960s appearance. The camera dollies left to right to show a classroom of students being lectured about how to interrogate a suspect into confession; the colors are grays, browns, and greens.

This is in stark contrast with the artist’s flat that appears warm and inviting.

Later in the story, the lead character sets up his surveillance room above the artist’s apartment and the camera move around him slow and methodically in the scene where he hears a song played on a piano by the resident below. This scene shows us how moved he is by moving a long way but keeping him center frame with all the high tech surveillance equipment surrounding him in a set that looks like a cave.

At this same point in the movie, there are many scene where he is standing or looking at things in the artist’s apartment showing a wide shot and all the set decorations that tell the audience about the artists he is watching and recording. I believe these shots also tell the audience that he is changing and becoming more appreciative of the artists and their lifestyle.

I chose this movie for this class review because it generated a heated discussion between a few students after watching it. Carlos Escobar and Bobby Arnold were not impressed with this movie where Alex Bright thought it was a great movie. Alex contended that Carlos didn’t like the movie because he couldn’t relate to it and that those of us alive during the cold war could. Carlos replied that he wasn’t born when the holocaust occurred but he liked Schindler’s List. The reason we watched this movie was to learn why this movie won the Oscar for Best Foreign Film over Pan’s Labyrinth. Bobby said he was not impressed with either movie. It was at this point our instructor reminded the students that art is like comparing apples and oranges. Some prefer one over the other. In this case, we watched a fantasy film to compare with a fictional documentary-type movie.

I was impressed with and liked both movies. Both are basically the same arc through the story where the antagonists try to oppress and control the artistic. The difference is that the antagonist in Pan’s Labyrinth is obsessed with his future offspring and legacy where in The Lives of Others, the antagonist is obsessed with the female life-partner of a successful East German playwright. Another significant difference is in the production. Pan’s Labyrinth is a very complicated fantasy world with mythical creatures and worlds beyond reality. The Lives of Others is a very realistic portrayal of communist controlled East Germany and how its citizens try to enjoy life in an oppressed culture. The story cleverly unfolds the change in that culture back to freedom when the Berlin wall is torn down. This is the irony because we learn in the beginning that the antagonist believes “people do no change!”

The protagonist in The Lives of Others is a Stasi officer named Hauptmann Gerd Wiesler (Ulrich Mühe) who is assigned the task of monitoring playwright Georg Dreyman (Sebastian Koch) and his lover Christa-Maria Sieland (Martina Gedeck), a successful East German actress. Wiesler’s commanding officer assigns this task to him in the attempt to break the two lovers apart for the commanding officer, higher in command. In the “rule of three” trilogy, Wiesler turns out to be the third apex between the lovers and the Stasi commanders. As he listens to the lives of the lovers, Wiesler indeed changes as the plot develops. We learn that Wiesler lives alone in a sterile apartment and exists only to serve the State by spying, interrogating, and torturing citizens into submission and obtain confessions for the State.

During a celebration party for Georg, he confronts the Stasi high commander about his director friend, Albert Jerska (Volkmar Kleinert) who has been blacklisted by the Stasi commanders and will never be able to work again. Then later during Georg’s birthday party Jerska gives Georg a gift of piano sheet music for Die Sonate vom Guten Menschen (The Sonata of the Good People) which becomes another trilogy in the plot. Georg attempts to convince the commander to remove Jerska from the blacklist but is too late because Jerska commits suicide and gives Georg a reason to protest the State oppression. Because the office of statistics stopped recording and reporting suicides (instead, calling them “self-murderers”), Georg decides to write an article for a West German newspaper to expose this travesty.

Act Two is where we watch Wiesler manipulate the lives of the underground protestors and attempts to setup a sting operation. However, the sonata that Georg plays on the piano changes Wiesler to where he realizes his life is void but the lover’s lives are full of close friends and art. Wiesler is so moved by the piano piece he hears over his surveillance headphones that a tear runs down his face while Georg plays it on the piano. He then starts lying about the lovers in his reports to the commander and then has to balance the story between the commanders and the lovers. Eventually, Wiesler loses his job because Christa commits suicide outside her apartment believing she will be incarcerated for treason.

Act Three is where the trilogy resolves as the East is freed, the high commander loses his job, and Georg learns that his apartment had been wired from the beginning. He then writes a book with the title of the sonata and dedicates it to Wiesler, in appreciation for what he had tried to do to save the lovers. The sonata plays a significant role in the movie and as a trilogy from when Georg first receives it from his friend before committing suicide (#1 – swan song) and when playing it, Wiesler changes his allegiance (#2), and finally at the end when Georg dedicates it to Wiesler (#3).

As for the Oscar win over Pan’s Labyrinth, I believe that the story resonated more with the voters for The Lives of Others in that it is more realistic to human suffering and how art changes the world to be a better place. Pan’s Labyrinth is definitely an entertaining and beautifully executed story but it lacks in its connection to specific life experiences. As for Bobby’s opinion of the two, he didn’t like fantasy stories and expected more action in The Lives of Others. He, obviously, prefers pears. I also found it interesting that both movies were nominated by the Golden Globe committee for Best Foreign Film but lost to Letters from Iwo Jima, a film directed by Clint Eastwood – ironically not a foreigner. Regardless, The Lives of Others won an Oscar and had 61 wins & 21 nominations, Pans’ Labyrinth won 3 Oscars and had 68 wins & 58 nominations, and Letters from Iwo Jima won an Oscar and had 16 wins & 15 nominations.

Goddard Sentinel Rover Prototype 1

Posted on 20 July 2018 by fgould

Please realize that this document is a journal of what I’ve done to create a final prototype product that is published here.

Here’s what’s happened up to today:

July 2018 – Ordered RPi3B for SlideShow build and learned Raspbian bug in graphics driver crashes Kivy and OS – this is not relevant to the rover but included for building SD cards.
Ordered Pan/Tilt arm, RPi3B+, 16 Channel PWM/Servo Motors HAT.
Ordered Devastator Tank Wheel Chassis to test 6V DC Motors.
Wrote software to control Pan/Tilt arm with IR camera head mounted.
Ordered components and built thermometer and fan to automate cooling. The optimal operating temperature is between 0°C to 70°C, or 32°F to 158°F. MoPower UPS range: 0°C – 45°C / 32°F – 113°F.
Ordered two DC Servo Motor Driver Boards and fried one of them; the other vendor deemed inoperable and replaced.
Failed to control 360 servo motor probably due to fried boards above. Pan/Tilt servos experienced inconsistent results.
Ordered MoPower UPS version 2 board for future Solar Panel
Fried RPi3B+ and 16 Channel PWM/Servo Motors HAT.
Ordered RPi3B+, 7″ touchscreen, and case to be used for remote controller – UPS lost package in Florida.
Built 16GB SD cards for Rover and Remote Controller – See Build Requirements below.
Redesigned to use and ordered RPi3B, RasPiRobot DC Motor Driver Board, and different brand/connections PWM HAT.
Built Devastator Tank Wheel base.
Determined the required battery and solar panel to power this sized rover were too large and heavy. This forced the decision to abort the solar panel design until a larger chassis and wheels can be designed to create a new prototype supporting the necessary solar power supply.
Tested a few motor driver boards before finding one that provided both PWM and DC servo motors on one board, thus removing the 16 Channel board. Due to design flaw with connection real estate on the Geekworm PWM HAT and the MoPower UPS does not have GPIO extension pins, it’s time for redesign.
While waiting for parts, wrote a short essay about my learning experiences with this project.
After removing the Geekworm board to return, the MoPower UPS board does not boot and goes into blinking red LED light. Moses suggested doing a board reset by pressing buttons during boot but didn’t answer my question about GPIO header extender. I’ll have to do this reset after I convert the pins to right angle connectors so I can stack the UPS board, should it work.
Successfully installed the new, handmade, 90 degree angle female pins onto the GPIO header and mounted both the SunFounder PWM and thermometer boards.
August 2018 – Ordered Geekworm HAT and received this email. That email link includes the whole episode with Geekworm Cindy and is a story of its own as shown on that page.
Finally received reimbursement from CanaKit for the lost package and ordered the Adafruit parts to create the remote control. That order included 3D printer parts to construct the mobile touchscreen tablet. Adafruit’s RPi 2 model B was out of stock at $40, so I had to order it from amazon.com for $42.
10 August order status: 1. RPi 3B+ and Geekworm HAT due today, RPi 2B due tomorrow, Nylon Hex M-F Spacer/Screw/Nut Assorted Kit due 12 Aug (day after tomorrow), Adafruit Remote Control parts due 15 Aug, and 3DHub case due 16 Aug.
17 August report: Fried Adafruit PowerBoost 1000 charger board due to confusion with the USB port sitting on top of the plus (+) and minus (-) sign printed underneath it. Reported this and spent a couple weeks testing connectors to determine PowerBoost board needed to be replaced. Got parts on 27 August.
23 August report: Built initial prototype integrated components and rig on top of tank wheel chassis. During this build, I upgraded fans from 5V to 12V and attached them to the Geekworm HAT. This change removed several wires and circuitry used to turn the fans on from the RPi. The other change was using the nylon spacers that worked nicely and avoided the Geekworm HAT failure that occurred using the metal spacers. And most annoyingly, the new RPi3B+ unit died while testing the Geekworm HAT PWM features for the 360 gimbal servo motor. Amazon.com gladly refunded my investment and I decided to use only RPi3B motherboards from now on.
27 August report: The ribbon cable pin broke on the remote control when attempting to remove the cable to install the replacement PowerBoost board. The display and touchscreen fail to work after attaching the back panel and the battery still does not charge.
28 August report: While experimenting with the MoPower UPS software interface, learned that the RPi 3B provides a CPU and GPU temperature value. That made my thermometer superfluous and after removing that additional circuitry, there are no GPIO pins required for this configuration. The two 12VDC fans work great in the Geekworm HAT.
31 August report: In an attempt to get support from Adafruit for their tablet tutorial products, I was banned from their site indefinitely and they refunded my last two order purchase amounts. That prompted me to write a physical letter to their support representatives to explain my attempts to sell their products in a brick and mortar store.
7 September report: A lot of time has passed since my last report, due to a lot of things happening and received. The rover is working consistently now ruuning off batteries. The gimbal is working with stepper motor operating the tilt operation and Ben Höller sent the revised base 3D printer file that has been printed and now needs to be whittled down. The scroll saw arrived yesterday and I cut the rim and camera base wood.
13 September report: Created my first 3D printer file for the gimbal board that drives the internal motors. After testing the gimbal during a trial run, there was damage inside that needs to be evaluated and corrected. Right now, it appears to be a config.txt file fix along with the hardware switches.
15 September report: Gimbal appears to be smoother but the switches did not work to calibrate the head and sounded like cracked some parts again. Decided to setup RPi 3B test system, again, to resolve the Gimbal issues and ordered the stepper motors and driver board to arrive Friday.
16 September report: Removed the Gimbal from the CPU and tested outside. Learned the batteries in the rear causes the chassis to fall backwards when attempting to roll over a front incline.
17 September report: Ordered AliExpress UPS power supplies because there has been no response from AllSpectrum regarding the MoPower UPS board that cost $55 for an early version. Also an overnight test proved the battery did not sustain the RPi and died at 1AM with no warning messages or shutdown info; had to reboot to restore. Since this is only one of a few alternative parts, I created a page to list the upcoming evaluations on this page. During this exercise, learned that MoPower UPS is overkill with 12VDC power supply where the only requirement is to run the RPi for the Wi-Fi and camera at 5V. This prompted a power supply redesign voltage downgrade to 5V as listed on the link above. For the 12V power requirements for the Motors, I decided to test a 10W 3.7V 4.2V Charger & 5V 6V 9V 12V Discharger Board DC-DC Converter Boost Step-up Module UPS Li-Ion LiPo lithium battery with 3.7V/2A Li-Ion batteries to install inside the front space under the rig.
18 September report: Was able to replace the broken ribbon cable lock on the RPi 2 Display Board and the remote control now boots with the back panel attached. The Adafruit PowerBoost board still does not charge the battery, so the replacement charger ordered yesterday will be the only hope for this current design. I also asked Bryce to send me the 3D printer STL files so I can fix some of his mis-measurements and add screw holes in the right place on the back panel.
19 September report: I received a Discord app invitation from dessant on #kivy-dev, joined, and installed the app to work with the kivy developers. This is a migration off freenode IRC to the Discord app most likely to prevent hackers dumping garbage in the chat sessions. During this exercise, learned about KivyMD and Google Material Design (MD) technology. Installed KivyMD-master and KivyMD-develop to test on Remote Control.
22 September report: After spending a day rebuilding the gimbal, tested it and it worked closer to expectation than before. Tested it again, this morning, to try calibrating the head to exact coordinates but it eventually failed and locked up, again. After examining the motor-free housing case, the problem appears to be caused by stepper motor gears problem. For more details, see
Gimbal Gears Analysis section below.
4 October report: As one can read, it’s about a week later I’m returning to write where we are today. Most of this time I spent upgrading the OS, watching the Upgrade movie to make notes for a review, and waiting for parts, of course. Because all of the platforms are affected at this point, I’ve made entries below based on the design changes to the rover and remote control tablet.
Gimbal: 28 September, received 3D printed parts and confirmed gears operate better and calibration was semi-successful. Because the power cable had a short in it, had to rebuild the power cable will fully test the gimbal in due time.
Power Supplies: 2 October, received one of two USB HAT boards in a damaged package, tested it on the tablet, fully charged the battery, and confirmed it is operational when disconnected from wall power. Currently in process to get replacement board that will be modified to fit inside the tablet case, which will need redesign if the battery and board need more room. 3 October, received battery charging circuitry and cables. These will be used to construct the battery power supply for the 12V needed to run the wheel motors.
Tablet Case: 28 September, received redesigned internal mounts and case lid with same parts as above. The new general and RPi mounts fit tightly into the case with the boards attached. The power microUSB connector moved, so exterior case had to be cut for cord access. This hole will change when tablet battery board arrives and can be modified to see if more space is needed for the HAT to fit. When fitting for the battery HAT, determined power switch will have to be a finger hole to turn on the battery operated device.
Ubuntu-Mate Migration: Because OpenCV is a required feature to make any object recognition sophistication possible and it failed many times to install on RPi 3B, I decided to go with the Ubuntu-Mate OS that had proven to work better than Raspbian OS and was updated regularly, along with the Ubuntu server versions. I tried the officially released version 16.04 but it failed to have the necessary openssl and nodejs software versions required by the streaming video services, picam and node-rtsp-rtmp-server run by coffee-script. On the day I learned this, RPi Foundation published How to upgrade to Ubuntu MATE 18.04 on the Raspberry Pi, in beta release, that gave me what we needed to support the streaming video. However, remote desktop (xrdp), which I use exclusively with the rover and some with the tablet, would not connect sessions after the upgrade. That prompted a search for a solution that Mathias Lindström found the final solution that worked for the rover. I didn’t need to upgrade the tablet because it ran fine with 16.04 and did not require the openssl or nodejs upgrades. Installed kivy and ran remote control app successfully.
Rover Rig Electronics: This redesign consists of replacing the MoPower UPS with a generic Chinese 5V UPS HAT, the Geekworm PWM/DC Motor board with the SB DC Motor board, and the Stepper Motor board where the holes are too close with a new one printed 28 September, same print as above. Because of the complexity and time required for this step, this reintegration work is postponed until final tests on the gimbal.
Gimbal Gears: Because the original polymer was PLA, I ordered the replacement Gear9 and Gear14 in the same material. Unfortunately, the stepper motors get very hot, too hot to handle, the shaft on the motor melted the plastic. So, based on Kyle Wiehe’s advice, switch the polymer to Nylon.
11 October report: Successfully tested redesigned rig with two motor boards, battery HAT, and 12V battery. Below is a list of changes that need to be completed:
1. Combine 12V inputs to one battery output, that is soldering three wires – DONE 10/13/18.
2. Cutout bottom of Rig Base to increase cable space – DONE 10/14/18.
3. Get M5x40mm bolts and nuts at Skycraft or Ace – DONE 10/12/18.
4. Pickup nylon gear9 and gear14 from Kyle – DONE 10/12/18.
5. Install new camera on Gimbal using existing holes, if possible – DONE 10/16/18.
6. Install dome and base on top of rover to confirm design – DONE 10/15/18.
7. Integrate temperature, battery, gimbal, and wheel code. Wheel code needs focused attention to calibrate motors equally – DONE 10/18/18.
8. Receive UPS HAT for tablet, bend and solder 5V/GND pins to display board, and clip all remaining GPIO pins off to fit under lid – DONE 10/16/18.
9. Reprint final gimbal base with correct holes aligned to front and back. Also print new base nut strap to mount upside down under base bolt – Ordered 10/17/18.
10. Write code to control rover from tablet.
18 October report – As seen in the checklist above, I have completed the first operational prototype now that the wheels are in sync and I implemented one-key control to turn the rover 90 degrees left and right, 180 degrees, and 360 degrees. Now don’t need the 360 gimbal rotation as much but this will be a good test bed for a different design using the same gimbal and hopefully camera. During this period, I learned that the right wheel kept coming loose so I’ve applied LockTite for screw threads to see if that will stop it from loosening. Created a Piece Parts Listing today in preparation for future publication (this is in addition to the ongoing Rover Prototype BOM Spreadsheet to track costs). I also removed the sensor_pin code from the ptzdriver.py and MotorSteppernoinit.py files. This was to remove any pin conflicts with the SBC Motor HAT (experienced some Segmentation Faults that are now gone).
23 October report – Picked up tablet case, yesterday, from Kyle and installed it to confirm openings are accurate, which they are with an exception of the HDMI connector opening that is about 2mm too far off on one side that the connector will not fit. The tablet is also shutting down on its own after a few minutes but not surprised with the loose fittings that need to be rebuilt with spacers. Ordered final wires with male/female connectors for wheels and fan. Next, I’ll be installing the CSI ribbon cable to the Stepper Motor Board. On Sunday, I attended the Maker Faire exhibitor’s orientation meeting and learned I have a lot of planning and work to do in the next few days (18).
25 October report – Spent yesterday solving a python3 problem with RPi.GPIO that I finally solved this morning as documented in this post. I spent the better part of today asking the forum where to post a solution and learned more about the hierarchy of Debian releases and support. Ubuntu releases the kernel portions of Debian and are also used by Raspbian. So, I wasn’t sure where to post or report the bug but got plenty of recommendations from different support reps. Ended up posting it on Ubuntu-mate-community (link above) and filed a bug report on Ubuntu bug tracking system (BTS). Also, started a OneNote page for Future Checklist of things to complete. When powering up the rover this afternoon, experienced a service failure for coffee service and determined npm had to be reinstalled. Below are the current list for the records:
1. This section is for the rover.
  1. 1. Install new 4-pin JST connectors and wires for Fans and Motor power.
  1. 1. Because it’s not powered, Move Stepper Motor Board to top of stack.
  1. 1. Install and get kuzeyron PH code working between new RPi-remote and rover.
  1. 1. Test and make turning work and abilities outdoors.
  1. 1. Replace acrylic sides and key with new cuts.
  1. Install camera attached to new head.
2. This section is for the remote control.
  1. 1. Change name on RPi 3B from rover to remote.
  1. 1. Install RPi 3B with spacers.
  1. Reprint case with HDMI hole larger.
27 October report – The last two days I spent resolving software problems, see below. The first was a file name problem used by a Ubuntu subprocess module for the GPIO interface that I just happened to realize because of another package that needed to be renamed, apt_pkg; I posted the solution to this on Ubuntu-Mate community forum. The second was a Kivy and Python3 startup problem because the correct 3.6.6 version of Python3 was incorrectly defined. After I found that solution yesterday morning, I posted it on the same site then rebuilt the tablet so the RPi mount did not short out on an underlying screw (I think I’ve fried another RPi, this time model 2 – it boots but doesn’t last long and eventually overheats and shuts down). In subsequent tests, the RPi3B tablet appears to be fully operational. Today’s plans include meeting Ian and crew from Maker Faire at Skycraft around 9AM and then getting the tablet and rover to talk to each other.
1. No module named RPi and RPi._GPIO and apt_pkg
2. Python3 ImportError: No module named ‘kivy._clock’
29 October report – Saturday I spent rebuilding the remote control tablet and testing the chat code that were then fully operational that evening. I also picked up a tee shirt, marketing lit, and giveaway items in the morning at Skycraft. Sunday was a productive day getting the remote control UI updated and operational. I found a site with hand-drawn arrows that gives the interface a more artistic appearance. This was at the recommendation of kuzeyron who informed me that the Kivy buttons have problems with positioning text characters and graphics are better. Of course, this opened another “can-of-worms” in that the graphics are also stretched and contorted based on how the graphic fits the button. So, it took some time how to widen the canvas so the graphics look professional and not contorted. Then, at the end of the day, kuzeyron was able to solve the problem between Kivy app and the kv file where Kivy was not being run when a button is pressed. The solution was to preface the call to the button’s routine with “app” so that Kivy knows which thing is supposed to handle the call. All the Kivy documentation that I could find said to use “root” as the prefix to the button’s routine. Now that that’s working, today is getting the rover and remote control code to communicate with each other and displaying the streaming video.
1 November report – Crashed and burned both OS environment trying to fix a python problem, late Tuesday afternoon. Now python3 doesn’t work on the rover and opencv can’t be imported on the remote control. During these last two days, kuzeyron talked me into trying Arch linux and after we finally got the OS to boot and upgrade, there was no user interface and the hurdles included learning all new commands, like pacman. Because of the looming deadline and now dead RPis, I spent Wednesday morning trying to get the Ubuntu-Mate installed and the afternoon installing Arch OS ready for full installation but did not want to invest more time with a whole new environment, although I will consider it seriously after the show. This consideration is because of the OS speed compared to Raspbian and Ubuntu-Mate. In addition, the graphics and mouse performance and behavior excelled over both of those OSes.
4 November report – Spent the last few day attempting to get Ubuntu-Mate to install opencv but it failed. Decided to move forward with Arch and so far it appears to be working better for the requirements we need for rover and remote control. Unfortunately, the is a problem with xrdp in the sessions management by vncserver and dbus sessions. Need to report this so it can get a solution so that I can use it for the rover. I have the touchscreen on the remote to see the graphics. I don’t have this for the rover and xrdp would make life a lot better, though still not required. During this time, I have spent hours pounding on the software to get at successful build and finally accomplished this yesterday, then something bombed and the chip would no longer boot. Today I’m spending to build another chip and ordered two more because before the final death of the chip, the tablet was rebooting when attempting to install numpy, required by opencv. Kuzeyron suggested using a new chip for the OS build, so I’m hoping the new chips will work better once I get a new install working. It is also concerning that the show is less than a week and I still don’t have a stable prototype.
7 November report – OS Success Today. Well, the roller coaster has begun. I let one friend know that I wasn’t attending the show, just so he knew to change his plans if it mattered. Then after three days trying to find the solution for installing kivy and opencv on Arch Linux ARM (alarm), kuzeyron stumbled upon the solution with the right commands to make it work. So now it’s back into high gear to finish and now is the time to list them.
1. Get opencv code to display video stream in kivy control panel.
2. Get chat session to communicate between rover and remote control.
3. Replace the generic Battery HAT with MakerFocus Battery HAT.
4. Move Stepper Motor board to top of stack.
  1. Install JST connectors for fans and wheels.
  2. Flip board and camera ribbon cable.
5. Field test and full system.
6. Install new camera and header on gimbal.
8 November report – today we made progress on a grand scale. The rig is disassembled, the 12VDC wire harness is complete, the rover and remote are talking to each other, the boards appear to be ready for installation, and the following now need to be completed, from the list above. Tomorrow we also need to setup loadin at site, pickup Layla’s meds, create the main poster banner, and pickup the printed literature.
1. Get opencv code to display video stream in kivy control panel.
2. Move Stepper Motor board to top of stack.
  1. Install JST connectors for fans and wheels.
  2. Flip board and camera ribbon cable.
3. Field test full system.
4. Install new camera and header on gimbal.
9 November report [posted to kuzeyron]- I’ve had to make a decision about the show. The list *to do* items is way too long for me to attempt to pull this all together at this late of a date. The hardware needs serious rewiring or use the old clunky connectors instead of jst 2.0 4-pin plugs and the software needs hand-shaking startup code plus all the wheels navigation, fan controls, and gimbal commands implemented. That’s just the product. All to do in one day. I also need to shoot the latest model, write descriptions, packup a booth worth of items, and setup the booth today for the show tomorrow. So, for the sake of the rover’s evolution into reality, I’d rather spend time making progress on it instead of promoting it too soon. If I could just pickup our living room and transport it there with curtains that only allow people to see me working on it, that would work but is impossible. If the show was next weekend, we could have made it. Unfortunately, this year is too soon for where we are. We did the best shot we could and I truly appreciate what we’ve accomplished so far. Our baby just isn’t ready to be born yet.
9 November report (PM-Continued) – Sent email to show managers and visited Fairgrounds to inform them that I would not be attending. Soldered both wheels and fans to 4-pin JST connectors and confirmed operational. During soldering wheel wires and removing electric tape labels, pulled a couple wires out of parallel lengths and will need to be replaced. During tests, glue popped on the wheel connector and had to be reglued, which appears to be working. Progress list update below:
1. Get opencv code to display video stream in kivy control panel – installed dev.
2. Move Stepper Motor board to top of stack – installed testing.
  1. Install JST connectors for fans and wheels – installed testing rewiring.
  2. Flip board and camera ribbon cable – TBD.
3. Field test full system – TBD.
4. Install new camera and header on gimbal – TBD.
11 November report – went to checkout MakerFaire show and wroteup an email description for Ariel, to answer his question about me enjoying the show. Short hand answer, yes, because of the education about the venue for next year. Today, I was able to combine the chat sessions using sockets and was able to receive the command values from chat_client.py as a string. The next step for tomorrow is adding the chat code to our kivy app to send the commands to the rover.
12 November report – Today was a productive and successful day and shows that I was only a few days away from being ready for the show, although defeaturized at this point. Today, the tablet UI worked for the very first time. The communications are handled in a chat session with WAK/ACK commands to synchronize the hardware operations with the remote control (this has yet to be implemented and tested). Both the fans ran using the new rover-server.py and wheels operated successfully remotely. The gimbal and camera do not work with this new configuration, although the gimbal hardware operates with python2, so something got hosed during the migration to python3 in the gimbal drivers. Also as part of this redesign version, I added the 4-pin connectors for the wheels and fans motors and heat shrinked them to reduce the clutter inside the rig.
1. Get opencv code to display video stream in kivy control panel – redesigned with gstreamer – Done 11/19/2018.
2. Move Stepper Motor board to top of stack – TBD.
  1. Install JST connectors for fans and wheels – Done 11/12/2018.
  2. Migrate stepper motor code to python3 – Done 11/15/2018.
  3. Flip board and camera ribbon cable – ribbon cable redesign needed.
3. NEW: Redesign UI for special wheel behaviors, like specific degree rotation – Done 11/18/2018.
  1. Align the Forward and Reverse Wheel icons centered – Done 11/13/2018.
  2. Add Stop Sign for middle wheel button – Done 11/13/2018.
4. NEW: Add new ribbon cable board to prevent curling cables over (see 2.3 above).
5. NEW: Lengthen the 12V cable so connector is accessible from outside.
6. Field test full system – TBD.
7. Install new camera and header on gimbal – TBD.
15 November report – Well, two days of debugging py2 and py3 code to find how it needed to be indented to operate correctly. Part of the problem was not with python3 but with the indent characters used by the author, especially one routine def that was indented inside another def routine. Once I had enough print statements in the code at the same level in both, I figured out the only way how it could execute in that order. The trickiest part was the code that started two pipes, one for each stepper motor that would then execute the code that had been indented within the same routine. Once I figured out the pipes were calling the move routine, it was only a matter of figuring out which move routine was being called and identifying it and the motors with “self.” The gimbal now works with rover-server.py but not with the remote (need to add logging to rover-server.py to see what is received). Now that I have spent this time gimbal, it’s time to catchup on yardwork. Item#2.2 above is now done. Purchased a new RPi3A+ that was announced today and available in December.
16 November report – During the end of day tests, rover app crashed on an invalid transmission from the remote with a camera button. This predicates the need to add logging to the rover app. In addition, more handshaking needs to occur so that both devices recognizes when the communications has stopped.
18 November report – Yesterday was a full day attempting to display rtsp video stream on the tablet that never happened. Using both Kivy VideoPlayer and OpenCV, neither was able to display real time video and next to the kivy control buttons. Kivy generates a file error with rtsp source and the OpenCV window crashes eventually due to buffer overrun caused by the delayed display, as well as showing 180,000 frames per second. Today we also learned that there is noise in the video which means there might be a hardware issue with the current configuration and the rebuild might fix this problem, we’ll see. These issues will need further investigation during the weekdays when resources might be available. Sunday turned out to be a test day and UI improvement day (which completes item #3 in the list above). Almost all features are working in tandem between the gimbal and the wheels simultaneously. There are still some refinements and maybe more data handshaking might be necessary to tighten the communications between the devices with reset/restart capabilities. Need to add 180 degree back camera pan support to rover-server.py, test/finetune the left and right wheel turn feature, and change 90 degree rover left/right turns to 45 degrees.
19 November report – Major progress day, primarily on the tablet. In one day, I created all graphic button images with beveled edges, configured gstreamer to play the rtsp streaming video on the display next to the buttons, and kuzeyron edited our RemoteControl.kv file so that the GridLayout sizes increased the video display and tightened the buttons. Like so…
21 November report – today I learned I have infected sinuses and rushed to the pharmacy to get Flonase and Zyrtec. This all made me feel drowsy but I still pounded on the keyboards to make progress, which was small today. I enlarged the button graphics to be easier to read and consistent in size. Because I’ve had to use my iPhone camera to shoot the tablet screen, I decided to implement the camera snapshot and screen capture features. I tried to add buttons beneath the video window but that hosed up too many things. I then decided to add the code to the camera Front and Calibrate buttons. This means the Camera Front button to capture the current video frame displayed and the Calibrate Camera button to capture the whole screen before sending the calibrate command. Below is an example of the two shots (I found out the hard way that the power extension cord was unplugged and realized why when I saw the 25% battery capacity):
Here is the new list of todo items, primarily hardware and software tests and final feature enhancements:
1. Finish Remote Control Arch Linux ARM and test on RPi3A+ – Done 12/04/18.
  1. Remove LXDE from boot and autostart main app – Done 12/04/18.
2. Add R/RC negative 1 capacity value when Power HAT fails with invalid capacity – Done.
3. Migrate Rover from Ubuntu-Mate to Arch Linux ARM and test on RPi3A+ – Done 12/05/18.
4. Reconfigure Remote Control and backup chip – All Done 12/04/18:
  1. Add heat sinks – Done, although only one fit and stresses the batt HAT.
  2. Glue CPU board spacers to mount – Done.
5. Add temperature logging in Rover app like Remote Control- Done 12/07/18.
6. R/RC Software Enhancements:
  1. Test and implement procedures for reliable WAK/ACK processing.
  2. Add ping function to R/RC apps.
  3. Reorganize folders on R/RC to same /home structure:
    1. apps – Services apps folder
    2. build – download/install folder and main apps
    3. remote/rover_logs
  4. Add local video recording feature in Remote Control app.
7. Finish implementing apps wheel controls for turns and 45 degree buttons – getting close as of 24 Nov.
8. Reconfigure rig hardware components:
  1. Replace RPi3B with RPi3A+.
  2. Add new ribbon cable board to prevent curling cables over.
  3. Change-out top nylon spacer with brass and glue to gimbal.
  4. Pull UBEC out of base for easier access and relief it.
  5. Lengthen the 12V cable so connector is accessible from outside.
9. Field test full system – this includes hotspot testing outside our LAN.
10. Install new camera and header on gimbal.
23 November AM report – late yesterday afternoon the tablet started reboot itself during a boot sequence multiple time until it finally made it to the desktop. Then when I started the remote control app, the system would power off. I was so pissed I packed the tablet away for the evening. This morning during meditation time, I realized I should unplug the battery to reset the power HAT. Guess what. That worked to fix the boot sequence; however, when I started the app, it shutdown the RPi. So, I checked the batt_cap.txt file and found 0 in it. That was what was causing the shutdown in my app. I then realized that after resetting the power to the board from the battery removal, I also needed to reset the i2c mode to get the capacity amount. Duh. So, I added the ic2set code that enables the register read that the battemp-start service uses to store in the batt_cap.txt file. Now all is back to operational.
24 November report – yesterday spent most of the day testing the communications and handshaking to learn there is package droppage occurring in the sockets. Need to do further tests to see if there is a more reliable configuration than currently defaulted to. The problem is that some rover_server routines attempt to send commands but they never arrive in the tablet but are recorded as completed in the log. This is using the sample educational app I found online. Sometimes these just work sporadically because time was not spent finding the most reliable solution. If I cannot find a configuration option to improve the reliability, I may need to write a timed send function that will wait for an ACK from the tablet before completing. Hopefully then this code will be reliable; otherwise, it’ll be time to go shopping for another example socket communications function.
1 December report – Haven’t done much on the Rover and Remote Control (R/RC) because of household projects such as removing plant tubers from the back yard, repairing a faulty plumbing job, and installing the new replacement water filter. During this time, the Rover died and had to be hard booted because even a ping would not be answered, which made me think the Wi-Fi might have failed. The camera and RPi lights were flashing as if they were operational, just no communications. I also started on the R/RC System Design document that describes the boot modules started as systemd services.
4 December report – Cleanup and finalization day. Today I finished the NetworkManager configuration to auto-start the Remote Control main.py app after all the network connections are operational. Just now, I realized I haven’t reported for a few days and thought I should report what kuzeyron and I accomplished, starting from scratch. Using the exton branch of Arch Linux ARM (ALARM), I created the boot image and partitioned the sdcard to 8GB. I then configured the system using a RPi3B attached to our HDMI TV until I could configure the system remotely with PuTTY and FileZilla, which was a recent epiphany to use, now that the tablet has no head. Once we had an operational OS, I backed it up then installed kivy. Turned out the ALARM version was outdated and ended up using the github version and installed kivy using setup.py. Once that installed tested well with the kivycatalog example app, I created the screen-start.service script and enabled it. Well, systemd is a fine auto-start feature in Linux. Unfortunately, it requires additional apps (aka services) to support more complicated dependencies from services, which is how we ended up with NetworkManager to support network-online.target trigger to start main.py. Once this was working, I backed up the sdcard as a boot image. Then, I testing installing npm on ALARM and it installed. So, I need to consider building a rover version of ALARM to see if picam and node-rtsp-rtmp-server will work. Then, it will be a question of a headless rover as well. Stay tuned.
7 December report – Today was another major accomplishment day to get the wheels turning properly using the keyboard, not the tablet. Because many features have been completed in the list from #61 above, I’ve repeated below what is yet to be accomplished.
1. R/RC Software Enhancements:
  1. Test and implement procedures for reliable WAK/ACK processing – Done 12/14/18.
  2. Implement Speed Slider control on R/RC apps – Done 12/08/18.
  3. Fix Gimbal Left/Right and Up/Down buttons on Remote Control – appear to be magically working, again. Don’t know why sometimes not working.
  4. Add ping function to both apps – Done 12/14/18.
  5. Reorganize folders on R/RC to same /home structure – Done 12/09/18:
    1. apps – Services apps folder
    2. build – download/install folder and main apps for dev
    3. remote/rover_logs
  6. Fix ‘Received socket msg: rover: WAKrover: ACK’ sent by Remote – Done 12/14/18.
  7. Add local video recording feature in both apps (R record, RC UI).
2. Finish implementing apps wheel controls for turns and 45 degree buttons – getting close as of 12/07/18.
3. Reconfigure rig hardware components:
  1. Replace RPi3B with RPi3A+.
  2. Add new ribbon cable board to prevent curling cables over.
  3. Change-out top nylon spacer with brass and glue to gimbal.
  4. Pull UBEC out of base for easier access and relief it.
  5. Lengthen the 12V cable so connector is accessible from outside.
4. Field test full system – this includes hotspot testing outside our LAN.
5. Install new camera and header on gimbal.
9 December report – More WAK/ACK tests proved to be working after basics tests with chat_client.py running on both RPis. The start of the day was asking #archlinux-arm chatroom guests why our comm-start.service was starting before the system clock was set, thus causing a filename anomaly using an invalid system date/time. It took one of the #archlinux-arm guest, Xogium, to ask someone in the #systemd chatroom to get a solution to this problem. Fortunately the solution was to enable systemd-time-wait-sync.service and add Requires/After time-sync.target(s) to my systemd file: comm-start.service. Demize offered this solution and it worked the first time. Because Charles my haircutter needed help with his Windoze PC, I had to break for the day to find a solution for his D.E.A.D. HDD. Once again, a failed Western Digital drive that shows the value of cloud drives for reliable storage. As for the WAK/ACK tests, both R/RC have been running all afternoon and everything still works.
11 December report – Today was a turning point for the gimbal and wheel motor communications because they interfered with each other when responding with an ACK indicating a job had been completed. After consulting kuzeyron, I decided to separate the gimbal and wheel motors communications channels so that they operated independently, thus waiting for its own completion instead of the other’s completion ACK. In short, this gives each device its own communication channel to send and receive commands and completion notices, respectively. Also today, decided to move the main apps (rover: rover-server.py, remote: main.py) to a new app folder. This prompted me to change the apps folder name to services, which I’ve yet to do. I have tested the new app folder and it works. I need to change the apps folder name to services to test next. The reason for doing this is to reduce the backup process time and files-not-needed from the /home/build folder and just backup the app, services, and logs folders for the R/RC backups. So, hopefully tomorrow I can test these final changes then rebuild the rig as in the action items to do.
12 December report – I’ve made more progress and have learned more about the common variables that are being used on both the rover and the remote control apps. These apps both need to have isolated variables per device. I fixed the RC app and now needs to do the same thing with the rover-server.py app. Otherwise, the apps are working better with ping and ACK tests during startup as well as prior to sending commands. I also renamed the apps folder to services and tested all works.
16 December report – Geeze, it’s been four days since I last reported. During this time I spent a day researching how to capture the screen and take a still shot of the video. The original code worked when I had configured Arch with a user and desktop but now without that, it was generating a “cannot open display” warning and not capturing the screen. Kuzeyron suggested it needed a window manager and that’s what I spent a day trying to configure. Finally, kuzeyron shared my code where I used export_to_png in the Camera Home button on_press, which was working. That’s when kuzeyron and I figured out how to get three buttons below the video window so I could dedicate them to record video, capture the screen shot, and snapshot a video frame. Instead of capturing streaming video on the tablet at 500×282, the rover will record the video for one minute max using picam by the tablet sending the rover a command to start recording. If the user presses the button again, the recording will be stopped and saved with the date/time in the filename. I also learned from MakerFocus that their board is defective and will be shipping a replacement in 15-25 days. I also designed a new tablet case (see in design notes – based on ThingIverse.com repository), submitted it to 3DHubs.com and FluxDesign (received an email from TreatStock that Walter’s World will generate the parts – I wrote back to replace the case with the one attached to my message) to be 3D printed. Because of these software implementations, I’ve pasted the ongoing action items list below:
1. R/RC Software Enhancements:
  1. Add Rover battery channel and convert to icon – Done 12/19/18.
  2. Add Rover video recording feature in both apps (R record, RC UI) – Done 12/23/18.
  3. Add Rover record comm channel for video/still capture commands – Done 12/23/18.
  4. Enhance video still capture by using picam and save it on the rover, like video recording – Done 12/23/18.
  5. Test 1920×1080 with picam option -w 1920 -h 1080 (see #71 below) – Done 12/24/18.
  6. Add Rover shutdown sequence with {quit} and log – Done 12/22/18.
2. Finish implementing apps wheel controls for turns and 45 degree buttons – getting close as of 12/07/18.
3. Waiting for RPi UPS HAT replacement due 1-25 January.
4. Waiting for 3D Printer quote and new tablet parts.
5. Reconfigure rig hardware components:
  1. Replace RPi3B with RPi3A+.
  2. Add new ribbon cable board to prevent curling cables over.
  3. Change-out top nylon spacer with brass and glue to gimbal.
  4. Pull UBEC out of base for easier access and relief it.
  5. Lengthen the 12V cable so connector is accessible from outside.
6. Field test full system – this includes hotspot testing outside our LAN.
7. Install new camera and header on gimbal.
20 December report – Yet another three days have past without me reporting. This time I spent adding the battery channel and processing to RC display, fixing the case_v1.stl file, and redesigned the UI in the video column. I also spent a fair amount of time correcting the case design file that failed to combine the top piece with the main case. I was only able to do this today going back and forth between MeshMixer and 123D Design. The first batch of parts arrived today and initial review looks correct. Also, started implementation of Rover video recording and determine 1 minute will be about 15MB. Just learned why the Rover picam is streaming 1280×720 which is good for now (see below indented). Need to test 1920×1080 to see if tablet can handle that resolution.
- Usage: picam -w 1920 -h 1080Options:-w, –width in pixels (default: 1280)-h, –height in pixels (default: 720)
24 December report – The last three days, I cleaned up the communications and implemented the Rover video and still shot recording features. Then, yesterday, I spent the afternoon learning Red Dead Redemption 2 so I could start playing the game around 4PM. This morning I tested the picam increased resolution but the displayed video stream has zoomed into the picture although it transmits at 1920×1080 based on what Digital Watchdog Spectrum reported. So, more research is necessary to fix the video image. Below is the latest action items list based on completion today:
1. Research 1920×1080 with picam option -w 1920 -h 1080 – Done 12/24/18. There is a problem with the image size displayed 200% but works and DW Spectrum reported 1920×1080 resolution. Did not test on remote – Dropping this for now 01/01/19.
2. Wait for new tablet case – Done 12/26/18.
3. Confirm or write code to unschedule clock after user presses video_rec STOP – Done 12/26/18.
4. Implement comm channel restarts automatically on R/RC.
5. Remove rover battery routine from main.py and create a new service to save capacity in file to read from main.py – Done 01/01/19.
6. Finish implementing apps wheel controls for turns and 45 degree buttons – getting close as of 12/07/18.
7. Wait for RPi UPS HAT replacement due 1-25 January.
8. Reconfigure rig hardware components:
  1. Replace RPi3B with RPi3A+.
  2. Add new ribbon cable board to prevent curling cables over.
  3. Change-out top nylon spacer with brass and glue to gimbal.
  4. Pull UBEC out of base for easier access and relief it.
  5. Lengthen the 12V cable so connector is accessible from outside.
9. Field test full system – this includes hotspot testing outside our LAN.
10. Install new camera and header on gimbal.
26 December report – I’m reporting today after two days practicing with RDR2 but wanted to give a status on a few things that happened since xmas eve. One relative to the rover is that I’ve learned the difference between FPV and third person with camera lens in games and drones. I couldn’t understand why the RDR2 camera pan was backwards: they treat it like a video camera aim stick, thus push/pull the back of the camera. With FPV, the push/pull is at the lens, not the back of the camera. The rover will only be FPV, obviously, but it was an interesting learning experience. The tablet case part arrived today. Another significant recommendation from Claudio was changing the UIX to be more like the picture below. But before that picture, Kuzeyron shared this code below to use when the user presses one of the circular navigation/gimbal overlay buttons:
- while CALL_ME:
  - self.ids.coord = mypos
27 December report – Today I whittled and drilled the tablet parts to get it back up and running. This morning I created a new rover battery service that polls the rover every 5 seconds to get the current battery capacity and saves it in batt_cap-rover.txt for the main.py program to read and display, instead of doing this inside the kivy loop. That’s because I was warned to not use time.sleep() in the kivy event loop because it will cause problems. Now that I have the tablet back up and running with the new case, I can proceed to test the new rover battery script rover_battery_log.py that I wrote and tested on the laptop. As for the new tablet case, it needs some more work on the print file to cleanup some of the accuracy of the mount guides inside the outside case. While attempting to snap the touchscreen into place, a loose spacer cause me to break the corner of the screen but it did not cause any failures; it is only a cosmetic issue and the touchscreen still operates as expected.
28 December report – Tested new Rover Battery Logging and decided to add comm servers for the Record, Gimbal, Battery, and Wheels/Motors (RGBW). These services will all record the latest transmission and check for no response from the Rover after 20 seconds. At that point, the service will write ‘alert’ into the last transmission file so the main app can handle the UI and the service will attempt to close and reopen the socket. This obviously assumes the complement to that is the Rover will also will now recognize the same outage and restart the RGBW services accordingly. The Remote Control’s app will determine the RoverIconRGBW.PNG where the top and bottom quadrants will show red background in the RGBW corners, one in each. Here’s how it looks:
1 January report – I’ve spent the last few days testing; decided to leave the Record, Gimbal, and Motors/Wheels in main.py for now; designed a button for the third version and submitted to Kris Walter; and implementing the communications channels UI, as described 28 December above. Testing consisted of the power supply on the Rover’s RPi3A+ that exhibited the same symptoms as the Remote Control’s. Then during these tests, I installed the RPi3A+ without the touchscreen but using the UPS power supply board with the HDMI output to the TV. That did not exhibit the same reboot reboots and successfully booted every time. I need to report this to MakerFocus to suggest the problem is caused by the touchscreen. As for the third version case design, I created several prototypes in various sizes and membranes based on Kris’s suggestions. I sent these in hopes to test the power button, but it failed to print operational.
1. Wait for new tablet case and RPi mount panel due 3 January.
2. Implement comm channel online/offline indicators on RoverIcon – Done 01/01/19.
3. Implement comm channel restarts automatically on R/RC – needs design spec.
4. Remove rover battery routine from main.py and create a new service to save capacity in file to read from main.py – Done 01/01/19.
5. Finish implementing apps wheel controls for turns and 45 degree buttons – getting close as of 12/07/18.
6. Wait for RPi UPS HAT replacement due 1-25 January.
7. Reconfigure rig hardware components:
  1. Replace RPi3B with RPi3A+.
  2. Add new ribbon cable board to prevent curling cables over.
  3. Change-out top nylon spacer with brass and glue to gimbal.
  4. Pull UBEC out of base for easier access and relief it.
  5. Lengthen the 12V cable so connector is accessible from outside.
8. Field test full system – this includes hotspot testing outside our LAN.
9. Install new camera and header on gimbal.
3 January report – I spent yesterday debugging the Battery Server code on R/RC and attempting to remove the broadcast send to all clients, unsuccessfully. I was able to get the Rover’s Battery client to restart on the Remote app and added code to the main.py ping routines to attempt restarting the RGW sockets after a ping fails for 20 seconds (4 ping timeouts). The new version 2 case and back panel arrived today and is much closer to the final design, with a few edges that needed sanding. There is a problem with the bezel around the touchscreen where the printer apparently didn’t smoothly fill the edges. I also sent an email to MakerFocus regarding the touchscreen power issue (although I erroneously reported the power needs to be supplied or it won’t boot, when the opposite is true). Then my final tests for the ping timeout restart code failed due to float object not accurate, so there’s a python issue in sending parameters to the restart_socket routine. This limitation caused me to separate the code so each routine handled its channel to restart.
5 January report – Yesterday I sanded the case to be fit for migrating the previous configuration to the new version. Looks good. Spent the rest of the time testing the restart comm across all channels and then implementing a version of the code to restart the services should the remote drop sockets. Still needs more work.
8 January report – Today I finally finished the socket restart so that if there are any droppage, both R/RC can recover cleanly. The final problem was the service startup time that needed to sleep longer for the service to accept connections. I have also heard back from Kris Walter saying he cannot print the membrane due to breakage removing from the build plate. Later today, after endurance testing, I will rebuild the tablet to see how well the new parts work.
20 January report – Yes, it has been almost two weeks since I’ve reported any updates. During this time, I’ve spent working on two other projects: genealogy and Claudio proof read. The R/RC has made some progress with the latest case after testing the blue UPS board that would have required a case back redesign to turn the board so the power switch is not on the bottom. After failing to obtain a replacement red UPS board from MakerFocus, I decided to request a refund which they did. Then the red UPS board started booting correctly, especially when the screen is powered using USB cable instead of the GPIO pins. I’ve ordered a right/left angled cable to improve the power quality to the screen. AI Completions: #1 New case and panel appear to be fine with fewer sanding correction, and #3 Implement comm channel restarts automatically on R/RC. Today, plans are to test the R/RC in the front yard and take pictures and video.
23 January report – successful field tests today and Rover made it across dead grass and back as well as other maneuvers. Need to increase speed with 180 degree turn around that failed today. Gimbal also encountered a socket failure when receiving packet. Weather has been a limiting factor with rain and wind.
26 January report – Yesterday, field tested and shot video (below) but the video stream has a horrible horizontal lines across the screen. During test, also noticed the 45 degree left/right stops the rover once complete where it should return back to current_speed. So now it becomes mandatory to rebuild the stack, replace the ribbon cable adapter, and lengthen the DC Motor Board power cable, as described in the Action Items list, #7, above.
27 January report – Today was productive and have updated the Action Items list below. I also need to update the system documentation with a diagram of the services. It also rained today, so field tests have been postponed, as well as the 12V battery problem that started after rebuilding the rig HW. Also today, created a Ubuntu-Mate chip to start the SlideShow rebuild process. See pictures in section below for Version 10.
1. Wait for newest tablet case and RPi panel for USB power – due 30 January.
2. Fix wheel controls for turns and 45 degree buttons – Done 1/27.
3. Reconfigure rig hardware components: Done 1/27.
  1. Replace RPi3B with RPi3A+. Done 1/27.
  2. Add new ribbon cable board to prevent curling cables over. Done 1/27.
  3. Change-out top nylon spacer with brass and glue to gimbal. N/A
  4. Pull UBEC out of base for easier access and relief it. Done 1/27.
  5. Lengthen the 12V cable so connector accessible from outside. Done 1/27.
4. Appear to have a 12V battery problem with too low power to operate motors.
5. Field test full system – this includes hotspot testing outside our LAN.
6. Install new camera and header on gimbal.
1 February report – The last few days I’ve spent shooting video of the R/RC as part of the field trials that completed somewhat successfully. One anomaly I fixed today was the Remote Control RPi crashing and removing the battemp and rover battery files that I added code to confirm a default file for main.py operations when missing. Need to do this file corruption fix on Rover too. Next few days are waiting for a higher capacity and current battery so the video streams on the tablet with and without shore power as well as editing video for an early promo piece.
7 February report – Due to Google deprecating the photos API I had been using for the SlideShow app, I’m spending time migrating the RPi and Android apps to the new API. During this time, I’m also standardizing on how the authorization processes are handled in a common routine. The R/RC is on hold for now.
3 March report – Wow, it’s been a month and I’ve mostly spent this time testing OSes to see if they’ll run the SlideShow app, just like I reported a month ago. In the slow times, like waiting for installs to complete, I have made some progress on the R/RC, most notably the upgraded battery to 5mA, USB male cable from RC RPi to video driver board, and most significantly a /boot/config.txt line that doubles the power to the USB port and thus the video driver board. What this solved was the video had stopped playing real time due to low power and with the USB power and software power doubling, it now displays video in real time, except when any of the channels are down, their recovery affects the refresh during channel communications timeout situations. I also posted a DIY recommendation about this configuration on the Raspberry Pi organization’s forum. Yesterday turned out to be a second day of part and app failures. Two days ago during my tests, the battery stopped working and the Rover server code got hung in a loop shutting down the wheel unexpectedly. The cause was my systemd code that ran the server app but errored out and gracefully shutdown all the motors. Then systemd auto-started it, as I requested, and it kept stopping all the motors. I’ve yet to address the battery but today I did code the server to auto-start at boot. The other main feature I was attempting yesterday was to implement the hotspot feature in the rover and remote so I can take it outside our network to test. I decided to do this using the spare RPi board to code dnsmasq and hostapd to then migrate to the R/RC. The second part of the bad day yesterday was the Remote totally stopped communications on Wi-Fi. That meant I had to restore a previous backup on the RPi microSD card. Fortunately, I had a backup from a week ago and it worked. During this restoration, I took new pictures of the internal components and posted them below. Full system (minus battery anomaly) up and running again.
4 March report – I double checked our findings about the UBEC and reported the failure to the vendor YoungRC and ordered a different UBEC part from banggood. This will probably take two weeks for a replacement and that means no field tests any time soon. The other major design change I made today was to flip the screen again 180 degrees so the new chip access opening is pointing down instead of exposing the internal electronic components to possible moisture exposure and also orients the back plate Raspberry Pi logo in the correct position.
15 March report – The Ides of March – “the last 5% takes up 90% of time” is my mantra and has turned to be true. Part of that time is spent waiting for single points of failure parts, like the two UBEC that were shipped the beginning of March. It took 3 days for the replacement UBEC to clear US customs – a no charge product. And I have been working on household chores. But the biggest time consumer was all the old online documentation that has become obsolete as the OSes and repositories have evolved to omit unnecessary code. That is what took time experimenting with the Wi-Fi network across wired Ethernet connections. This research took many trials and reverting back to previous versions of OS builds on chips. Today is the first day to test the configuration that has worked when the Goddard Wi-Fi Network access point rebooted and the R/RC continued to ping each other during the boot process. This confirmed the concept works but today will be the day to determine if all the network streaming and sockets continue to work on the subnet (term used loosely). The concept is that the Rover will always boot on the Goddard Wi-Fi Network and start watching for the Remote Control to join the Wi-Fi network as ‘remote-ap.’ Once the Rover sees remote-ap, it will immediately switch over to that network until it goes offline again and will switch back to the Goddard Wi-Fi Network. See here for more details.
21 March report – received Banggood UBEC on Tuesday, installed and tested it successfully worked, received YoungRC replacement UBEC and packed it away, received HooToo miniature router, and started configuring the Rover to connect to it, so far without success. This required wpa_supplicant that I’ve avoided to this point.
23 March report – received HooToo miniature Wi-Fi router on Thursday and spent all day Friday configuring it to work in our LAN, which it finally did work with the Remote Control dev system. Today I’m migrating the Rover dev system onto the new Rover Wi-Fi Network SSID. Once I get that working, my next job is changing all the R/RC apps to use the new IP addresses, provided by the new mini-me router. By the end of the day, the R/RC were fully operational on the new mini-me network.
24 March report – Finished integrating the HooToo router inside the rig with Velco squares for easy removal and replacement. However, when starting to reboot the Rover, I realized each time I do that now, the router is also rebooted. Fortunately, I purchased a cable that can be attached to the power board that should not power off the connector during RPi reboot. I will be testing that in the next few days. Until then, I just leave the Rover running continuously. In addition, the new router will change IP addresses over time, so I had to add code to arp (address reverse protocol) to determine the opposite device’s IP address. During this bug fix, I determined a couple things need to be tested and debugged:
1. All module’s communications reliability and restart – had a battery service stop reboot due to continuing to restart – need to confirm restart on failure.
2. Remote Controller boot files for temp and capacity – currently crashes app on startup when missing.
30 March report – The new HooToo mini-me wifi router dropped connections when the internet was disconnected and there was no way around that. Made me so mad but I returned it for full refund. The TP-Link router sucks so much power off both the RPi and the UPS HAT that it caused the RPi to reboot after fully up and streaming video. So, I drove to WalMart and found a $10 mobile device battery that almost worked for what I needed. Turns out the new TP-Link mini-me wifi router draws so much power that the battery doesn’t give it enough juice and the router keeps rebooting, when power input is connected to the battery from RPi. If I remove that connector, the router works with just the battery and without rebooting. So, that means this little component, the mini-me router + battery are now a module that slides into the rover base, independent of the RPi rig connections but has to have its own charger when not in the field. Kuzeyron replied, “You should do something about it. From 1 battery it charges the rest.” I replied, “I’m using a 2amp (3.7v) battery in the remote that might have enough juice to power the UPS HAT and mobile router battery. I’ll have to order one to see if it works (edit: ordered 31 March). Then I won’t have to use shore power to charge the mobile router battery. Good thinking!” The current UPS HAT has a 3.7v 1a battery. Upping the amps on that for the remote fixed the pausing video problem. Now the problem is the 2amp battery is longer and wider so I’ll have to figure out how to mount it with the stack-o-boards. Today was the first successful day of field test for the new wifi router + battery module. Field Test Results: Operations as expected however range was very limited, roughly 25 feet. There might be operator errors or UI bugs with this and further investigation is needed. Batteries: 30 minute test at home, one block for wifi test in car, and Trotter’s field park results, all starting at 100% capacity:
- Remote Control down to 81%.
- Rover CPU down to 60%.
- Rover Wi-Fi Router down to 91%.
1 April report – No April Fool’s Day incidents but did get the wifi router configured to reboot the Rover should it stop pinging. Tried all day to get the systemd services to restart but was not able to get the router to respond to ping after reboot.
2 April report – Spent most of morning and early afternoon preparing some comparable components for the Rover Prototype 2 build. This consisted of wheel chassis, UPS HAT, and DC Motor boards. Decided on a Your Cee wheel chassis because the front and rear are flat straight cuts and the tires appear convex and have 6 treads instead of 4. The rest are probably going to be SB Components Motor boards and Teamdewhole Technology Co., Ltd. from AliExpress. Also today, I got a message from Amazon.com that the 5A battery and TV remote control are arriving today – that means my free shipping expected 5-8 days turned out to be a two day delivery. Now that the battery arrived, I’m rebuilding the rig for the last time before field tests at our friend Don’s “ranch.” This will include the following changes (removed this as iii for later when new shorter ribbon cable arrives: Replace gimbal head with new camera gimbal head and camera):
1. 1. Replace 2500mAh battery with 5000mAh battery – requires spacer.
  2. Mark the motor 4 pin connectors with black and blue ink.
6 April report – Can’t believe it’s been 4 days since last reporting. I’ve been busy with Prototype #2, rig updates completed from 2 April report, the 5000mAh battery was not sufficient and Wi-Fi router rebooted when connected to UPS power supply, received and tested NEW UPS power board (that has no readable values – returning product after GPS tests), started GPS installation and interface, and learned RPi apps must have internet access to get date/time from Internet and Wi-Fi router cannot provide date/time (per chat with TP-Link rep). This last issue requires a way for both R/RC to get date/time without Internet access. This may require the GPS to provide network date/time on boot.That is now our primary issue for the private network to reboot: Real Time Clock.
10 April report – Well, once again 4 days later… I’ve spent the last few days getting the GPS to work and it does now on the Rover-dev system. This works with NTP and can be a server; however, the Remote Control requires ALARM 4.19 but when installed on RC, the video drops frames and it appears like slow motion. No response to my request for advice on #ALARM and decided to solve the field boot problem (without Internet connection to get NTP pool time from servers) by writing code. Next step is to get the Remote Control to use that GPS UTC date/time to start the R/RC apps during boot. This is not a Prototype #2 requirement but just to get this feature to operate in the field without internet connection, which may prove useful in a future Rover field crash situation (after manual restart intervention). So, the R/RC will now have yet another socket for GPS communications and possibly future GPS/cell phone requirements. Also, a few days ago, ordered 2 x wheel bases, backup UBEC part, and 2 x UPS HATs, for Prototype #2 because I received an email saying prices will be increasing on the 9th. These should arrive around the first of May.

11 April report – Got email from AliExpress vendor saying no UPS power boards, will refund purchase amount, so I ordered the same product from a different vendor. Rough R/RC startup this morning with what appears to be a mini-me drop out during the night. During this time tested the kuman UPS Battery Pack Expansion Board Power Supply and found it has no python interface so no way to determine battery capacity, so returned for refund. Have created list below to debug ASAP:

1. Fix repeated ping failure on Rover for all services.
2. Confirm Wi-Fi router reboot handled by Rover – didn’t work during tests – Done, 4/12/19 – Needed to enable wifi-manager.service.
3. Finish RC datetime sync sockets and migrate dev code to Rover – Operational with Internet connected router. Still needs to be debugged for field boot.
4. Install GPS wiring and mounting bracket – Done 4/13/19.
5. Fix RC code rover_comm.txt missing file error handling when missing – Done 4/12/19 – added code to create file with default value, needed contents corrected too.
6. Figure out why the RC battery socket doesn’t startup all the time – need to add ping code like in rover_server.py.

13 April report – Got email from vendor saying to cancel the order again after the first time I selected “out-of-stock” product based on their email. Today, went to update the order and asked Steve from the AliExpress support rep who asked me to report the vendor, which I did. Then when I went in to cancel the order, it showed it had shipped and was in the US. So, I have no idea what is going on with the UPS HAT from Teamdewhole. Might be here in 2 days from DHL, per their website. Had to cancel other vendor’s product I ordered because of this stupid out-of-stock/failed quality tests issue. As for progress, made final systemd-timesyncd work with the GPS NTP server on the dev system. Yesterday, received a lot of good help from damjan and Xogium on the #systemd channel. Today will migrate the dev system onto the Rover chip to confirm it all works before integrating the GPS hardware into the rig (items #3 and #4 above).
16 April report – Once again surprised to see it’s been 3 days since my last report. This time I’ve been battling AliExpress and their UPS HAT board seller incompetence and wrote them a nasty letter that pretty much details the problems and expected results. Yesterday, I finished the GPS integration into the R/RC but still need to test it without Wi-Fi. Although it works in each of my test environments, it’s amazing how many trial-and-error tests need to be completed for some slight difference in the OS, MAC addresses, IP addresses, RPi 3B and 3A+ CPU versions, and the mini-me Wi-Fi router. As I wrote Claudio, “I had to add more wires to the Rover CPU board for it to power and talk to the GPS along with talking to the wheel motors, gimbal motors, video capturing, and battery capacity sockets. This was where the dev/test system proved its value so the GPS was isolated and I didn’t have to deal with other features impacting the over-and-over testing.” During these last few days, I was able to complete some of the fix list items in #97 above, and have noted them there.
24 April report – A lot has happened, mostly for the positive but definitely slowed R/RC dev down the last few days. Spring cleaning and yard work took a precedence due to the cool weather. Yesterday, received the v2.0 wheel bases from China and they look good, shipped TP-Link travel router back to vendor, got hostapd to work on comm-dev RPi3A+ using create_ap (this replaces the mini-me router), and the power dropout on the UPS HATs is causing issues with the RPi reboot. Have researched power supplies because this could be the cause of the board reboot as well as high enough amps. As for the next steps, it’s a matter of integrating the create_ap and GPS NTP service onto the Rover Wi-Fi Network subnet. This requires burning a chip with the ALARM image, installing several packages on the RPi3B chip while on Ethernet port, and then running it on the RPi3A+ (sans Ethernet) after operational on RPi3B. Still waiting UBEC (unknown arrival date, no tracking) and 18″ camera ribbon cable (due 2 May).
28 April report – Succeeded creating the Communications Rig to handle GPS for time services and setting Rover and Remote Control time synchronization on the 10.10.10.x subnet. There still needs some cleanup work in the rover_server.py code to reduce the number of repeat entries, like when the RC is no longer responding. In addition, need to research how to use the 5GHz Wi-Fi to stream the video that appears to be dropping frames. During tests, Rover rebooted in a few minutes that stopped rebooting when 5V3A power supply used. Need to try a 5V4A power supply to see if that resolves the RC rebooting when power plug inserted.
1 May report – Yesterday was an outside test day with the new communications rig and it worked for about 25 feet then the rover failed to respond to the RC. This could be due to code problems that will require more research and analysis of what is happening in the communications. Based on past logs, it could be hung in some kind of loop sending a bunch of crap, as shown in the logs. However, based on this configuration and successful operation, I’ve declared Prototype #1 to be complete and have backed up all OS images as the initial product release. I’ve also decided to time slice the prototype developments unless I get the wifi to work further distances. One test I want to try is creating an ALARM 4.19 version OS on the RC because the standard upgrade broke video streaming (may have mentioned this above). Building from scratch may install everything (like Kivy) successfully and be better supported. The other test I need to do, based on Troy’s suggestion, is to take the iPad outside to see what the network is doing (which was a brilliant idea since I didn’t want to haul this dying laptop outside and risk losing the LCD screen that flickers constantly today). I’ve also ordered a new print job to replace the RC case and RPi mount in an attempt to find a better print job as well as ordered a new RPi case to house the communications rig electronics so it can be stored on the inside of the rover chassis.
9 May report – WORDPRESS SUCKS IN THE MOST EVIL (Like M$) WAY! I just lost a whole paragraph of a week’s worth of notes due to a fucking “unknown error.” Not unlike eBay and others these days. I hate these free apps that fail regardless whether one pays for them or not. Stupid time to be living in computer world these days. What I meant to say before was it’s been over a week and I’ve made a lot of progress. First off, the Communications Rig works great continuously and the new printed case fits great with only a few holes needing to be: added for On/Off Access, enlarged for power supply connector, and removed opening for other access. Tested 3A and 4A power supplies and 2A works best on tablet (still sporaticaly reboots when power applied) and 4A appears to be working fine on the rover. The tablet new printed parts work and look better than Walter’s World printed results and he’s fired. The touchscreen appears to fit the new case better than before but it’s time to print the second back panel to align all the pieces and drill final holes (then replace the touchscreen). Replaced the test camera with the Arducam OV5647 5Megapixel camera and it looks great. Integration issue that cost about an hour was their ribbon cable connector is reversed from the typical RPi camera connectors. Finally, spent three days debugging and cleaning up the socket code where they dropped and never reconnected. Appears to be working now, especially the battery since it was the worst at dropping. Prototype 2: built two wheel bases (first for assembly, second for building test unit), received and installed Geekworm motor HAT and SB Components Motor HAT. Code all appears to be working and need to test with rear wheels on six wheel chassis that I also created using the scroll saw to test before laser printing for 6 wheel prototype.
15 May report – I’ve accepted the fact that I don’t get back to this journal but closer to a week apart, and that’s okay. It allows me to accomplish more then list it here. So, for starts, successfully tested the R/RC at the local ORRA parking lot that proved to me the wifi works further than 150 feet, based on Google Maps. I wasn’t able to test a further distance at the time but the wifi signal strength on the RC showed full strength. I plan to test more at the Calvary Church parking lot since the ORRA lot is too full too often. During these tests, I plan to include MPH, wifi distance, and battery capacities during open runs on smooth surfaces. I also attended the Orlando Robotics and Makers User Group meeting and documented my notes in a letter to Claudio. In attribution to suppliers of R/RC contributions, I wrote Ben Hollerer to promote his gimbal design and print files. Due to the Trump China trade fiasco, I ordered 4 UPS boards (minus batteries) and one more Motor board (with PWM pins moved like I recommended) to use for a stand alone Pan/Tilt camera on the back porch. Yesterday, I spent all day editing the final RC case parts and the comm-rig version 3. Finally, I setup a fifth RPi to start testing 5GHz wifi because the RC video is flashing blank frames which could be caused by dropping frames due to wifi interference or bandwidth. This also begs the Troy recommendation to look at the wifi signals on iPad measuring tools.
16 May report – Removed the following from the design spec because it is more of a journal report than valuable design note. Because of this, there are multiple hack solutions on the web that have become outdated or not implemented on ALARM OS. That required a few days of tests to determine how these app interfaces work. For instance, on the RPi, if any app opens the serial port (pins 6 and 8), the other GPS OS code cannot open the port and fails. This required installing software modules to query the GPS daemon from python to access the coordinate data.Today, I am finishing loose ends of documentation on prototype 1 to be more prepared to present the system. Updated GPS/Communications Rig section in design spec.Added a Goddard Rover Prototype 1 Facebook page. Sent a ping email to Ben Höller and he replied:

I was overwhelmed with your motivation and ambition for the project, so i did not want to rush in a fast response. What i can say for now: You are totally awesome 🙂
20 May report – Made excellent progress in documentation updates and created a new prezi overview presentation that can be used for different user groups, like Python and RPi. This allowed me to update all literature with the latest configurations and quality check accuracy. I completed the 3D Hubs final print files to replace the gimbal head, comm-rig case, and tablet’s large back panel and internal mounting bracket, minus screw holes to drill with existing panel and case. Plan to order parts and replacement touchscreen on my birthday, 27 May. No progress on prototype 2 or ALARM 4.19 kivy tests.
21 May report – Ordered 3D Hubs Parts today and omitted the comm-rig box for a larger version instead (from Thingiverse). Need to test this new box for final version fit inside chassis.
26 May report – Not much activity on prototype 1 except testing for 5GHz Wi-Fi network configuration which I was able to test on a comm-dev unit. Once I wrongly enabled dhcpcd, the chip no longer worked and I had to rebuild the kivy image version (which I’ll backup this time). The reason for lack of progress on the rover is that I am waiting for the 3D print job that has sat on Production for a week now with no activity. It’s supposed to ship tomorrow but it’s a holiday, so who knows when the parts may arrive. In the interim, I’m watching NVIDIA tutorials that I learned existed during the RPi UG meeting in Longwood, yesterday. I presented the data sheet and overview presentation, which is more of a technical design spec. What turned out to be most important are the NVIDIA videos that I had missed and now can get a better idea how their SDK and existing examples work.
28 May report – I have been timeslicing between multiple projects the last couple of days: Pan/Tilt Camera rig (had problems with dev camera connection that failed to transmit video signal until reseating ribbon cable, one RPi3B would not boot when ribbon cable in camera jack), 5GHz Wi-Fi research rig (not appearing on network using comm-dev configuration on RPi3A+), Jetson Nano research, and the front yard gravel planter cleanup (to remove an over-populating basket grass instead of using herbicide). The Pan/Tilt Camera rig problem was exacerbated by the requirement for wired Ethernet that I’ve not used in a while and finding the right configuration option then reconfiguring a “clean” OS build that excludes Wi-Fi. I even tested the Rover OS configuration on this RPi test unit but it failed with the same results: No streaming video. That pointed the finger at the camera hardware not spewing video like it should. After the one RPi wouldn’t boot until I removed the ribbon cable so that I could test a different CPU, I wiggled the cable around enough to determine there was a cable or connection problem. After this exercise, I reconnected everything and it worked. I was even able to change the video port from 8059 to 8159, so it was more consistent with the 10.0.1.159 IP address for this camera configuration. The 3D Hubs print job showed parts shipped, assigned tracking number, and label has been created.
4 June report – Well, not surprised it’s been a week. Lots of stuff going on this past week, including a Factur tour and meeting with Swami to discuss 3D printing. I’m at the point of deciding if and when to migrate from the Remote Control to an Android tablet. Swami and I agreed that I need to cleanup the RC 3D print files with final extractions and send them to him for printing using PET-G polymer instead of the PLA. It will also be more consistent aesthetically by printing on the same printer by the same operator. I’ve also spent time researching more about NVIDIA and AI (short for topics). PRi User Group host is interested in getting presenters for the NVIDIA Jetson Nano and based on his agreement, sent Adrian at PyImageSearch to see if he might be interested. Made progress on goddardptcam configuration using new battery (that works except i2c interface), redesigned head to tighten under dome better, and automation works. Received the new UPS battery boards from China and appears one is DOA (RPi does not boot), one has LED problems that disagrees with WirePi report (only two lights on when 100% capacity reported), one appears to work fine, and one is still in the package (need to write vendor for advice). I’ve painted the rig all black and installed the new camera head which worked great until the bolts fell out today during tests. These test resulted in the app crashing, still every few times I hit the touchscreen. This is where I am today to decide spending around $200 to finish the Remote Control by replacing the broken touchscreen and reprinting all parts or migrate the RC app to an Android tablet that will cost half that amount of money. Regardless, my thesis was to confirm RPi 3A+ works for this application and at this point it fails due to the touchscreen app-crashes. This latter decision is also a predetermined requirement, since the RPi touchscreen configuration is way too pricey, much larger and heavier, and overkill for just the function it performs; however, it has 5GHz Wi-Fi that I still need to upgrade on the Rover network that is not supported on most Android tablets in the right price range. Yesterday, I totally broke a clean reserve camera dome glass used for glamour shots, so now down to three (two stored clean), with one cracked due to the cut wood shifting shape. The reason the dome broke was due to touchscreen not stopping the Rover when hitting the Stop button. This may have been caused by the code not issuing the Stop command because the app rebooted and thought the speed was already zero (over coding). Still more work to go on prototype 1.
5 June report – Finally found the 5GHz Wi-Fi solutions yesterday for Rover Wi-Fi Network subnet, it was as simple as adding ‘-c 149’ to the ap-start.service file. Appears to work fine; however, there is no improvement in the streaming video and frames still drop and on the RC, there is a pause every 5 seconds (probably caused by the ; need to test 5GHz in field. Also yesterday, installed new 160 degree fisheye lens on the Pan/Tilt camera configuration and all appears to be working correctly, including the battery board that was behaving strangely with only two LEDs shining instead of four; this was using the PoE converter (that frees up a power supply). Today is studying the last field test logs to get to the root cause of the tablet app crashing when pressing touchscreen. Spent rest of day reviewing latest field test logs and still see socket problems like refusals, broken-pipes, null receive buffers, and buffer overwrite problems; cleaned up some piece parts and organized; tested all batteries that appear to work but also reported to vendor that API is not working and will need to return if can’t fix this. Also during this time, determined latest RPi3A+ died and would no longer boot from known operational SD card and power supplies; exchanged failed board with replacement in two days from Chicago Electronics.
10 June report – 5GHz Wi-Fi did not solve the video frame drops or delays. Have determined that the streaming appears to be solid from all cameras playing in VLC but the tablet still exhibits frame drop/delays and now need to migrate the RC app to the new ALARM 4.19 OS to see if that might improve everything. Was able to install the WAL cam on the new comm-dev migration unit (RPi3A+) running ALARM 4.19 and tested the new IR floodlight that works with the RPi cam and existing Vivotek yard cameras. I also conversed with Claudio to ask his opinion about GoFundMe for the dev investments; he responded positively. Tested all battery HATs to determine only ONE of FOUR boards work with python; have asked for refund or replacement boards; submitted a dispute.
Things that need to be done going forward:
1. Test Rover code changes that failed to answer pings after last edits.
2. Replace Gimbal head screws to hold camera in place.
3. Migrate Remote Control app to ALARM 4.19.
4. Test Rover Wi-Fi Network channels for better streaming, like VLC.
5. Reprint Remote Control using PETG polymers – Swami job.
26 June report – Yes, it’s been a couple weeks of an assortment of projects mostly beyond the R/RC. I’ve spent time battling the insanity of the IRS as loan sharks, PyImageSearch for their shady practices, 3D Hubs delaying a day beyond their contract, and building my laptop replacement (due to screen and Wi-Fi adapter failures) using a spare RPi (that failed to work due to desktop tech requirements – RAM and 5GHz Wi-Fi). For R/RC, finally accomplished the upgrade of the RC to 4.19 with the latest version of Kivy running. At this point, need to migrate the UPS HAT from the tablet to test it on the RPi 3A+ remote-dev unit. To record yet another fortunate development from the Raspberry Pi Foundation, a second time I need a board to improve the features for what I need, the foundation released a RPi 4B that increases system RAM to 4GB which is direly needed for a competitive alternative to an Intel (or AMD) desktop computer. On 24 June, I received an email from Chicago Electronics informing me that that day alone was available to order the new 4B boards. After read their specs, I learned that this version will improve the delays caused by the 3B+ memory contentions as well as increase the CPU speed. I immediately loaded my cart with a unit, a new micro HDMI connector cable (Type D), and a microsd card. Then I stopped to think and wait before ordering. I wanted to double check my technology decision for the desktop but after a few minutes, my cart said the product had been sold out and my order updated with its removal. Guess who was pissed off and immediately sought another distributor, which I did with Newark Electronics whose website failed to allow me to order the micro HDMI in my cart (as another pre-order product) and forced me to call (because their web chat sales were down and the tech support said the site had overloaded). I was greeted very calmly and after learning my difficulties, patched in a tech support rep into our call who had no idea why they would not do the cable the same as the RPi4B. When the sales rep realized this was an order entry problem, she informed us that she can put the cable on my order and my RPi4B was confirmed with an estimated Friday, 28 June, ship date. I also ordered an overpriced ($37) PoE HAT to test for a surveillance camera feature to remove the PoE splitter brick. If this HAT isn’t perfect in many ways, I will be returning it, as I have with the UPS board a few months back. As for 3D Hubs, they were trapped in my amazon.com time warp where I had ordered the RPi3B+ and 16″ LCD monitor that showed up a week sooner than expected. It was understandable to me that I’d have to wait for the 3D Hubs parts to enclose the computer and it sat out in the open waiting for shipment. Well, their Lead Time date was four and the Ship date was set for Friday but the printer only printed the shipping label on Friday and the parts sat for a day waiting for the USPS pickup. I was furious because I checked online chat to confirm the parts would ship on Friday and not sit overnight with a printed label, which is NOT ship date. I went back-and-forth with the dispute manager who could only apologize for the delay and tried to blame the problem on UPS and USPS shipping policies. I disputed that excuse saying my order has always been to a Post Office Box and should have had nothing to do with UPS. I asked for a loyalty discount for failing to ship on time but was told there are no options for that in their system. Once again, a failure to follow standard marketing practices, so I will be seeking another printer for the final Remote Control case prototype.
29 July report – Yes, it’s been over a month since last reporting. I’ve done little on the R/RC and have focused most of my time receiving the RPi4B, which arrived two days ago. This is for the Desktop PC and as I suspected, the UPS HAT does not supply enough power to run the RPi4B and it continues to reboot, just like the RPi3A+ with the UPS HAT before enough current applied.
So, for a splash of spending, I did order the Remote Control case be printed in PET-G that should fit better now. I also redesigned the Desktop VESA case to support the RPi4B and will post that should it fit and work correctly. The expected completion date for these printed parts is mid-August, so I’ll be back around that time.
5 August 2019 report – As Moses quoted below, I fried another Pi, the new 4B. This was a stupid mistake where I plugged the 12V connector into the Pi’s 5V input. It smoked a bit and I thought it was my cigarette, but after that, the board was useless. I immediately ordered 2 more and had them delivered priority. Today those boards, a new power supply, and the redesigned 3D printed cases for both the 4B and the Remote Control arrive. For the Desktop Pi, I ordered iJoy bluetooth headphones they turned out to sound incredible and as clean and clear as professional headsets.

28 August 2019 report – It’s been just about a month of ordering and waiting for parts. This has been productive since I fried the Pi in my last report. This one is best viewed in the table below.

Project Achievements

Product	Results
Rover	Not much has been done for this project other than replacing the gimbal camera head screws. Need to investigate video flashing and delays, with RC and see if the camera caused more delays.
Remote Control	Received new case parts and the touchscreen fits as it should. Still have video delay and errors with ffpyplayer. Need to revert back to previous build that worked with just a constant 3 second delay.
SlideShow	Waiting for case with new mount 100mm and deeper cavity, Raspbian and Arch Linux ARM OSes work, and RPi4B firmware fix required for monitor off. I reported the vcgencmd failure and commented on the dpms not powering off the screen issue. Have tested a new PoE board that’s lower priced than the free one I got from Newark (who couldn’t support it, refunded my money, and their HAT cost $12 ($36) more than RPF PoE HAT (which doesn’t support RPi4B power requirements). Now waiting for a new PiShop.us UPS HAT that supports 4B for the SlideShow and Desktop PC.
Desktop PC	Have new 20″ monitor with internal speakers, waiting for new case, both OSes working, RPi4B firmware fix required for monitor off. The 20″ monitor removed the need for adding speakers and reduced the part and wire count considerably. This also reduced the prices/costs for the components.

1 September report – Five days has seen the following accomplishments, across all projects for now.

Project Achievements

Product	Results
Rover	No change
Remote Control	Have tested the May 2019 OS and it continues to stream video as it did back before I migrated to ALARM 4.19. It also still exhibits the gray flash screens which makes me think the video is not being transferred fast enough and the display flashes when resyncing.
SlideShow	Case with new mount 100mm works great. Now waiting for PiShop.us UPS HATs to be in stock to order and install on the SlideShow frame.
Desktop PC	The new 20″ monitor works great. Have completed the battery install with only a strap remaining before writing up the build it yourself instructions and photographing parts.

6 October report – Over a month has seen the following accomplishments, across all projects for now.

Project Achievements

Product	Results
Rover	No change.
Remote Control	Have experimented with option changes to picam startup and got rid of the flashing video by turning off videobitrate using the May 2019 OS. It continues to stop as if some other process is holding up the stream and will experiment more with RC app to stop all polling. ALARM 4.19 does not flash video with this change and needs to fix stopping stream.
SlideShow	Ordered Geekworm UPS HATs for SlideShow and/or Troy’s new PC, and Frank’s PC. Need to test how it works with the new PoE board.
Desktop PC	Have completed HW and OS build but still needs new case with screw holes in all six places to secure the plastic tightly. Waiting for new UPS HAT to write app to shutdown once battery capacity is below 5%. Also need to determine what time 5A battery has for marketing literature.

14 October report – Have spent the last few days learning a new method of socket communications between the rover and remote control apps. This initiative came to fruition after stabilizing the ALARM 4.19 migration to stream video at a smooth frame-rate along with the log evidence showing communication failures, buffer overrun, and unreliable packet processing (unexpected bogus traffic). The frame-rate problem I resolved using variable frame rates on the server. Once that smoothed the video and removed the gray flash frames, the remaining problem was the 5 second freeze frame that lasted up to a second. To fix this, I turned off all ping activity between the R/RC and the freeze frame problem vanished. That necessitated a code method change to remove the ping processing into a separate class of code. To learn how this is done, I found the following tutorial and modified the code to remove the R/RC ping/ACK processing outside the RC kivy app. This same code will be applied to the following R/RC comm operations: Record, Gimbal, Battery, and Wheels/Motors apps.
https://realpython.com/python-sockets/
30 November report – This is a success update about the new python-sockets communications interface that is now working between a test rover gimbal and a remote app. There are five modules that make up these device client/server, four on the Rover: gimbal-server, rover-libserver, gimbal-client, and rover-libclient; two on the Remote Control: gimbal-client and rover-libclient. Both rover-libclient modules are the same on both the Rover and the Remote Control. In the next few days, I will migrate all these comm modules from the existing rover-server-current.py module to handle each of the devices (record, gimbal, battery, and motors) into individual client/server modules and all of these will use the same rover-libclient and rover-libserver modules.
3 December report – Making progress with the communications design upgrade and has passed prototype tests using the Adafruit camera gimbal with remote control test code running from RPi Desktop.
7 December report – Because the rover needs to stop things when the communications break down, added code to the gimbal client prototype intended for wheels to STOP when remote is not communicating.
– Fixed double message receive buffer problem by “jamming” ACK.
– Added ping timeout to rover-gimbal-client to recognize remote missing.
– Added sending remote ping period to rover for sync and config update.
– Added logging restart on rover when remote connects – date problem.
16 December report – Successfully migrated the new data comm code to the gimbal and it worked sporadically using the old code variables and multiple drivers. Need to simplify the drivers instead of using the gimbal code provided by Ben Holler. I sent Ben an email asking his advice about new drivers or use his modified. He was going to fix the pan backup in his code but I never heard back from him.
Also, the RPi4B desktop exhibited a power supply problem and I had to revert back to the PiShop UPS board and an RPi PSU. Need to determine the power failure, somewhere in the step-down converter or wiring.
17 December report – I actually fixed a gimbal quirk that makes it run smoother and more precise by not backing up when panning. I also learned the prototype test bed has a bad stepper motor driver board. Gets jammed when trying to pan but the rover gimbal appears to be working correctly. More test to follow. Next to compress the startup code into the remote-libclient.py code as subroutines then migrate the wheels and recorder code.
5 January 2020 report – Today the R/RC are running the new client/server communications code that is now separate threads on both devices that run the recording, gimbal movements, battery capacity reporting, and wheels/fans motors. This change has improved the video streaming delay about a second resulting in an estimated 1.5 second delay. During this migration exercise, Kuzeyron has left our chat room, I’ve trapped two stray house cats, and Freddie bit me again. I remain diligent, the code appears to be more reliable, and I plan to start field tests again at the church. One thing that is not working well is the gimbal that appears to be a pan hardware motor problem. This will not delay field tests because the wheels are my primary issue using the new communications code.
12 January 2020 report – Today, prototype 1 is software is complete and fully operational. The new communications system appears to be rock solid and will be tested today for field reliability and some statistics gathering for speed and capacity. The gimbal pan has been working consistently during the last few days, so not sure what causes the non-responsive pans. Once I get some field tests completed, the code will change to remove the RAW transmission logging that should reduce file sizes by 75%.
Yesterday, I ordered a replacement touchscreen and two power supplies. The current touchscreen has a crack now across the lower left corner trailing across the left side to the center on the top of the screen. The power supplies are test units with 4Amp and 5Amp capacity to replace the current units that are causing power surges and reboot or not boot at all.
19 January 2020 report – Yesterday I conducted three field tests at three locations. The video was a constant problem and was only able to work for short periods and I still don’t know what the problem is. There is no problem when at home inside with the existing LAN but in the field, it failed multiple times. I will be testing this to determine what needs to be fixed. The other tests worked great with Wi-Fi appearing to work over 200 feet. I was also able to get some mileage data and it appears the rover runs about .8 MPH. I have since changed the logging code so more specific runtime data is separated from the debug log entries. My next enhancement is a pop-up window that will allow the remote to reboot and/or shutdown the rover too.
27 January 2020 report – Today was a migratory day starting with the Rover by going back to the June build (now running on the 32GB Black Sandisc chip) and installing the latest scripts. This was to overcome a video dropout problem that still persists but in lesser degree, for now. Along with this test, I’ve also updated the battery log on the remote to only log new capacity values with a count of how many received. Need to do this on the rover too. Also added a popup window to allow the user to reboot or shutdown the devices. This removed the separate icons that did just the remote’s reboot/shutdown and also incorporated the remote app restart. I tried to add the ‘systemctl restart picam-start’ to the rover ping response routine but it failed to return quickly enough for comm processing. This now needs to be a separate process to monitor picam and restart it should it start generating ‘Record buffer is starving.’ I also ordered a power meter today to test the power supplies and transformers on the USB ports. This is to fix the Desktop power problem with the RPi4B that reboots now without reason but soon to be determined.
2 February 2020 report – Today was a major success field test day that a majority of the systems worked together to determine the speed of the Rover which is just under 1MPH as I reported on the data sheet. Turns out times were 14:09:10 start to 14:15:31 end, or 6:21 for 528 feet track.
16 February 2020 report – Today was a major implementation day for my RPi4B PC in that I replaced the failed 5V4A transformer with a 5V5A transformer, and it is still working as I write. The other thing accomplished today were field tests at the ORRA parking lot where the rover had problems with communications, for some reason. I now need to research the logs to see what happened but it was definitely some strange results. Also experienced a problem with the right tread not being tight enough to do some of the 45 degree turns. This will require some more research to determine the tightness of the tracks.
x

“Broken items are generally part of the learning process.”

Moses, Electrical Engineer at All Spectrum Electronics, 9 July 2018

Original Build Requirements

App	Card	Address	OS	LAN	Python	GUI
SlideShow	#1	10.0.1.188	Arch	CAT5	3.7	Kivy
Remote	#2	10.0.1.158	Arch	Wi-Fi	3.7	Kivy
Rover	Black	10.0.1.159	U-Mate	Wi-Fi	3.7	xrdp

Final Build Configurations

App	Address	OS	LAN	Python	GUI
Rover	10.10.10.100	Arch 4.19	Wi-Fi	3.7	ssh
Remote Control	10.10.10.101	Arch 4.14	Wi-Fi	3.7	Kivy
Comm-rig	10.10.10.1	Arch 4.19	Wi-Fi	3.7	ssh

Camera Configurations

Make	Model	Lens	Rcv Port	rtsp Port	Use
Arducam	OV5647	Closeup	1956	8059	Rover
SainSmart	OV5647	Fisheye	1959	8159	Pan/Tilt Yardcam
MakerFocus	OV5647	Wide Angle	1901	8201	IR Tests

Franks Travel Timeline

Posted on 19 July 2018 by fgould

Frank’s Global Travel Timeline

1956	Washington, DC – First Plane Flight just after birth – Not Global, just first flight
1960	Cross US Country to Alaska with my parents, Bea and Harvey Gould
1973	High School Cross France Country – Paris, Rouen, Le Mans, Tours, Orléans, and Versailles
January 1975	Stetson Europe Tour – Monte Carlo, Florence, Rome, and Germany
September 1985	NCR Video PC Support Trip from England to Scotland
April 1989	Cross Europe Sales Tour – Switzerland, England, Holland, Germany, and France
June 1990	Cross Europe Sales Tour – Germany, Norway, Denmark, Luxenburg, Holland, England, France, and Switzerland
November 1990	Cross New Zealand Country – Auckland, Rotorua, and Christchurch
November 1990	Cross Australia Country – Sydney, Cairns, Great Barrier Reef, and Canberra
May 1991	Amsterdam Trip with Tim Carpenter
March 1993	CEBit Show Augsburg Germany and Amsterdam visit
July-August 1993	Cross US Country with JR – East Coast, Canada, Mid-West, West Coast, and back
February 1995	Paris Trip with JR and Amsterdam visit
September 1999	Cross Costa Rica with Troy – San Jose, Limon, Puerto Viejo, and Turrialba
August 2001	Cross Peru Country – Lima, Explorama, ACEER, Pacaya-Samiria, Cusco, and Machu Picchu
Feb-March 2002	Cross Brazil Country – Sao Miguel, Sao Paulo, Pirenópolis, Rio, Brasilia, and Pantanal
July 2003	Cross Peru Amazon Country – Explorama, ACEER, Explornapo, Yagua, and Cieba Tops.
November 2004	Attended Cannabis Cup in Amsterdam, Holland
August 2005	House Hunting in Costa Rica Quepos Pacific Coast
January 2006	San Salvador, El Salvador and surrounding areas.
June 2006	Cross Venezuela Country – Isla Margarita, Caracas, San Francisco, Colonia Tovar, and Henri Pettier.
December 2006	Spanish Immersion – Isla Margarita, Venezuela

US Postal Service Vacant Brains

Posted on 28 January 2017 by fgould

We had renters move into a house two doors down from our home on 13 January. The next day, the new renters started yelling and cursing from the house and out into the street. Later that morning, Orange County Sheriff’s Office (OCSO) parked two police cars in front of our immediately next door neighbor’s house and one down the road. That’s when I started writing a letter to the owners of 4601 Goddard Avenue.

As I have in the past, I searched for the owner’s name and address on the county property appraiser’s website. What I found odd is that the owners listed used the 4601 house address. Usually rental units have a property owner’s business address or post office box.

As I was finishing the letter complaining about the loud and angry screaming, two pit bulls from the same property loitered in our front yard, followed by the owner right behind them. He was maybe in his thirties, overweight, unshaven, and wearing boxer shorts. He apologized and we said his dogs need collars and tags. He said nothing.

I finished the letter and drove to the post office to mail it. There I received a tracking number for the letter to be certified and restricted delivery to Anna B Ethington at 4601 Goddard. Three days later, I see online that the letter had an Alert that it was undeliverable with no explanation.

That prompted me to call immediately the USPS Service Center. I reported to them that the address is two doors down and there are renters there. The rep said he would reschedule the delivery. Two days later, the website reported the following:

Your item was returned to the sender on January 19, 2017 at 8:55 am in ORLANDO, FL 32804 because the address was vacant or the business was no longer operating at the location and no further information was available.

That immediately prompted me to call the service center back to reiterate the new tenants are there and that it was two doors down. Late in the day Brandon from the College Park Post Office calls and leaves a message saying the house is vacant and left a number to call. I called the number, no one answered, and the option offered was to leave a message. As soon as the call switch to the College Park Post Office answering machine, the voice reported the mailbox was full and to call back again.

I called back and tried some other options but all resulted in the full voice mailbox. So, I called the USPS Service Center to report what had happened, reiterated not vacancy, and that I could not contact the post office because no one answers and the voice mailbox is full. The rep repeated back while he wrote and skipped the VOICE part in my report. I reminded him the he must put VOICE on the report or they will think it’s a joke, as in the mailbox is full, the post office is full of mailboxes. It would certainly be confusing without VOICE.

stupid-post-office Nothing happened for a few day which made me think they were actually trying to solve the wrong information from the delivery carrier person. After three days, I called the Service Center back to get a status on this delivery. I was informed they were working on it and I should hear back from them soon. The next morning I got two voicemail from the College Park post office saying the property was vacant and to call them back. I tried calling them back, since I figured they had fixed the full mailbox problem, but no, no one answered and the voice mailbox was full.

I called the Property Appraiser’s office and was told they only provide the address that the owners specify in the title papers at closing. I asked what if you need to get in touch with them. He said his office would use the online address.

Once again, I called the Service Center and got the same repeated vacant address status, so I asked to escalate this stupid incompetency. The rep sounded like she could understand the stupidity and tried to submit this problem online peacefully to the USPS Customer Affairs division. Later that day, I received a call from Customer Affairs who informed me they had received the complaint.

Two days later, I go outside to check on the dogs barking at 4601 and right when I returned inside the house to answer the phone, it went to voicemail. After someone left a message, I retrieved it and learned their conclusion was that the house is vacant and to call the post office. I called the Customer Avoid, er Affairs, number back and spoke to an idiot who merely read back what the report originally said. No one gave me any credence for a fact.

I repeated there were renters in the house and it was the carrier who was vacant in the brain. They had made no effort to confirm residents or prove vacant. When I asked for a supervisor, the Customer Avoidance rep hung up on me.

Later that day, we walked our dogs and during the walk our elder dog started limping, due to an existing joint problem and lack of exercise while recovering from gastrointestinal problems. I walked ahead to get my car and returned to pickup our ailing dog. My partner said for me to take her home and he would walk by the renter’s house to talk to the guy working in the front yard. That we did.

My partner, Troy, told me that he kindly greeted Brian (the name we’ve heard others say because we’ve never talked to him) and mentioned that his dogs were barking incessantly and loudly during the days. Brian replied in an aggressive tone, “that’s what dogs do, they bark. What about it?”

Troy just waved and walked back home. Troy reminded me that was what our next door neighbor had told him when his dog was barking outside during the night. The aggressive behavior was also not neighborly and later that same day, Brian walked past our house with a dog on leash and stared at our front yard as he walked both ways past our home. He looked defiant and provocative, like he wanted to fight.

4601goddard Photo taken of 4601 Goddard Avenue at 7:30 AM, 28 January 2017

On 28 January, I went to the post office where I originally sent the letter to ask for my money back. The attendant talked to the supervisor and said I would have to drive down to the College Park post office to get the letter back. The attendant said his supervisor had called and talked to the supervisor at that post office. I drove to the College Park post office and stood waiting for 10 minutes to talk to the supervisor.

When finally talked to me, he started hollering why they hadn’t contacted the post office to complain about not receiving mail, I answered that that has nothing to do with me. I was only trying to have a single letter delivered to the owner and don’t care about their mailbox situation. After I proved that the problem is the carrier lying, he decided to call the carrier directly and ask. When he got off the phone he explained that weeks ago the carrier had tried to deliver mail in the mailbox but no one removed it. After it starts piling up, they pull the mail and insert a note saying the house is considered vacant, regardless of neighbors telling them that they are there.

Of course, I had no idea what was inside the box because it is illegal to tamper with someone else’s mailbox. Instead, I had to spend hours on the phone and drive to two post offices because no one has any brains to inform the customer why the house was considered vacant. Below are the calls and time it took to find out how incompetent this country really is. NAMI was right in the DSM-V, this country is mentally ill.

Number Called	Date/Time	Call length
800-275-8777	1/19 – 1:37PM	01:10:00
800-275-8777	1/20 – 8:08AM	00:14:00
407-841-2634	1/20 – 2:20PM	00:01:00
407-841-2634	1/20 – 2:23PM	00:03:00
800-275-8777	1/20 – 2:27PM	00:30:00
407-841-2634	1/24 – 7:33AM	00:01:00
407-841-2634	1/24 – 9:07AM	00:00:54
800-275-8777	1/24 – 9:10AM	00:38:00
813-354-6200	1/27 – 8:02AM	00:05:00
407-841-2634	1/28 – 8:07AM	00:01:00
	Total Time:	02:41:54

800-275-8777	USPS® Customer Service
407-841-2634	USPS® College Park
813-354-6200	USPS® Consumer Affairs

WIR54547258	Redelivery Case Number
CA131666076	Consumer Affairs Number

Update USPS Miami

After ordering a 12V battery UPS from amazon.com, here’s how the US routes packages to Miami and they attempt to deliver it:

Tracking Number: LW915462595CN

The customer has requested that the Postal Service redeliver this item on August 12, 2019 in ORLANDO, FL 32804.

Status

In-Transit

August 10, 2019
Redelivery Scheduled
ORLANDO, FL 32804

In-Transit

August 10, 2019
Redelivery Scheduled
ORLANDO, FL 32804
The customer has requested that the Postal Service redeliver this item on August 12, 2019 in ORLANDO, FL 32804.

August 10, 2019, 11:55 am
Delivery Attempted – No Access to Delivery Location
MIAMI, FL 33166

August 10, 2019, 8:28 am
Out for Delivery
MIAMI, FL 33166

August 10, 2019, 8:18 am
Sorting Complete
MIAMI, FL 33166

August 10, 2019, 7:55 am
Arrived at Unit
MIAMI, FL 33166

August 9, 2019, 6:59 pm
Arrived at USPS Regional Destination Facility
MIAMI FL DISTRIBUTION CENTER

August 9, 2019
In Transit to Next Facility

August 5, 2019, 9:33 pm
Departed USPS Regional Facility
QUEENS NY DISTRIBUTION CENTER

August 5, 2019, 5:38 pm
Arrived at USPS Regional Facility
QUEENS NY DISTRIBUTION CENTER

August 5, 2019, 9:22 am
Processed Through Facility
ISC NEW YORK NY(USPS)

July 31, 2019, 6:03 pm
Processed Through Facility
SHENZHEN EMS, CHINA

July 31, 2019, 1:38 am
Processed Through Facility
SHENZHEN, CHINA

July 30, 2019, 7:23 pm
Acceptance
CHINA

ObamaCare

Posted on 22 January 2017 by fgould

Below is the letter I received from the IRS regarding the (Un)Affordable Care Act tax I am being charged and penalized. My response follows the charges.

EPSON MFP image

20 January 2017

Department of the Treasury
Internal Revenue Service
Kansas City, MO 64999-0002

Dear IRS rep,

Because someone names something affordable, like the Affordable Care Act, does not mean that it is affordable when one has no income. Why is that? Because some others in the same group decided to give tax credits to corporations when they offshore jobs. Why is that? Because some rich people decided they could get richer by using cheaper labor in foreign lands and wiping out the middle income earners.

Now I’m penalized for not having health care. Why? So others in this country can have health care. When was the last time I visited a doctor? 2007 and I smoke more than a pack of cigarettes a day. That’s yet another penalty.

That’s also the year I lost my career job of a quarter century. What did I do? I learned that my career had been saturated with workers who also lost their jobs. In 2008, there was 80% supply of Project Managers with a 20% demand for them. I had just turned 50 a couple years prior, now I was supposed to compete in a saturated job market full of age discrimination. I learned this at the job center where they could not place me.

So, after researching a new career path, I deduced that my dream job was a possibility in Florida where I live. During a conference call meeting with the Florida Film Commission, I learned that Florida had a tax credit that was profitable to the state and it created many jobs across the state. This was a successful and profitable program that generated millions of dollars in economic stimulus to communities, local jobs, and an opportunity to work with professional movie makers.

I started a Valencia College degree program for Film Technology in 2009 and worked in the motion picture department on a work-study program. I took out a loan to cover the cost of this two-year degree and graduated with 4.0 GPA in 2011. I was generating a low wage income but I had saved enough to make it through school and was working on movies until 2012 when the Florida legislature terminated the tax credits for the Florida motion picture industry. The Koch brothers funded this.

I have been unemployed now since then and have had no job interviews nor career opportunities since then. I have requested from the Department of Education that my student loan be forgiven and/or reimbursed so that I can survive living on the remaining assets I have. My 401K will not last many more years and I turn 61 this coming May.

Now this enclosed IRS letter I received says you want me to pay this ACA tax that I don’t even use. This is sucking my remaining income for the health of someone else who can afford it. Besides a $75 per month tax, there should be an unaffordable option for people who have been screwed by the government in multiple directions. Also, why is there a penalty for smoking but none for obesity, alcoholism, or prescription addictions? This is taxation without representation.

I worked 25 years so that I would have retirement funds but instead my government wants to tax and penalize me for something I haven’t needed in 10 years. I’m paying taxes on income I saved so I could retire but instead I’m using it to feed and house our family. These days I spend $100 per quarter to have my teeth deep cleaned at the dentist so I can keep my teeth. Isn’t that a better investment in my health?

Please send me the forms for opting out of the ACA tax. I’m hopeful that the incoming US president retroactively repeals ACA and I can reduce my 2014 IRS tax debt from the ACA taxes and penalties. With no career income in the foreseeable future, these taxes are depleting my savings and increasing my debt that I will never be able to pay back. I’ll be homeless before I die.

Is this the “American Dream?”

Sincerely,
Frank Gould
P.O. Box 608516
Orlando, Florida 32860-8516

2015 Infraction Factions

Posted on 2 July 2016 by fgould

Case Number: 2015-TR-164933-A-O
Citation Number: A1XN98P
Defendant: Frank Gould
Date: 8 February 2016

I am Not Guilty due to extenuating circumstances caused by the Orange County Sheriff Office (OSCO) failure to do their job and support our community. I was cited for attempting to circumvent a road lane outage caused by a disabled vehicle in order to proceed in an open lane. After learning the severity of the blockage that extended far beyond where I could see or had any knowledge, in hindsight, I would have driven miles around the blockage to avoid the closer route to my destination and avoid the resulting citation.

The insult to me is that once the officer pulled me over, I had to tell him that he should be directing traffic instead of handing out traffic citations because of what they caused by not informing drivers of the impasse. You will note in the evidence I present regarding this neglect of duty clearly shows the OSCO personnel were aware of the event, had ample time to direct traffic safely, and failed to fulfill their commitment to the community.

I do not believe I should pay any traffic violation penalties nor court costs caused by their traffic trap. Please allow me to provide my perspective and decisions based on the traffic situation that day, 22 November 2015, with supporting evidence.

I had been working for a month on a user booklet about a new product for a startup company. So I could view a professionally printed draft as it would be for product release, I decided to print the document at the Office Depot a few miles away on a slow-traffic Sunday, and not a busy work day. Below is a map of my route.

Before I ever take a trip in my car, I always plan my route and destinations, even the most basic trips. Because it was Sunday afternoon, a little after 4PM, I knew the traffic on Lee road is always wide open with no backups or jams. Normally, it would take me 10 minutes to drive from my home, west of I4 off Lee Road, to the Office Depot in Winter Park. This Sunday was different but I had no clues this was the case.

As I got past the Adanson Street traffic light, two lights before the major I4-Lee Road intersection, I started to see that the left lanes were blocked with long lanes of traffic backup. This typically meant there was something wrong in the left I4 East access ramp from Lee Road onto the highway. So, I stayed in the right hand lane to see if there might be a way around the blocked left lanes, and the right lane appeared to be flowing through to the next intersection.

This was when I realized that drivers were circumventing around the left lanes and butting themselves into any opening right as they approached the traffic light. I abhor this behavior and do not attempt this maneuver because it’s cheating to avoid being held up and getting ahead of or delaying those waiting in line. However, in this case, since it was so badly blocked, I decided to go around the whole intersection, south (I4 westbound) to the next exit, Fairbanks, and drive back up Wymore Road to avoid all of the I4 intersection traffic jam (this would have been futile but didn’t know it then).

As I approached the intersection in the I4 access lane, I was in line behind two cars waiting for the oncoming traffic to the same I4 entrance ramp, while we yielded for the oncoming traffic turning left onto I4. Once they had cleared, we had the right-of-way to also accelerate onto I4. This is where I made a wrong decision to fill an open space in the Lee Road right lane to navigate around the immediate lane outage (see map below). Because there were no officers directing traffic, I assumed that safely using the available open road to circumvent the downed vehicle would be permissible.

Illustration 1 (right) – Lee Road/I4 Intersection West Map. This illustration is an attempt to show the traffic and car positions when I made the decision to go around the blocked left lane where a vehicle was out-of-service (red rectangle) along with a repair vehicle (blue rectangle) also blocking the same lane.

Note: This map image is not exact nor to scale.

The other correction in the image is that there are three lanes of traffic under I4 (see picture below right) where the map image right shows only two lanes. Also note the police flashing lights icon on Wymore Road beyond this intersection was now visible from my location, in the Open Lane Position.

Illustration 2 – Lee Road/I4 Intersection West Bound Ramp. This is the same intersection as the map illustration above; however, this view is from the road looking east. This photo was not taken the day of the incident but a few days later.

It was at this point I made the decision to pull into the Open Lane Position, as illustrated, while there was no traffic moving in the intersection. Afterwards, I saw an Orange County Sheriff vehicle pull out of a left lane behind me and flash his blue/red lights. We sat there for several light changes and then approached the Wymore Road intersection where the officer’s car informed me on the vehicle outdoor speaker to pull into the Denny’s parking lot, as in the photo below.

Illustration 3 – Denny’s Restaurant Southwest corner Lee Road and Wymore Road Intersection. This photo shows the No Right Turn sign into Denny’s parking lot. This picture also shows the view down Lee Road where I could then see the major blockage and police flashing lights down the right and left sides of the Lee Road lanes as well as a single vehicle flashing lights located on Wymore Road, visible between the No Right Turn sign and the Denny’s building. This photo was not taken on the day of the incident but a few days later.

I pointed to the No Right Turn sign for the officer to see and he responded over the speaker, “negative.” Then a few seconds later, he informed me again to pull into the parking lot and implied I ignore the No Right Turn sign.

As we waited for the traffic to allow us to move forward, I could see flashing police lights to the right of Lee Road on Wymore Road and that Lee Road was blocked with vehicles stopped all the way down the road along with more flashing police lights on the left and right sides of the road (see map in Conclusion). It was then that I realized there was no possible way of driving down Lee Road to 17-92 (aka North Orlando Avenue) where the Office Depot is located. Had I known this, I would have totally avoided Lee Road and driven Fairbanks Avenue to 17-92 and north to the shopping center where Office Depot is located.

After I parked in the Denny’s parking lot, I could see that the I4 eastbound right lane Exit 88 was blocked back to the Fairbanks curve and vehicles were changing lanes in all directions to circumvent blocked lanes throughout the intersection. I was not the only driver who attempted to avoid the blocked lanes using available open lanes. I could not believe the unusual amount of traffic in this area and had no idea it would be this jammed without any signs or indications about an event that could cause such traffic jams.

When the officer approached my vehicle, I explained why I had circumvented the blocked lane. He replied that I had failed to obey the traffic control device. I told him that I had done so because of the I4-Lee Road intersection jam due to the vehicle outage and asked why there weren’t officers directing traffic away from this intersection to inform drivers that Lee Road was blocked. He didn’t answer my question. I added that this stop should be a warning notice and that I am a resident of this neighborhood, where I was going, and why.

The officer proceeded to issue me a citation and suggested I take the traffic improvement course to avoid penalties and points. I insisted the citation should be a warning (if anything) and the officers should be out there directing traffic instead of handing out citations to local residents innocently going about their business and totally uninformed about the road outages.

The officer had nothing to say. I took the citation and drove back home, where I started investigating this incident to learn about several extraneous factors involved with my citation and the event of which I was unaware.

In an online search, I learned that the event was an Eatonville ‘Riding Big Car Show’ attracting thousands of participants. Winter Park Police had prepared in advance for the show but OCSO did nothing in preparation.
This car event started at 2PM and at the time of my citation, 4:14PM, there were still no traffic notices or officers directing traffic. This made me feel traffic was an excuse for citations instead of managing traffic.
Ten minutes after my traffic citation, WESH posted the following traffic alert indicating the Lee Road exit was closed:
From the Orange County Sheriff’s Office website: “[Sheriff Jerry L. Demings] believes that, to be totally effective, a law enforcement agency has to form close working partnerships, not only with the citizens it serves, but with its schools, churches, all branches of local government, and the local corporate community. Community Oriented Policing remains one of the cornerstones of his policing philosophy.” Does this NOT include local community traffic communications and directions? Does this mean serving citations?
From the Orange County Sheriff’s Office website, again: “The Support Services Division commands many of the sections and units, such as Community Relations…which can provide the logistics support vital for agency and community interaction that is so important to a community oriented philosophy.” Does this NOT include local community traffic communications and directions? Does this mean providing citations?
The next morning after my citation, a friend told me that he was at Home Depot on Lee Road the same day as my citation and when leaving around 4:30PM, traffic was diverted around Lee Road eastbound and only onto I4 local southbound (westbound) direction. This confirmed what I had learned online.
There were no event advertisements or signs in the Lee Road area warning in advance of the event or current traffic blocks. The picture below is a traffic warning sign that did not display any warnings about the upcoming traffic congestion or detours. This sign is located on Lee Road facing eastbound traffic (towards I4) between Goddard Avenue and Adanson Street (see map in Conclusion section below). Had this been operational and informative, I would have detoured around Lee Road by turning on Adanson Street and using Fairbanks Avenue to 17-92 and up to the Office Depot.

Links corroborating evidence list above:

Conclusion
I am a volunteer for the Lee Road Safe Neighborhood association to publish its newsletter (below) and I had no information about this event nor traffic. Winter Park police had notification and prepared for the event (reference WESH video in link #1 above) but Orange County Sheriff Office did nothing to prepare our neighborhood.

I believe this citation should be rescinded and canceled without any further action. I should not have to pay for court costs because OCSO did not perform its duties for safe traffic performance in our community but instead taxed me with a citation caused by their failures. This document took me two (2) days to create.

Below is a full aerial view of the Lee Road area to identify landmarks referenced in this document.

Also a few days after my citation, I found that in downtown College Park traffic signs had been erected warning of road closure. Below are photos of one of these signs (note: photograph did not capture the sign lettering but was clearly visible in person: EDGE-WATER DR CLOSED, 12-3-15 12PM-10PM). Same road closure signs have been posted on Minnesota Avenue, a two-lane back road street, unlike a major road like Lee Road.

Final Judgement:

Blighthouse Trouble

Posted on 2 April 2016 by fgould

Of course, my titling this piece “Blighthouse Trouble” instead of the actual company name, “Brighthouse,” as in networks, will obscure it from Internet searches; however, we had a blight in our house on the network and it took Blighthouse far too long to eradicate the problem. Exposing yet another stupid company is not my objective. It’s just another example of a greedy corporation in the United States, and there’s nothing news-worthy in reporting that. This report is only to document how stupid companies are when it comes to supporting their products.

Until early 2014, I had very little experience in network products and technology when we started adding a large number of network devices. These included iPhones, iPads, Windows and OSX computers, multiple IP surveillance cameras across our property, HomePlug power line adapters (with EOP/POE features), multiple Android Wi-Fi tablets (running picture slideshows) with front-facing cameras, UAVs (Unmanned Aerial Vehicles or drones), a Windows 7 server, and numerous switches, routers, and modem to interconnect these devices.

I’d like to reinforce my neophyte knowledge of networks and their interconnecting devices. Everything my partner and I had installed was typically plug & play with minimal skills or knowledge required. So, I viewed each Blighthouse rep with expectations of high expertise and superior to anything I could understand. In the end, I finally realized with all the network devices I had configured and resolved issues, I had learned enough detail to figure out solutions to problems I never imagined I could understand.

But one day back in mid-2015, we started having problems with temporary bandwidth dropouts sporadically during the day. Our initial assumption was that the line voltage carrying the network signal to our equipment was dropping out. We watched daily as the download speed descended to 10% of its typical performance. Then after a few minutes, returned back to double digit download speeds.

We began trouble-shooting this problem with Blighthouse Networks support reps to systematically determine the point of failure. They sent out reps on separate dates over time to replace the wire from the road, replace the wire inside the house, and replace wall outlets previously installed by a Blighthouse rep. Each time they came to us, they identified some bogus problem they supposedly fixed; however, the dropouts continued to occur.

I was misled all the way up to the last visit by a Blighthouse rep who never said anything about their modem replacement product was also a router, as in combo. Based upon my support call to one intelligent trouble shooting rep, the field rep’s instruction was to install just a modem only, and from what the field rep said, that’s all it was. But in reality, the device was not just a modem. It was a modem and router combined.

After the rep successfully installed the device and departed, I eventually looked at the back of their “modem” and found multiple ports, as a router would host. What it proved to me is that these Blighthouse reps barely know what they’re doing. That’s because this last installer got it half right and hadn’t completed his job. I had to figure out how to make the modem/router be just a modem by configuring it to bridge mode that would allow our Apple AirPort Extreme Wi-Fi router to manage our home network configuration.

The way I figured it out was that our Apple router had a 192.16.1.1 address (Windows network numerics) as the default router and I knew then that their replacement modem was operating as a router, too. That’s when I called Blighthouse yet again.

They configured the modem/router remotely to bridge mode and our home network began working as it had with our original two-year old NetGear modem that exhibited dropouts.

As for backstory, April Fool’s Friday 2016 was the second time they had dispatched a rep to install their “modem,” that same week. On the previous Wednesday, the rep didn’t even recognize the NetGear modem that Blighthouse recommended we buy and install (the modem that became suspect for our network dropouts). Then when I told him our router was on the lower shelf in the stand right in front of him, he picked up the Synology NAS box on the middle shelf, as he thought that was our router. I corrected him multiple times.

Then once the Wednesday guy got their replacement modem installed, our router complained with an error about not being configured correctly. The guy had no idea what to do. That’s when I told him to pack it up and get out.

Then that Friday with the final field support rep, the same Apple router error occurred. However, this time, after a few minutes, the router somehow adjusted itself and the error message went away. After getting the Apple router working, he should have known to configure their new modem/router to be in bridge mode, just as I had finally figured out by calling their phone support rep to fix.

I also suggested we inform the Wednesday rep how he had installed it correctly but hadn’t waited. But this successful rep told me he was a contractor and not a Blighthouse employee, although they sent him to us as a “field supervisor.” He also said without me having a receipt, which I did not have, he couldn’t identify who the rep was on Wednesday, and added that the Blighthouse employees don’t know what they’re doing beyond a simple home installation.

My biggest issue is the longevity quality with these modems, in general. I decided to rent a Blighthouse modem because this purchased NetGear modem was only two-years old, out of warranty, and I don’t want to have to buy a new modem every two years. I’ve learned network gear is low-quality after any length of time. That too applies to the Apple router we had to replace weeks before the new modem, without any clue why it died. Apple can’t even determine why their router failed but instead expect people to replace it with a new or refurbished one.

As you can imagine, each time I called Blighthouse to report the dropouts while we slowly isolated the problem finally down to the modem, I’ve had to walk each phone support rep through all of the steps we’d done up to each point in time, even though it was documented on our account. It appears they can’t read or write, or both. When they failed to understand the issue and “robot-repeated” their corporate customer script, I escalated to a supervisor. That’s when it was a pleasure to find someone who actually understood the problem and we were able to make progress.

One final note that I don’t know if it’s published anywhere is that they can put a “device watch” diagnostic utility on the modem to monitor and record the signal to the house. However, once you do that, you have to find someone in their Internet customer support group to do anything with the logs. If you call the regular support group, they go brain-dead and have no idea what device watch is or who to transfer the call to for them to take any action.

Fixing this simple problem has had to have cost them hundreds, if not thousands, of dollars simply because of ignorance and lack of followup training.

In the final minutes after installing the replacement modem, my ignorance was about where the DDNS is configured for our network. For some reason, I go brain-dead when it comes to the outside access and which part of the network gear does the addressing, internally and externally. After all these final installation issues, I now will remember it’s the router, silly.

The day I originally published this post is the day after the final modem installation, and it’s only for testing to confirm the NetGear modem wasn’t causing the dropouts. So far, none.

NOTES

EOP stands for Ethernet Over Power. This technology is a standardized product of HomePlug Alliance where my long-term close friend, Rob Ranck, is CEO.

POE stands for Power Over Ethernet. This technology is a product of IEEE standards defining the use of DC power on a Category 5 (aka CAT-5) cable with RJ45 connectors. This has become the standard method of providing power to network-ready devices, like IP surveillance video cameras.

EOP/POE is the combination of both standard features in a single device. A EOP/POE adapter product (COP-Systems offers this product on eBay) replaces two adapters to accomplish both features, having only one standardardized feature per unit.

Android Tablets are ViewPix Frame prototypes running a picture slideshow. These Frames are designed for the senior market where families wish to contact elderly parents with video calls.

The reason for mentioning the front-facing camera, in the intro above, is to include this note about my installing an IP surveillance camera app on the Android Frame. I prototyped this feature by configuring an IP WebCam app to demonstrate its ability to be added to IP camera surveillance software that records this Frame’s video camera stream. In this configuration, Digital Watchdog Spectrum server software manages the Frame IP camera and records its video stream. This is illustrated in the floor plan at the link below, near the middle of the page.

Orlando Configuration Floor Plan 2016

Vet Scam Butchery

Posted on 26 January 2015 by fgould

It was March 2009 when Troy and I brought our second Rottweiler home, this time an eight week old male. We talked to a plethora of people about raising this puppy as close to perfect as we could. Our vet was very informative with a very favorable reputation in our community in that they are the primary service providers for the Orlando Police department canine unit.

Because we had been warned to get an early neuter to prevent Freddie from raising his leg to pee, after five months, we asked for the surgery. Everything went well and after a year we decided to adopt another more active puppy, a Boston Terrier, whom we named Ziggy. Layla, our oldest rottie, turned out to be Freddie’s half-brother, by accident, because when their mother was in heat, one of the breeder’s males was able to inseminate her, and thus our Freddie boy was born.

Freddie is a wonderful dog being social and loving towards people. He runs to our neighbor’s front door on a regular basis hoping she’ll let him in to visit. All of our neighbors comment how friendly Freddie is to them and they love him. After both Ziggy and Layla experienced leg joint problems that Glucosamine fixed, we were blessed to see Freddie have no symptoms of any problems. In addition to leg problems, Layla had a thyroid problem that took months to recover, and we were pleased to see her return to a normal lifestyle and energy.

But then one day on a family walk when he was a little over 5 years old, Freddie yelped, fell to the ground, then jumped up with a wounded right rear leg. We were shocked. We walked home and made an appointment with the vet only to learn that it appeared he had sprained his muscle. The symptom was that he held his leg off the ground and hobbled on three legs when walking. The vet recommended we give it some time to see if it returns back to normal. He never told us to limit walks or playing, so we continued to do so with no improvements.

During the next couple months, we continued to walk the dogs on a regular basis but Freddie never regained his leg use. Then one day, totally unexpectedly, he yelped while lying still on the couch. That was the last time we took his injury lightly and repeated a trip to the vet.

During this visit, the vet surgeon, who had not inspected Freddie before, suggested we take him to a specialist surgeon who could perform an operation on the leg to realign his cruciate ligament (CCL, like ACL in humans). Since we had an X-ray exam the first time we visited the vet, we knew it had to be something more than just a sprained muscle. Then we got serious about researching this problem and not relying on the vet diagnosis.

It was during our research, we found many articles about conservative management before considering surgery. Following the vet’s advice, we scheduled a surgeon appointment for a few days in the future but filled our heads with anecdotal evidence. One author claimed to refute most “scientific” facts, as in the article at the link below.

Questioning Canine Cruciate Ligament Surgery

Others went as far as to say that early neutering changed the hormonal levels that would help bone and tissue development had they not been neutered earlier in life, as in the article below.

Don’t Neuter Your Dog YET – Read This Life-Saving Information First!

At this point, it was too late for the conservative care before the surgeon appointment. We listened to the surgeon tell us that we should have surgery soon before it advanced into a worse condition. After the surgeon told us of three options, we decided to wait for 8 weeks to see if Freddie regained his leg functioning.

The three options included the following and their estimated pricing.

TPLO Surgery (tibial plateau leveling osteotomy): $1,500
TTA Surgery (tibial tuberosity advancement): $3,500
TTO Surgery (triple tibial osteotomy): $4,500

More can be learned from the article below. What offended me most was that everything we read said TPLO would never work for large dogs and is a waste of money. The surgeon responded that she was offering all the options. But that was not an option and would be deceitful to those not knowing the difference.

Different Types of Surgery for Dog ACL Injuries

During our 8-week rehabilitation period, we refrained from walking Freddie. Because he whines for unknown reasons we call him a “Rott-wheiner” and for that reason we chose not to confine him from jumping up on the bed or couch, as articles suggested. He ran in the yard occasionally for short distances but outside that, he was restricted for 8 full weeks from his normal walks.

Since Christmas eve 2014, Freddie has now been walking daily that includes off-leash running, jumping, and climbing and declining down 45 degree hills. His leg shows very few symptoms and appears normal. We feed him a Glucosamine tablet once a day, mainly for precaution.

We have now learned that neutering should be after the dog is full grown and that our Boston Terrier, whom we never neutered, has not run off seeking a female in heat. We hope that this article helps others with a difficult decision to butcher their dog and that patience worked for us. It is a sad reflection on the animal healthcare profession where mutilating an animal by a human is acceptable, even if they cannot guarantee it won’t happen again.

Epilogue

on 25 September 2016, Freddie died of hemorrhagic gastroenteritis, a rare disease caused by bacterial infection usually fatal within 24 hours. This was another lesson learned the hard way, to watch him die in our arms, hopelessly. However, once he recovered from the CCL, he never had a problem again for the rest of his life.

Goddard Recovery Day

Posted on 3 October 2014 by fgould

Yesterday, 2 October 2014, was a recovery day for the residents of a Goddard Avenue home in Orlando, Florida. Troy and I had lost two important items in our lives due to accidental casualties in their daily activities: Quad-copter propeller and Ziggy’s Big Blue Ball (BBB).

ARDrone2 Ziggy Big Blue Ball

The prop failure was caused by too many learning-curve practices that resulted in crashes that ultimately caused a motor to fail. Below is an illustration of what had to be replaced to get the Parrot AR Drone 2.0 back up and running. The blue rectangle contains the parts that were first replaced on each of the four arms: Prop, two gears, and axel. The hardest part of this exercise was aligning the axel at the top of the prop so that the C-clip slid into the microscopic slot at the end of the axel.

So, Troy and I replaced all the props and mechanical pieces to test if the motor would start working; it didn’t. So Troy ordered the replacement motor and it arrived the day before yesterday.

prop arm graphics

Yesterday morning, I replaced the motor and leg, the latter had continued to break off in crashes with any minute stress, like replacing the motor. The yellow arrow above identifies the motor that also included a small printed circuit board (PCB), see below, and the white arrow indicates the seam in leg where I glued the leg back (it actually stands slightly taller than the rest so it is no longer a flat plane when on a flat surface).

Drone Motor The above illustration is to give you an idea how small the parts are for this drone. The six microscopic screws had to be pressure inserted into the PCB holes and then aligned beneath the top casing where the last three screws secures the top, the board, and into the bottom casing of the prop arm. It worked, first time trying!

This time I purchased Loctite Impact Resistant Superglue to glue the leg back on the base of the prop arm. Before, I had tried Loctite Special Plastic Superglue that didn’t appear to bond properly. Well, after a day of practice, the copter has crashed twice, using the new glue, and the leg is still attached.

The other replacement was a late evening ball playing incident that resulted in an unretrievable ball in the dark. After many days of rain, the ball was not needed because it was too wet to walk or play ball in our neighborhood park. This afforded me time to search the local area, not remembering (it was late) where I threw the ball.

At lunch, still yesterday, I ate at Beefy King before searching the stores for a replacement ball. After the first pet store, Frank found the ball at Sports Authority, a little further down the road. It worked. Ziggy is now suckling and flying in the sky for his Big Blue Ball!

And finally, below is a cropped picture from the drone test flight yesterday of me flagging the drone while wearing the Oregon State University tee-shirt that Rob Ranck gave me. This is just days before Frank planned to drive to Tampa to meet up and celebrate Rob’s anniversary with his wife Cathy.

Frank Flagging

While at Beefy King, a patron cheered me and said, “Go Beavers!” It took me a minute to figure out what the guy was saying!