Electronics Box Block Diagram

The block diagram is shown below. 

Electronics Box Components Function

The electronics box has a 2-layer architecture: 

1. Autonomy layer, provided by Raspberry Pi running ROS

2. Realtime layer, provided by ESP32 running FreeRTOS in an Arduino environment

The Autonomy layer provides mission planning and execution control, including overall direction control and vision-handling. The Realtime layer provides the interface to the mower, and odometry and other low-level data that should be handled in a realtime manner.

The Raspberry Pi is network connected by a Picostation Wifi device which allows communication to the home Wifi access point and thereon to the internet. RTK GPS corrections are obtained over Wifi from an internet corrections source (rtk2go).

The ESP32 runs the realtime software at a 20Hz loop rate. The realtime software comprises:

• The RL500Comms task which drives the mower via a serial link wired to a jack that plugs into the back of the grey control box recessed into the top of the mower.

• The Odometry task, which measures the time between odometer sensor pulses and reports odometry data

• The PiLink task, which passes messages back and forth to the Raspberry Pi.

HW Configuration

Mobot's HW configuration is:

Compute Subsystem

• Raspberry Pi 4B with 8GB memory, 16GB SD card, for autonomy processing. Serial ports connected for console access, connectivity to ESP32

• StarTech.com SATA to USB Cable - USB 3.0 to 2.5" SATA III Hard Drive Adapter (Amazon)

• Samsung Electronics 870 EVO 500GB 2.5 Inch SATA III Internal SSD (for faster boot, updates, log storage) (Amazon)

• Atolla 4-port powered USB hub with USB 3.0 Data Ports (Amazon) - used to power camera, SSD from external power (Amazon)

• Sparkfun Thing Plus ESP32 board with under-mounted protoboard for wiring, level shifters

Sensors

• Sparkfun GPS-RTK-SMA breakout ZedF9P

• Adafruit 9-DOF Absolute Orientation IMU Fusion Breakout - BNO055

Comms: tailscale + DDS configuration

• As shown on system diagram, RPi can connect using its wifi to home network, or to the Botphone's wifi, which puts it on the internet

• TODO: make wifi SSID selection available via CLI

• tailscale VPN runs on laptop and RPi, providing peer-to-peer comms. Allows ssh, git etc when robot is remote and not accessible via the wifi segment the laptop is on

• DDS needs configuration because VPN doesn't support multicast, so ROS2 discovery doesn't work. See this link for ROS2 DDS configuration options: https://github.com/ros2/ros2_dds_profiles_examples

• I use unicast_discovery_from_another_host.xml, with host-based selection of profile by a .bashrc script run at login which sets the proper environment variable to cause DDS to use unicast discovery

Power Subsystem

• Daly Smart BMS 7S 24V 30A Li-ion BMS (Amazon)

• SSR-25DD Solid State Relay Input 3-32V DC output 5-60V DC) with heatsink (Amazon)

• DROK DC-DC Buck Converter 12V/24V to 5V 5A/25W to power robot electronics (Amazon)

• Maxmartt 50A Solar Panel Battery Charging Ideal Diode (Amazon)

• Turnegy 4S 5Ah battery from Hobbyking.com

• Turnegy 3S 5Ah battery from Hobbyking.com

External equipment

• Voyee Wireless PS3 gamepad for teleop-ing robot

• Laptop 19V 3A power supply for shore power / charging

• DC DC Buck Boost Converter Variable Voltage Regulator CC CV 0.5 - 30V adjustable power supply

• Ubiquity Rocket 2 access point mounted in attic. Associated POE injector to connect to home network router

Electronics Box

This section shows the construction of the electronics box and associated HW. The picture below shows the electronics box without its lid, wired to the controller. The mower-encoder signals are tapped into inside the mower chassis and brought to the electronics box via a connector under the box.

The rear of the box is a flap that can be opened for maintenance when the box is removed from the mower. Mounted to it are a Raspberry Pi running ROS and ethernet-connected to the wifi station. Beside the Raspberry Pi is a box containing an ESP32 microcontroller running FreeRTOS in the Arduino environment, and a Ublox ZED-F9P GPS receiver. Under the ESP32 is a level-shifter proto board, which converts the 5V encoder pulses to 3.3V. 

