Goddard Sentinel Rover Prototype 1

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.

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:

  1. 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.
  2. Ordered Pan/Tilt arm, RPi3B+, 16 Channel PWM/Servo Motors HAT.
  3. Ordered Devastator Tank Wheel Chassis to test 6V DC Motors.
  4. Wrote software to control Pan/Tilt arm with IR camera head mounted.
  5. 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.
  6. Ordered two DC Servo Motor Driver Boards and fried one of them; the other vendor deemed inoperable and replaced.
  7. Failed to control 360 servo motor probably due to fried boards above. Pan/Tilt servos experienced inconsistent results.
  8. Ordered MoPower UPS version 2 board for future Solar Panel
  9. Fried RPi3B+ and 16 Channel PWM/Servo Motors HAT.
  10. Ordered RPi3B+, 7″ touchscreen, and case to be used for remote controller – UPS lost package in Florida.
  11. Built 16GB SD cards for Rover and Remote Controller – See Build Requirements below.
  12. Redesigned to use and ordered RPi3B, RasPiRobot DC Motor Driver Board, and different brand/connections PWM HAT.
  13. Built Devastator Tank Wheel base.
  14. 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.
  15. 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.
  16. While waiting for parts, wrote a short essay about my learning experiences with this project.
  17. 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.
  18. Successfully installed the new, handmade, 90 degree angle female pins onto the GPIO header and mounted both the SunFounder PWM and thermometer boards.
  19. 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.
  20. 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.
  21. 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.
  22. 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. 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.
  24. 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.
  25. 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.
  26. 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.
  27. 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.
  28. 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.
  29. 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.
  30. 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.
  31. 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.
  32. 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.
  33. 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.
  34. 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.
  35. 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.
  36. 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.
  37. 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.
  38. 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.
  39. 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.
  40. 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.
  41. 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.
  42. 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.
  43. 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).
  44. 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).
  45. 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. Install new 4-pin JST connectors and wires for Fans and Motor power.
        1. Because it’s not powered, Move Stepper Motor Board to top of stack.
        1. Install and get kuzeyron PH code working between new RPi-remote and rover.
        1. Test and make turning work and abilities outdoors.
        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. Change name on RPi 3B from rover to remote.
        1. Install RPi 3B with spacers.
      1. Reprint case with HDMI hole larger.
  46. 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’
  47. 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.
  48. 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.
  49. 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.
  50. 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.
  51. 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.
  52. 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.
  53. 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.
  54. 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.
  55. 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.
  56. 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.
  57. 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.
  58. 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.
  59. 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…remote-control-screen-photo
  60. 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):remote-control-screen-interiorvideo_snapshot
  61. 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.
  62. 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.
  63. 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.
  64. 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.
  65. 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.
  66. 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.
  67. 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.
  68. 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.
  69. 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.
  70. 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.
  71. 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)
  72. 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.
  73. 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
    • drone_app_ui1
  74. 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.
  75. 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:
  76. 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.
  77. 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.
  78. 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.
  79. 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.
  80. 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.
  81. 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.
  82. 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.
  83. 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.
  84. 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.
  85. 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.
  86. 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.
  87. 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.
  88. 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.
  89. 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.
  90. 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.
  91. 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.
  92. 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%.
  93. 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.
  94. 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. Replace 2500mAh battery with 5000mAh battery – requires spacer.
      2. Mark the motor 4 pin connectors with black and blue ink.
  95. 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.
  96. 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.
  97. 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.
  98. 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).
  99. 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.
  100. 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).
  101. 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.
  102. 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.
  103. 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.
  104. 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.
  105. 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 🙂
  106. 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.
  107. 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.
  108. 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.
  109. 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.
  110. 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.
  111. 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.
  112. 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.
  113. 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. 
  114. 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.

  115. 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.
  116. 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.
  117. 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.
  118. 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.
  119. 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/
  120. 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. 
  121. 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.
  122. 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.
  123. 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.

  124. 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.
  125. 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.
  126. 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.

  127. 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.
  128. 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.
  129. 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.  
  130. 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.
  131. 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

1 thought on “Goddard Sentinel Rover Prototype 1

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s