The picture below shows the rear view of the electronics box with its flap open and its lid beside it. Labels identify the RPi, GPS receiver, ESP32 on the flap, as well as the Picostation which provides wifi access, and the powered USB hub which provides power to the high-power devices (camera, SSD). The lid with GPS antenna and the depth camera are identified. 

A clear plastic mid-plane  mounting plate holds the wifi station, POE injector, USB hub and SSD. The wifi station is a Ubiquity pico-station that links to a Ubiquity Rocket M2 access point in the attic of my house. The SSD is mounted to the back side of the midplane. See the picture below.

The front wall of the box is the power plane, with an ideal diode, 24v->5V converter, SSR and terminal strips. See the Power Subsystem section for design details. See the picture below, which is taken with the midplane removed from its mount and folded rearward. The SSD on the midplane can be seen. The antenna for the Picostation can be seen mounted to the front right wall.

Looking down from the top of the electronics box, the BMS and IMU are labeled. They are mounted to the base of the electronics box, below the rear flap and midplane assemblies..

Mowbot is shown below without its cover. The 3 blade motors and two drive motors can be seen, encircling the single large control board which handles the serial protocol from the electronics box and contains the motor drivers..

SW Operation

Use Cases

• Reset/Restart Autonomy Layer or Motion Control Layer and system resumes operation

• Stop Autonomy Layer and robot stops in safe state

• Run Autonomy + Motion SW in simulation (for system test/dev purposes)

• System cannot complete mission, so cancels it. (Examples: cannot escape bumper press, critically low battery)

• Analyze logs & bags from runs, with visibility into all important aspects

SW Requirements

• • System shall transport packets between Autonomy Layer and Motion Control Layer with integrity checking

    1. System shall drop packets that fail checks

    2. System design shall be tolerant of dropped packets (Hi-want)

  • System shall have modular design (non-functional)

  • System shall provide realtime performance for motion control loops

  • System shall ramp wheel velocity to requested level at an achievable rate. Rationale: steps in motor power may produce perturbations.

  • System shall log important motion-control layer data to bag files

SW design

The image below shows the block diagram of the SW that runs in the electronics box.

The ROS SW repo is at https://github.com/PaulBouchier/Mowbot

The ESP32 FW is in several repos:

• MowbotRealtime - the main project that instantiates the library components and provides the Mediator pattern: https://github.com/PaulBouchier/MowbotRealtime

• PiLink - the ESP32 side of the link to the RPi: https://github.com/PaulBouchier/PiLinkTest.git

• Encoder task: https://github.com/PaulBouchier/PiLinkTest.git

• RL500CommTask. This repo is not public, because it currently contains the proprietary RL500 comms protocol. It may be released in part in the future (without the proprietary mower messages).

Odometry & Drive Train

Mowbot Drive Train Measurements

Gear Sizes

• Motor gear: 18 teeth

• 2nd gear: large: 87 teeth, small: 21 teeth => ratio: 4.83 from motor

• 3rd gear: large: 81 teeth, small: 17 teeth => ratio: 3.85 from 2nd gear

• 4th gear (wheel drive):  60 teeth => ratio: 3.52 from 3rd gear

• Total gear reduction: 65.45

• Wheel diameter: 26cm => wheel circumference: 0.817m

Hall effect sensor toggles each time a magnet goes by. Two magnet passes/motor revolution. Sensor holds output from last sensor until the one on the opposite side passes over it, when it toggles. i.e. output toggles each half motor rotation, complete cycle each rotation.

At max speed (manual operation on blocks), wheels turned 19 times in 30 sec, i.e. 0.63 rot/s => 0.517m/s => 41 motor revs/sec at max speed. Therefore I will see 41 cycles (80 transitions) per sec at max speed. Each cycle represents 0.817m/65.45 = 0.012m of wheel movement. Each transition represents 0.0062m of wheel movement. At full speed, transitions will happen every 12ms, at 1/4 speed every 48ms. i.e. with a 50ms control loop, only get 4 transitions/cycle at full speed, 1 transition/cycle at 1/4 speed. IOW not enough transitions to control wheel speed. 

Proposal: Control period between transitions

Block diagram and sample timing diagram shown below.

Encoder ISRs place timestamps into queues each time a left or right encoder changes state (each half motor revolution). The MowbotOdometry task pulls the encoder change timestamps out of the queue every 50ms and processes them to develop leftSpeed and rightSpeed, and the robot pose x, y, and theta.

ESP32 Design

The ESP32 embedded computer is mounted on a carrier which contains TTL->3V converter logic, and terminations for other electronics managed by the ESP32. The HW block diagram is shown below. The level shifter is a Sparkfun BOB-12009 or equivalent

The ESP32 runs FreeRTOS as shipped from the factory. It is used to ensure that the IP stack gets sufficient run-time on CPU-0. The PlatformIO development environment is used to create the software system, which spawns several tasks when it starts:

• RL500CommsTask: handles a queue of requests going to the mower serial port and status coming back

• PiCommsTask: handles the COBs protocol used to pass messages between the ESP32 and the RPi

• EncoderTask: Handles encoder transitions and computes odometry. Reads magnetic heading from BNO55 and populates odom_extra

The design is highly object-oriented, with each spawned task running in an object which may contain other objects appropriate to its function.

The design uses the mediator pattern, in which a mediator object acts as an interface to each of the other classes, so that none of the other classes (MowbotOdometry, RL500CommsTask, PiLink, TxLog, TxOdometry) need have direct interfaces to each other - they all go through the MowbotMediator object to communicate with each other. This simplifies testing each object by itself - a dummy mediator sufficient for that object's interfaces is all that's needed.

Dev Environment

ESP32 code is developed with the PlatformIO extension to VS-Code. The workspace definition is on Paul's laptop in ~/Documents/PlatformIO/Projects/MowbotEsp32-workspace.code-workspace. There are 4 projects that make up the codebase:

• MowbotRealtime: Contains the MowbotMediator  object, and instantiates the other major objects (RL500CommsTask, MowbotOdometry, PiLink), to which it retains references. It passes a reference to itself to each of the other major objects. It does not run its own task - tasks call through it to communicate with mediated objects. Code is in https://github.com/PaulBouchier/MowbotRealtime

• MowbotOdometry: Contains the MowbotOdometry object. Code is in https://github.com/PaulBouchier/EncoderTest. The object's init() function spawns the task that runs this object .  The task reads encoder pulses and tracks odometry and reads IMU data from the BN055. MowbotMediator is its interface to the other ESP32 tasks.

• PiLink: Contains the PiLink object. Code is in https://github.com/PaulBouchier/PiLinkTest. The object's init() function spawns the task that runs this object. The task sends and receives messages from the RPi over the serial link. MowbotMediator is its interface to the other ESP32 tasks.

• RL500CommsTask: Contains the RL500CommsTask object. Code is in Paul's dropbox: Dropbox/GitRepos/RL500CommTaskTest.git. It is private at this time because it exposes the BIT interface to the RL500, which is the subject of an NDA.

MowbotRealtime Startup

The system follows the Arduino model for startup: the setup() function is called once, then the loop() function is called continuously.

MowbotRealtime/src/main.cpp contains the setup() entrypoint for the software system. The module instantiates the MowbotOdometry, PiLink, and RL500CommsTask classes. The module also instantiates messages used by each module to communicate.  The Arduino setup() entry point calls each object's init() function which spawns the task that does that objects's work. The loop() function does no work.

The module provides a library in MowbotRealtime/lib/MowbotRealtime/src which mediates calls from the three tasks and passes them on to the proper object for servicing.

RL500CommsTask

This task contains messages that are passed between it and the mower. There are two general kinds of message: TxMsg going to the mower, and RxMsg coming from the mower.  It also contains a request queue upon which other tasks can place various kinds of RL500TaskRqst messages. RL500CommsTask pulls requests off the request queue and actions them by interacting with the mower. Requests can be things like motor speed request, BIT-mode request to put the mower into BIT mode, light-mode request to set the light on or off, and so on. A block diagram of the objects used by the task is shown below.

MowbotOdometry task

To be written

RPi4 and Rpi Zero 2W Configuration

This section describes how to install an Ubuntu OS onto an SSD on a Raspberry Pi and to configure it for developing ROS software.

User bouchier is the main user account on both laptop and the RPi and inside the ROS docker container, and has ability to commit to github from either laptop or rpi4, and to ssh from laptop to rpi4 without needing to enter a password. 

rpi-imager Configuration

In this step we connect the boot media (typically SD-card, but could be SSD) to the laptop, run rpi-imager to install a firmware update image or an OS image, then reconnect the boot media to the rpi and boot the rpi from it.

• Load the latest rpi-imager on to your laptop. At least 1.8.4 is needed.

• Install the firmware updater and update the rpi board firmware

• Install Ubuntu 22.04. Configure initial user account, password, and networking parameters, and enable ssh before writing the boot media by using the "edit boot options" function. 

• Connect a monitor and keyboard/mouse, connect the boot media to the rpi and boot

• Verify remaining space is sufficient. 

RPi4 SSD Boot Notes

• Updated RPi firmware to latest

• Installed Ubuntu 22.04 to SSD using rpi-imager running on my linux laptop, with SSD connected to laptop

• Booted RPi from SSD

• I found it important to run the SSD off a powered USB3 hub - it would get disk errors and disconnect if run directly off the RPi USB3 port

• I found doing a proper power-cycle to be important. If I only power-cycled the RPi, or switched the disk off/on, it could hang and refuse to boot until I power-cycled the electronics module.

Disk I/O Benchmark results

Insalled and ran the storage benchmark test with the following command:

which gave the following RPI4-with-SSD performance results, which are about in the middle of the range of reported results:

The RPi zero 2W with SD card gave the following performance results:

RPi4 Firmware Config

This section describes settings in the boot config files, and associated pins. The only change required is to modify config.txt and cmdline.txt See the table below for the mapping of UARTs to pins, devices, and use. All 5 UARTs are enabled.

• Precondition: Booted the RPi with an external monitor and Keyboard/Mouse

• Open a terminal in the GUI and edit /boot/firmware/config.txt using vi or nano.  Add the following lines:

• Add the following lines to file /boot/firmware/config.txt to enable serial console on UART 2, 3, 4 and 5 (/dev/ttyAMA2-5):

• Reboot and check that /dev/ttyAMA2-5 exist. Reference: see discussion of how to enable serial ports here.

• Edit /boot/firmware/cmdline.txt and replace "console=serial0,115200) with "console=ttyAM4,115200". and remove the boot options "quiet". This causes the OS to output boot messages to the serial console

RPi Zero 2W Config

This section describes settings in the boot config files. The only change required is to modify config.txt and cmdline.txt.

• Precondition: Booted the RPi with an external monitor and Keyboard/Mouse

• Open a terminal in the GUI or use the command line and edit /boot/config.txt using vi or nano.  Add the following lines:

This causes the OS to present a login on the serial console, and to print boot messages to the serial console.

• Edit /boot/cmdline.txt and remove the boot options "quiet" and "plymouth.ignore-serial-consoles". This causes the OS to output boot messages to the serial console

Verify serial console and networking (RPi4 and RPi Zero 2W)

• Connect a USB serial cable to the RPi Serial console connection, and on the laptop, run miniterm /dev/ttyUSB0 115200 to connect from PC to rpi via USB serial. Reboot from the monitor/keyboard and verify you see boot messages come out on the miniterm terminal. Verify you can log in. The USB-serial connection is your back-door into the system in case you're in the field and can't access the rpi through ususal methods.

• The miniterm command uses .bash.aliases: alias miniterm='python -m serial.tools.miniterm --eol LF'. But cursor movement commands don't work: backspace, vi is crap.

• Use the monitor/keyboard to connect to Wifi. Check you know the IP the rpi was given, and ssh to it from your laptop to verify the ability to connecto over the network.

• Use the keyboard/monitor to shut down the board, or use the poweroff command. Disconnect keyboard/monitor, and reapply power. Verify you can ssh to the board after it boots.

Ubuntu OS Configuration

These are the steps to configure Raspberry Pi OS on Mowbot's RPi once it has been installed and is bootable. 

• change /etc/hostname as appropriate. Edit /etc/hosts to make <hostname> a name for 127.0.1.1

• Add the hostname of the rpi and it's IP to the laptop's /etc/hosts file

• Ensure ping www.google.com works

• Update and upgrade list of packages. sudo apt update; sudo apt upgrade

• From laptop, install user bouchier's ssh public & private keys to allow rpi to commit to github: scp .ssh/id_rsa* bouchier@<hostname>/home/bouchier/.ssh

• On laptop, create .ssh/config file that causes ssh rpi4 to connect to host rpi4 as user bouchier. .ssh/config should contain the following:

• Optional (seems important for rpi zero 2W): Increase swap size using these instructions: https://pimylifeup.com/raspberry-pi-swap-file/

Mowbot Ubiquity Config

•  Plug in the ubiquity microstation or a wired ethernet cable

• Apply the netplan: sudo netplan apply

• Check link status: ip addr show dev eth0

Package Installation

This section describes installation of packages needed to make ROS on RPi work as desired. Note: some of these steps are no longer necessary if using the 1.8 version of rpi-imager; it does a lot more to pre-configure the system.

VNC

VNC was chosen for graphical use because generally the robot's RPi would run headless, but remote desktop capability is sometimes valuable. 

Observations: the current version of RPi OS doesn't support the RealVNC server which ships with it, owing to it using Wayland and RealVNC using X11. Tigervnc is the recommended alternative

• install tigervnc-standalone-server

• edit /etc/tigervnc/vncserver-config-mandatory to uncomment $localhost="no" so as to allow remote connections

• Run tigervncpasswd and set a password

• Install xterm

• create the file xstartup inside the .vnc folder:

dbus-launch --exit-with-session /usr/bin/gnome-session --systemd --session=ubuntu

• manually start tigervncserver on mowbot

• Test vnc: on laptop: xtigervncviewer -SecurityTypes VncAuth,TLSVnc <hostname>:1

• Kill the vnc session on the rpi with tigervncserver -kill :1

• To run firefox or chromium within a vnc window, do xhost+, then ssh localhost then export DISPLAY=:1 then launch firefox from the ssh terminal

• 
  

tailscale

• Install tailscale using the instructions for linux at tailscale.com. 

• Open a VNC window to the robot and launch a browser and go to the URL printed by the install script. Note the issue below in "Notes" on a special way to get a browser to run in a VNC window on Ubuntu 22.04

• Run "sudo tailscale up" on all devices that are to be on the tailnet

• Make an entry in the laptop's /etc/hosts for a hostname of each tailscale robot RPi. e.g. mowbotv (for vpn) and it's tailscale IP

miniterm

Configure python for miniterm, (serial port access from python, etc). sudo apt install python-is-python3; sudo apt install python3-pip; Add the following to .bash_aliases: alias miniterm='python -m serial.tools.miniterm --eol LF'

git config file (~/.gitconfig)(

Configure git to use my favorite aliases & tools. Note that git difftool would have to be run in a VNC window, since it uses meld, which is a graphical diff app. Add the following to ~/.gitconfig. Note: the indented lines need to be preceeded by tab, not spaces

Install other packages

Install the following packages:

apt-utils vim-gtk3 wget inet-utils-ping inet-utils-traceroute net-tools xterm terminator python-is-python3 python3-pip

Make ROS source directories

• mkdir -p ros2_ws/src

Install ROS2

• Follow the directions at ros.org to install the appropriate version of ROS2 for the Ubuntu version you installed. I installed the desktop version. Test the installation using the talker and listener apps as shown in the instructions.

• Follow the instructions in the Tutorials -> "Beginner: CLI Tools" -> Configuring the environment.

• Follow the instructions in the Tutorials->"Beginner: Client LIbraries" -> "Using colcon to build packages"

• Install the following additional packages on the laptop: ros-humble-swri-console ros-humble-plotjuggler ros-humble-plotjuggler-ros

DDS Configuration

These steps set up mowbot to run ros programs using the unicast configuration of astdds discovery. The discovery configuration is pointed to by the environment variable set by .bashrc. The configuration file is based on unicast_discovery_from_another_host.xml in the fastdds directory of this repoa; https://github.com/ros2/ros2_dds_profiles_examples

• add the following to .bashrc of all hosts, substituting the name of the profile file as appropriate:

• Create a file in src/Mowbot/robot_hardware/config called <hostname>_fastrtps_profiles.xml which is based on :unicast_discovery_from_another_host.xml noted above, with the other host's tailscale IP address substituged as appropriate

• Source .bashrc and ros commands will use the unicast discovery profile

Message to Karim:
After considerable testing with talkers and listeners in different places, I've concluded that the version of ROS2 I'm running (humble on x86-linux-ubuntu22.04 and humble on arm64-ubuntu22.04 (RPi) just doesn't work the same as yours - if I don't have the InitialPeersList correctly populated, the local or remote subscriber may not receive published messages. Reading the comments in the file from the ros2_dds_profiles_examples repo (which is part of the official set of ros2 repos), it appears that the interface whitelist is the interfaces that DDS will use. In your case you're listing an interface that doesn't exist (it's on the other machine), but that appears to be benign. The InitialPeersList is what I find has to be populated with the remote machine first, and the local IP last. If the local IP isn't in the list, local subscribers won't get messages published by a local publisher; same if it's not last. The remote end will receive regardless of the order, but it won't receive it's own publications if its IP isn't last. The stock file also has an extra element that you don't show: after </InitialPeersList> it has: <metatrafficUnicastLocatorList> <!--This will disable multicast spdp, while still enabling unicast.--> <locator/> </metatrafficUnicastLocatorList> I don't know what that does, beyond what the comment suggests

Mowbot GPS Packages

u-center (dev laptop only)

Install u-center on laptop running Windoze. u-center is a Windoze (x86) tool for checkout and analysis of ublox receivers. 

Download latest version (v22.05) of u-center (not u-center2) from the ublox site. Unzip and run under windows:

UTM conversion

These steps install packages which convert the GPS lat-lon fix to UTM, for easier use with odometry, rviz etc. The GeographicLib which contains conversion routines is installed. The lla_utm_local package which subscribes to the /gps/fix topic and uses the GeographicLib library to convert the fix to UTM and publishes the UTM fix needs to be cloned and built. 

On the laptop I was able to install GeographicLib from apt (sudo apt install GeographicLib-dev or maybe libgeographic-dev). On RPi apt didnt' do a complete install of GeographicLib and I had to build it from the instructions here: https://geographiclib.sourceforge.io/C++/doc/install.html

rviz_satellite (dev laptop only)

The rviz_satellite package provides an rviz plugin that enables viewing robot position in the context of satellite imagery. You need to create your own Mapbox account and get a mapbox api key (www.mapbox.com) and insert your key into the AerialMapDisplay URI. Note: my URI key has been obfuscated in the git repo to limit unauthorized use of my account.

Reference: https://github.com/nobleo/rviz_satellite

Clone rviz_satellite into the dev laptop ROS src directory

ublox

• sudo apt install ros-humble-ntrip-client

• 
  

rtcm_msgs

Mowbot SW Installation & Test

This section describes how to install Mowbot's ROS SW and related packages onto the RPi.

• Install pySerialTransfer: pip install pySerialTransfer

• Clone Mowbot repo, install needed dependencies, and build it: 

• cd src; git clone git@github.com:PaulBouchier/Mowbot.git; cd ..; rosdep install --from-paths src --ignore-src -y; catkin_make. This should complete without errors.

• Verify /dev/ttyAMA1 exists - it is used to talk to the ESP32

• Run the Mowbot start launch file: roslaunch mowbot_bringup start.launch

Depthai camera installation

Follow instructions from https://docs.luxonis.com/software/depthai/manual-install/#Manual%20DepthAI%20installation-Installing%20dependencies

• Installed python3-virtualenv

• Created virtual env with virtualenv venv && source venv/bin/activate

• 
  

Recipes

RTK-GPS

• Start ublox_dgnss node:    ros2 launch ublox_dgnss ublox_rover_hpposllh_navsatfix.launch.py CFG_MSGOUT_UBX_NAV_HPPOSLLH_USB:=1 CFG_MSGOUT_UBX_NAV_POSLLH_USB:=1 CFG_MSGOUT_UBX_NAV_STATUS_USB:=1

• Start ntrip_client. Tested mountpoints are VN1, EMBER1 

  • ros2 launch ntrip_client ntrip_client_remap_launch.py host:=rtk2go.com port:=2101 mountpoint:=VN1 username:=paul.bouchier-at-gmail-d-com password:=Unused 

• launch lla_utm_local:

  • ros2 run lla_utm_local lla_utm_local --ros-args -p local_easting_origin:=692371.60 -p local_northing_origin:=13670689.64

• Check fix accuracy: ros2 topic echo /ubx_nav_hp_pos_llh. Look at h_acc: accuracy in mm * 10. i.e. 1156 is accuracy of 115 mm or 11.5 cm.

• Check whether rtcm is being used:  /ubx_nav_status

• Start mowbot comms node:

  • ros2 run robot_hardware esp_link

• Set BIT mode: ros2 run robot_hardware bit_mode

• run joystick node: ros2 launch robot_hardware xbox_joy-launch.py

• Run scripted_bot_driver servers:  ros2 launch scripted_bot_driver servers_launch.py

• 
  

Basic RL500 Platform Data

Bumpers

• 4 bumper zones: left front, right front, left rear, right rear

• Voltage on bumper sense wires: None detected, yet it senses 1-2 ohms contact resistance when bumper is pressed. Neither black nor white is connected to ground. Possibly polls with a pulse?

• On front bumper, black is common (joined between left & right, so can be used as a common

Motors

• Both sides of motors are at 24V when motors stopped

• One side or the other pulses low (for fwd or back)

• One motor running, no load, drew 0.3A

• One motor running, stalled, drew at least 6A

• Even when heavily loaded or rotor locked and unable to maintain speed there appeared to be PWM-ing going on, implying a current limit feature, with max current around 5-6A. 

Test Results and Observations

RPI4 Performance

• RPi running COBS test decoder decoding 14 byte PacketSerial packet took 20us to decode the packet

• Building Mowbot SW inside a container took 3 min 31 sec. 

RPi Zero Performance

• Running tigervncserver with chromium launched in it, 256MB of memory was used by user processes, the swap daemon was running, and performance was noticably sluggish

• On rpi zero 2w the OS (Full version) used 9.2GB. The OS (lite version) used 1.4G, but was up to 8.8GB after installing dockers for ros1 & ros2. The not-full, not-lite version used 4.4GB for just the OS install. Installing the ros2 docker increased usage to 8.3GB and adding the ros1 docker brought it to 11GB used.

• I increased swap to 1GB

• Building the ros1 and ros2 dockers each took a bit over half an hour. Free memory was frequently below 100 MB and 400 MB of swap was occasionally used. 

• Building Mowbot SW inside a container took 101 min 40 sec, load average 4 - 7! Much swapping as indicated by kswapd consuming significant CPU % in top

• It ran my Robocolumbus code driving the sim (which was runnng on the laptop) and the Robocolumbus code took 30% of a CPU.

• Building Mowbot SW with catkin_make tended to hang even with 1GB swap. Tried -j1 option. It took 88 minutes for a partial build

Power

• BMS phone app doesn't display discharge current, only charge current

• BMS was unable to charge the old 4S + new 3S battery to 100% - peaked at 98% with 30V 1A charge power applied

• BMS bluetooth is off when battery is disconnected.(maybe after a timeout). It wakes back up when a load is placed on the battery

Notes

ZED-F9P

• After 1 minute of no corrections it drops out of RTK Fixed mode. If corrections are re-instated, even a minute later, it very quickly re-enters RTK mode

• If ZED-F9P is powered on and allowed to run without corrections for a minute, it never achieves RTK lock

• ZED-F9P drops out of RTK Fixed mode immediately the antenna is placed on top of the electronics box. Moving it to 0.5 - 1m away allows it to regain RTK Fixed in about a minute, and keep it. Thesis: EMI from the electronics box is upsetting the sensitive amplifiers in the powered antenna.

Starting firefox

• In a terminal. set xhost +

• In another terminal run "ssh -Y mowbot" (can be run from anywhere) then "export DISPLAY=:1.0" then "firefox"