Project Link

Like my Glowbug Project this PCB is designed to use WLED a firmware that works on many Espressif microcontrollers to handle LED effects and control. WLED is fairly extensible with various usermods to handle things like audioreactive light displays, OLED screen output, and so on. This particular PCB is setup to be small form factor but still have the main elements of a fully featured WLED PCB like a fuse, large capacitor, relay, and in addition uses a WCH 224K to allow for 5V 2A power delivery via the attached USB input. I’ve previously discussed the CH224K so opted to go that direction.

This smaller board has the following features:

• USB power delivery power
• Uses a relay to keep power consumption in check
• Uses a fuse to prevent issues
• Capacitor for the LED line
• 3 or 4 wire support for LED strips
• Level shifting the data and clock lines
• IR receiver

In this article I’ll be discussing the schematic for my board, linking the project for the associated board, and demonstrating it in practice.

Careful: Use this board at your own peril. Things seem to be working for me but further testing is warranted before anyone uses it in a production setting.

Project Sponsorship

At this time I want to thank PCBWay for sponsoring this project by providing the PCBs. I’m grateful they put faith in my project and gave me this opportunity. Their website can be accessed for more details about their product line. I like how easy it was to go from my gerber to the shipped product and the boards I received seem of high quality. Their capabilities page has a lot information about what they can help you with. PCBWay really does make it easy to get started, build professional PCBs for your project, and see your ideas come to fruition. Love it.

Schematic rundown

The entire schematic can be referenced from the EasyEDA project directly or via the associated PDF linked here.

Power

This PCB includes a WCH CH224K used for USB PD. As mentioned previously I was grateful to have used this IC a few times prior with WeAct boards I grabbed on aliexpress so I had a decent idea of its capabilities. I took a look over at the WCH documentation for CH224K and from there adjusted my schematic.

This is a fragment of the WCH CH224K documentation linked above. As you can see in this configuration mode one can adjust the resistance of the given pins to request different voltage levels.

WLED configuration

In WLED you can further configure the device. For the ESP32S3 I utilized platform.io with the wled firmware and selected the 4M qspi environment.

Here I’ve selected several GPIO for the various elements such as the IR receiver and relay. These correspond to the values printed on the PCB itself for reference and ease of access. I used the pinout of the Xiao ESP32S3 to find the associated GPIO to use.

Sponsor

Thank you JLC3DP for sponsoring the resin print I used for this project! They also sponsored the large white PCB that connected with the core board. You can visit their site here. I really like the resin print in the transparent style (they sand and use oil for it) as it felt smooth to the touch and it was cool that you can see right through it (I utilized an LED on the board so the transparent cover allowed me to see the LED as it lit up which was great). I highly recommend their services as the 8001 resin type really looks great in this way!

Project Links

• You can see my full article here on the Hackster.io site
• Mouse core board
• Larger board that attaches with the core board

Some background

The contest is an inclusivity based one where entry participants are able to get a “Superbox” of electronics hardware to utilize for various ideas to help people with mobility and vision issues. For this project I was addressing the issue of mobility troubles inside the home. I had taken part in the previous Build2gether challenge and realized that mice generally aren’t designed with disabilities in mind – one of the previous contest masters had discussed the discomfort of normal mice so I opted to use this as my focus.

My mouse

My mouse focused on trying to reduce the amount of movement that would be needed while also making the buttons easy to use with a simple touch. To accomplish this I utilized elastic strings on the perimeter to pull the mouse back to the default position between pushes. When the user puts their thumb on the lowest touch pad I allow the mouse to be moved. In this way the mouse can be reset simply by lifting your thumb and allowing it to naturally pull back into position so one can move around very easily by timing their thumb position as they need to move. Given a mouse allows more control than a thumbstick I believe this allows for maximum control for someone with limited movement range.

Printables link: https://www.printables.com/model/941756-foot-pedal-adapter

Additional Project items (affiliate links):

• Xiao SAMD21
• pcsensor FS2020U1 USB Foot Switch Control device
• 22 Gauge 5 Conductor Electrical Wire

Background

Awhile back I purchased this foot pedal from Aliexpress as a way to add an additional control device to my set of random devices. A big driving factor was that I know it’ll make for a great component to use with future videos so I wanted to do the legwork to get this piece in place ahead of a need.

Initial investigations

I removed the screws from the device’s bottom and began investigating the layout of the circuit board. Upon opening it was clear the circuit is a simple IR emitter and receiver (versus a mechanical switch). The mechanism for signaling in this case was to break that emitter’s line of sight to the receiver with a piece of plastic that falls into the cutout between them as the spring is compressed down by a foot.

My initial investigations of the board left me fairly puzzled. I could see each of the boards was the same. I could also see the power lines were connected.

Initially I was going to use the existing wires coming from the board but realized it powered the sensor by doing a round-robin power setup powering one signal pin at a time while checking the state of the others (using a reverse biased diode to power the board from the main board). This worked well during my testing (setting one pin as power and checking the state of the pedals) but wasn’t feasible for the microcontroller to source that much current from the signal pins. This falstad circuit shows power from the left signal wire, from the middle signal wire and from the right signal wire illustrates a similar circuit setup as the one used by the controller with the 4 wire approach. One of the pins as a power source with the other two acting as an open collector. This approach does work as shown above but it could present a problem for a microcontroller without additional components as the pins wouldn’t be able to source enough current without use of a mosfet for each signal line (albeit one could just use two pins for power).

Luckily, the main board still surfaced the power pin though (each of the side boards is a duplicate of the main) so I realized I could easily replace the wire with a 5 wire one I grabbed from Amazon and be able to use this with my projects going forward.

Wire strain relief component

The original setup used an injection molded piece around the 4 wire cable. This helped to provide strain relief for the wire keeping it from being dislodged from the circuit board. This also unfortunately meant the existing piece would need to be replaced completely. I measured the existing part, adjusted the design slightly, and printed a component.

My original design actually didn’t work here but involved using a PG-7 cable gland for preventing cable movement. The problem related to the top component of the foot pedal as it has a plastic piece which comes rather low. The PG-7, even at the bottom of the replacement piece, just was too high in the piece with its backing nut so it couldn’t be inserted without modifying the pedal shell which I did not want to do here.

As a result I designed a replacement piece that was much simpler and only had the wire going through versus any additional hardware. To aid with wire strain I added holes for a zip tie which can be used to keep the wire from moving.

Wire attachment

I tinned and soldered the wires to the main board, used a zip tie, and crimped the stripped wires on the other end of the board for use with a dupont connector.

At this point the device is ready for use with a microcontroller.

Microcontroller use

Now with the 5 wires soldered and with dupont connectors on the other side it’s easy to get running with a sketch. I connected the red wire to 3V3, black to GND, and used D0-D2 as signal wires.

The code for the logic used in my example is rather simple as well:

#include "Keyboard.h"

const int leftPin = D0;
const int middlePin = D1;
const int rightPin = D2;

void setup() {
  Serial.begin(9600);
  
  pinMode(leftPin, INPUT_PULLUP);
  pinMode(middlePin, INPUT_PULLUP);
  pinMode(rightPin, INPUT_PULLUP);
}

void loop() {
  if (digitalRead(leftPin) == LOW) {
    Keyboard.press('a');
  } else {
    Keyboard.release('a');
  }

  if (digitalRead(middlePin) == LOW) {
    Keyboard.press('w');
  } else {
    Keyboard.release('w');
  }

  if ( digitalRead(rightPin) == LOW) {
    Keyboard.press('d');
  } else {
    Keyboard.release('d');
  }
  
  delay(100);
}

The pins are set to inputs with a pullup. The loop logic simply checks if the pins are reading LOW indicating that the pedal has been pressed down causing the blocker to interfere with the emitter / receiver setup. Once brought LOW the logic emulates the pressing of the awd keys (used with awsd control schemes to move forward and turn or strafe).

Testing

With the circuit in place I opted to test the functionality with the game Rebel Galaxy. In this game the a and d correspond with turning while the w is used for the booster throttle.

Concluding thoughts

This was a neat project that puzzled me for a bit. I definitely felt accomplished figuring out the unique round robin power used here with the initial circuit.

I’d like to design my own foot pedal in the future using a mechanical switch instead of the line break used here. Not sure if I’d reuse the enclosure here or 3D print my own but worth a revisit some day. For now this seems great and I’ll be using this for some projects I have planned.

Link to board project: pcbway

Project Sponsorship

At this time I want to thank PCBWay for sponsoring this project by providing the PCBs. I’m grateful they put faith in my project and gave me this opportunity. Their website can be accessed for more details about their product line. I like how easy it was to go from my gerber to the shipped product and the boards I received seem of high quality. Their capabilities page has a lot information about what they can help you with. PCBWay really does make it easy to get started, build professional PCBs for your project, and see your ideas come to fruition. Love it.

Why make this board?

I have three uses for this board:

• If I want to use UART serial communication with a 5V board I need to level shift for the signals and power to avoid hurting the Xiao with its 3V3 pins
• There are some 5V only i2c devices such as the Seeed Vision AI sensor v2 (you can attach the Xiao directly to the board to get around this but my projects usually use multiple sensors so I prefer attaching it via a cable)
• There are some actuators that require 5V like the Seeed Water Atomization module

In the past I took care of this by assembling an inline DIY level shifter. It works well but I prefer simplicity with enclosures and it makes things a bit more difficult as each DIY board has slightly different dimensions.

Schematic

So first I want to describe the logic here and give an example circuit to play around with it. This falstad circuit is the one I put together to verify my assumptions prior to ordering the PCB. With this setup you can see four different circuits. The top two are 3V3 to 5V which is a fairly normal setup for level shifting while the bottom two are 3V3 to 3V3 so demonstrating the behavior when not level shifting at all. The left two circuits are setup to allow toggling of the logic level on the LV side while the right two allow toggling on the HV side. In this way both 3V3 and 5V can be tested as the HV to confirm they will continue working.

For how it works I’ve included my text from my DIY level shifting entry below.

I believe this works by (my understanding came from this great reddit answer):

• When the LV side is LOW it causes a Vgs of 3V3 which is more than the 1V5 needed to fully activate the mosfet. Once activated it causes current to flow and pulls the HV side down as well. When it’s high the Vgs is 0 so current doesn’t conduct and with the pull up resistors both sides are kept at their respected voltage.
• When the HV side is brought LOW it causes the diode to become reverse biased (from what I’ve gathered) which in turn allows the body diode to allow current through it. This in turn causes the source voltage to drop in turn causing the Vgs to climb until the mosfet is fully activated and the LV side is also brought fully to LOW.

With that out of the way let’s look at the schematic. You can see it matches the general form of the above circuit. I’ve added some capacitors, headers for the jumper, and the Grove ports themselves. It’s a fairly simple setup. The jumper is setup as the HV value for each of the signal lines allowing customization for both ports.

The PCB itself has no components on the backside.

Assembly

Generally though the PCB has a silkscreen marking for each component listing the uF or ohms needed so I didn’t refer to the schematic while assembling. You should assemble the board with whatever you’re comfortable with if copying my steps here whether that’s individually soldering the components or using paste and hot air like I did.

Testing

You can refer to the video for more information but I preformed the following two tests prior to using the circuit.

• Continuity testing the various component points (confirming the pins from the Grove connector properly were soldered and checking for shorts)
• Using a test with all 4 signal pins set to HIGH allowing me to use my multimeter to check the voltage levels

Test Code

Initial Test Circuit

void setup() {
  pinMode(D4, OUTPUT);
  pinMode(D5, OUTPUT);
  pinMode(D6, OUTPUT);
  pinMode(D7, OUTPUT);

  digitalWrite(D4, HIGH);
  digitalWrite(D5, HIGH);
  digitalWrite(D6, HIGH);
  digitalWrite(D7, HIGH);
}

void loop() {
}

This circuit is the one I used for testing. The goal here was to simply set each of the various pins to a HIGH state such that I could test them once shifter.

Water Atomization Circuit

Additional Project items (affiliate links):

• Grove Water Atomization 1.0

Code:

void setup() {
  pinMode(D7, OUTPUT);
  digitalWrite(D7, HIGH);
}

void loop() {
}

For this example I simply set the RX pin (D7) to HIGH such that the enable pin is activated and the logic can run. There’s nothing special about this set of code it just keeps the EN pin HIGH allowing it to function. When Grove modules only use with pin they use the outer pin and have the inner signal pin set to a not connected (NC) state.

i2c Test Circuit

The i2c test circuit used here is a built in example for SSCMA for inferencing over i2c.

Additional Project items (affiliate links):

• Grove Vision AI V2 Module

Code:

#include <Seeed_Arduino_SSCMA.h>

SSCMA AI;

void setup()
{
    AI.begin();
    Serial.begin(9600);
}

void loop()
{
    if (!AI.invoke())
    {
        Serial.println("invoke success");
        Serial.print("perf: prepocess=");
        Serial.print(AI.perf().prepocess);
        Serial.print(", inference=");
        Serial.print(AI.perf().inference);
        Serial.print(", postpocess=");
        Serial.println(AI.perf().postprocess);

        for (int i = 0; i < AI.boxes().size(); i++)
        {
            Serial.print("Box[");
            Serial.print(i);
            Serial.print("] target=");
            Serial.print(AI.boxes()[i].target);
            Serial.print(", score=");
            Serial.print(AI.boxes()[i].score);
            Serial.print(", x=");
            Serial.print(AI.boxes()[i].x);
            Serial.print(", y=");
            Serial.print(AI.boxes()[i].y);
            Serial.print(", w=");
            Serial.print(AI.boxes()[i].w);
            Serial.print(", h=");
            Serial.println(AI.boxes()[i].h);
        }
        for (int i = 0; i < AI.classes().size(); i++)
        {
            Serial.print("Class[");
            Serial.print(i);
            Serial.print("] target=");
            Serial.print(AI.classes()[i].target);
            Serial.print(", score=");
            Serial.println(AI.classes()[i].score);
        }
        for (int i = 0; i < AI.points().size(); i++)
        {
            Serial.print("Point[");
            Serial.print(i);
            Serial.print("]: target=");
            Serial.print(AI.points()[i].target);
            Serial.print(", score=");
            Serial.print(AI.points()[i].score);
            Serial.print(", x=");
            Serial.print(AI.points()[i].x);
            Serial.print(", y=");
            Serial.println(AI.points()[i].y);
        }
        for (int i = 0; i < AI.keypoints().size(); i++)
        {
            Serial.print("keypoint[");
            Serial.print(i);
            Serial.print("] target=");
            Serial.print(AI.keypoints()[i].box.target);
            Serial.print(", score=");
            Serial.print(AI.keypoints()[i].box.score);
            Serial.print(", box:[x=");
            Serial.print(AI.keypoints()[i].box.x);
            Serial.print(", y=");
            Serial.print(AI.keypoints()[i].box.y);
            Serial.print(", w=");
            Serial.print(AI.keypoints()[i].box.w);
            Serial.print(", h=");
            Serial.print(AI.keypoints()[i].box.h);
            Serial.print("], points:[");
            for (int j = 0; j < AI.keypoints()[i].points.size(); j++)
            {
                Serial.print("[");
                Serial.print(AI.keypoints()[i].points[j].x);
                Serial.print(",");
                Serial.print(AI.keypoints()[i].points[j].y);
                Serial.print("],");
            }
            Serial.println("]");
        }
    }
}

I didn’t change anything with this circuit just reused the existing one to demonstrate the level shifting here.

Serial Test Circuit

For this example project I setup a serial test circuit by utilizing an Arduino Uno, Base Shield V2, a Grove Buzzer, a Grove buzzer, and my Level Up board.

Given the Uno board only allows for one serial connection I opted for Software Serial utilizing the NeoSWSerial library with a slower baud rate.

When the button on the Xiao side (with my level up board) is pressed it sends a message across the serial connection. On the Uno side the logic listens for commands and when it receives the associated message it triggers the buzzer.

Additional Project items (affiliate links):

• Grove Button
• Grove Buzzer
• Grove Base Shield V2
• Arduino Uno Rev3 - although I suggest the Uno Rev4 board

Arduino Uno

#include <NeoSWSerial.h>

// Define the software serial pins
const int rxPin = 6; // RX pin
const int txPin = 5; // TX pin

NeoSWSerial mySerial(rxPin, txPin);

const int buzzerPin = A0;
const String triggerMessage = "BUZZER_ON";

void setup() {
  pinMode(buzzerPin, OUTPUT);
  digitalWrite(buzzerPin, LOW); 

  mySerial.begin(9600);
}

void loop() {
  if (mySerial.available() > 0) {
    
    String message = mySerial.readStringUntil('\n');
    message.trim();
    if (message == triggerMessage) {
      digitalWrite(buzzerPin, HIGH);
      delay(1000);
      digitalWrite(buzzerPin, LOW);
    }
  }
}

The Uno logic here is fairly simple it sets up the buzzer as an output on the A0 pin (the same pin that has the buzzer connected over a Grove cable), it sets up a serial connection using the pins D5 and D6, and then during the loop it looks for newlines indicating a received message, compares it to the trigger for the buzzer, and if found turns it on for a second.

Xiao ESP32S3

const int buttonPin = D5;
const String triggerMessage = "BUZZER_ON";
bool buttonState = LOW;
bool lastButtonState = LOW;
HardwareSerial SerialOut(0);

void setup() {
  pinMode(buttonPin, INPUT);
  SerialOut.begin(9600, SERIAL_8N1, -1, -1);
}

void loop() {
  buttonState = digitalRead(buttonPin);

  if (buttonState == HIGH && lastButtonState == LOW) {
    SerialOut.println(triggerMessage);
  }

  lastButtonState = buttonState;
  delay(50);
}

On the Xiao side the code is fairly simple. It sets up D5 as a button (here I’m using the i2c pins for the button), it then starts a hardware serial connection using the lower baud rate we set for the Uno, and it then just listens for button events and triggers the message based on that.

Closing Thoughts

This board works great for its intended purpose. It wasn’t hard to put together as it uses just a few components, its compact so it can be used with various projects, and it level shifts well.

I’ll be using the Seeed Grove Vision AI Module V2 for more projects in the future so this board will come in handy for those. I have a few more projects on the way in the future so will have more articles once those are ready!

The associated code for this project can be found here.

Prerequisites

For more information about the robot car kit you can check my article on the lessons from the Adeept tutorials with the car.

Background

There’s an ongoing contest from DFRobot around utilizing the Unihiker for various project types. I have a Unihiker and have used it for multiple (1, 2) projects previously. The Unihiker device is fairly easy to work with: there are various example projects, the pingpong libraries makes interfacing with various sensors a simple task, and it has a large screen and touchscreen.

Setup

Banana Pi PicoW S3 CircuitPython

The first step is to get your Banana Pi PicoW S3 setup to have the CircuitPython code. The majority of the libraries used for this project come as part of the omnidirectional car kit’s logic but a CircuitPython bundled library is needed as well.

If you reference the code only the code.py file from the repository will be used for car. Depending upon the version of CircuitPython you used you may need either the 8.x or 9.x bundle. I used the 9.x bundle as I flashed that version of CircuitPython to the board.

• Copy adafruit_ht16k33 to the drive’s lib folder
• From Adeept’s code bundle for the car copy over the avoid_obstacles.py and BPI_PicoW_S3_Car.py. I placed them at the root folder of the project
• Finally copy the code.py from the repository above to the drive

With those in place the setup process for the car is complete and we can move onto the Unihiker setup.

Code Breakdown

I’m going to go into the code I added / adjusted here. So I took the original car control logic and modified it for commands I wanted to handle. I won’t go into every part so you should reference the code in the repository for actually copying it over but this may prove helpful if you want to understand the different elements of it.

# Connect WIFI
ssid, pw = ('BPI-PicoW-S3', '12345678')

wifi.radio.start_ap(ssid=ssid, password=pw)
time.sleep(1)
print(f'WiFi AP mode Started! SSID is {ssid}, IP={wifi.radio.ipv4_address_ap}')

So this logic sets up an access point. This access point can be connected to from the Unihiker to then control the car. Having it act as an access point (vs connecting to an existing network) allows one to take the car anywhere. I found the car to use the address 192.168.4.1 for the access point it created (I used CircuitPython serial to read the output).

servo = Servo()
servo.set_angle(board.GP7,0)

I noticed during initialization for the servo head moves which can cause it to not point forward when the car begins movement. In order to address this I set the angle of the servo to 0 after initialization. In this way when the obstacle avoidance logic is running the car is always reading the forward direction. You’ll notice this is using the pinout from the motor shield / banana pi PicoW S3 as it’s using CircuitPython. If you were using arduino you’d need to use the ESP32S3 related GPIO numbers but in this case it’s straightforward given that mapping.

with pool.socket(pool.AF_INET, pool.SOCK_STREAM) as server_socket:
    server_socket.bind(('0.0.0.0', 8080))
    server_socket.listen(5)

    while True:
        server_socket.settimeout(0.1)
        try:
            connection, address = server_socket.accept()
            print("Connected by", address)
            connections.append(connection)
        except OSError:
            pass

The logic then creates a socket and once connected proceeds.

for connection in list(connections):
  buf = bytearray(BUFF_SIZE)
  try:
      size = connection.recv_into(buf)
  except OSError as e:
      if e.errno == errno.EAGAIN:
          continue
      else:
          raise

  if not size:
      connection.close()
      connections.remove(connection)
      break

  data = buf[:size].decode()
  print("Received data:", repr(data))

Then for each connection it confirms if the connection has been closed and if so removes it else it decodes and processes the data.

Given the data in this case is just a command the logic is pretty simple from here out.

if data == "obstacle_avoidance":
  try:
      avoid_obstacles_mark = 0
      while True:
          avoid_obstacles.test()

          buf = bytearray(BUFF_SIZE)
          try:
              size = connection.recv_into(buf)
          except OSError as e:
              if e.errno == errno.EAGAIN:
                  continue
              else:
                  raise

          if not size:
              break

          data = buf[:size].decode()
          print("Received data:", repr(data))
  except KeyboardInterrupt:
      motor.motor_stop()
else:

I persisted the existing obstacle avoidance code here. It triggers the logic in that associated library provided by Adeept which prevents the car from running into obstacles by using its sensor to detect range.

  direction_commands = [
      "forward",
      "backward",
      "left",
      "right",
      "left_backward",
      "right_forward",
      "right_backward",
      "left_forward",
      "turn_left",
      "turn_right"
  ]

  if data in direction_commands:
      motor.move(1, data, speed)
      if "turn_" in data:
          time.sleep(0.5)
          motor.motor_stop()

      lcd_print = data.replace("_", " ")
  else:
      lcd_print = "stop"
      motor.motor_stop()

if info != lcd_print:
  lcd_putstr = LCD1602()
  lcd_putstr.lcd.clear()
  lcd_putstr.lcd.print(lcd_print)
  info = lcd_print
  lcd_putstr.lcd.close()

In the original code for the WiFi control the logic did not support all directions and was geared towards the associated app. I adjusted these to remove the newline and added support for each of the directions. In the event it’s a turn the logic automatically stops the motors after half a second. I did this to help prevent the car from turning too heavily prior to a user pressing stop. I would have preferred having the Unihiker buttons act on touch but I didn’t see touch events just click in the API documentation so opted for this which works well.

That’s about it for the car – most of the primary logic here is handled by Adeept’s libraries so it’s just a matter of starting the access point, listening for connections and creating a socket, and then just processing the commands.

Unihiker Setup

For the Unihiker the setup is also fairly straightforward. First you’ll want to connect your Unihiker over SSH I found Visual Studio code to be a great IDE for this as they mention in their documentation.

With that setup you should be able to see the associated folders, are able to drag and drop code to the device, and can use the terminal via the connection.

Connecting to the Access Point

The first step you’ll want to take is to connect to the associated access point. To do such you’ll want to hit the address http://10.1.2.3 and go to the “Network Settings” tab.

Here you’ll see the following screen:

It took me a few times (both scanning and then connecting) before I saw the Access Point in the list. Once I did connect though I’ve never had to return to this page. As soon as the Banana Pi PicoW S3 is on the Unihiker attempts to connect and make a socket connection which in turn just works every time.

The values seen in this screenshot represent the ones we setup in the code prior. If you changed the WiFi SSID or password there you’ll need to use those here as one would expect.

Getting the Remote Ready

The next step is to upload the images and code. With the SSH connection to the Unihiker ready you need only drag and drop the associated images folder from the code repository to get them on the device. These images include ones for each button, a background with the title, and a splash screen.

Like the images the unihiker_remote.py can be dragged over. Once on the device you can get to the code (assuming it was placed in the root) by long pressing the side button to open the menu, selecting “2 - Run Programs”, selecting the “root” folder, and then selecting the program from within there.

Code Breakdown

The code for the Unihiker here isn’t too complex. Like earlier I’ll go into some detail about various elements but the code itself should be referenced for use on the device.

server_ip = '192.168.4.1'
server_port = 8080

As mentioned earlier the access point’s address for me was this one so I setup the Unihiker remote to connect to this address.

def send_command(s, command):
    try:
        s.sendall(command.encode())
        print(f"Sent: {command.strip()}")
    except (BrokenPipeError, ConnectionResetError, OSError):
        print("Connection lost. Reconnecting...")
        s.close()
        s = connect_to_server()
        s.sendall(command.encode())
    return s

I setup a send_command method to send commands to the device.

def connect_to_server():
    while True:
        try:
            s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
            s.connect((server_ip, server_port))
            print("Connected to server")
            return s
        except (ConnectionRefusedError, OSError) as e:
            if isinstance(e, OSError) and e.errno == 101:
                print("Network is unreachable. Retrying in 5 seconds...")
            else:
                print("Connection failed. Retrying in 5 seconds...")
            s.close()
            time.sleep(5)

Likewise I setup a method called connect_to_server that attempts to connect to the server but in the event of failure it retries 5 seconds later.

def initialize_gui():
    gui = GUI()
    gui.draw_image(x=0, y=0, w=320, h=320, image="images/remote.png")
    return gui

I’ve encapsulated some logic here to initialize the GUI setting up the initial splash image and returning the GUI object.

def draw_buttons(gui):
    commands = {
        'turn_left': 'images/arrows-turn-left.png',
        'turn_right': 'images/arrows-turn-right.png',
        'left_forward': 'images/arrows-top-left.png',
        'forward': 'images/arrows-top.png',
        'right_forward': 'images/arrows-top-right.png',
        'left': 'images/arrows-left.png',
        'stop': 'images/stop.png',
        'right': 'images/arrows-right.png',
        'left_backward': 'images/arrows-bottom-left.png',
        'backward': 'images/arrows-bottom.png',
        'right_backward': 'images/arrows-bottom-right.png',
        'obstacle_avoidance': 'images/obstacle-avoid.png'
    }

    button_positions = [
        ('turn_left', 30, 80), ('obstacle_avoidance', 90, 80), ('turn_right', 150, 80),
        ('left_forward', 30, 140), ('forward', 90, 140), ('right_forward', 150, 140),
        ('left', 30, 200), ('stop', 90, 200), ('right', 150, 200),
        ('left_backward', 30, 260), ('backward', 90, 260), ('right_backward', 150, 260)
    ]

    for command, x, y in button_positions:
        gui.draw_image(x=x, y=y, w=60, h=60, image=commands[command], onclick=lambda cmd=command: button_click(cmd))

I’ve setup these two mappings. In retrospect I suppose I could have just put the images in the tuple for the button positions but I didn’t at the time. The logic loops over the button positions, uses the draw_image method on the gui to then draw them to the page. It uses the commands mapping to figure out the correct image to use. You can see in the onclick lambda it sets the variable cmd to the value of command which it then in the lambda uses.

def button_click(command):
    global connection_socket
    connection_socket = send_command(connection_socket, command)

When the button is clicked it then runs this code sending that command to the socket.

Board("UNIHIKER").begin()
gui = initialize_gui()

connection_socket = connect_to_server()

gui.draw_image(x=0, y=0, w=320, h=320, image="images/background.png")
draw_buttons(gui)

while True:
    time.sleep(1)

The main logic is seen here – it initializes the Unihiker board, the GUI (and splash as mentioned above), attempts to connect to server, once that completes it adds the background, and then draws the buttons. Given the rest of the logic is handled in callbacks the loop logic simply sleeps each iteration to keep the program alive.

Next Steps?

I could imagine further augmenting this control to display sensor data and display it on the remote as you control it. It would also be really cool to use an onboard Xiao ESP32S3 Sense to get a low resolution image to display to allow for remote control.

Image Creation Process

To help aid me with the remote control design I utilized ChatGTP’s image generation features. The nice thing about relying on a tool like this is that it can create lots of content with a similar theme allowing your images to work well together as you design an interface.

To generate the images I started with a simple prompt:

I’m designing a gamepad and need a bunch of arrow buttons to see which I’d prefer – give up and up right for each design and make sure the design can be flipped or rotated without issue for those two (omnidirectional)

This led to it responding with ASCII art so I responded:

Image generation

Which started generating images.

I’ve included screenshots of the exchange here as a gallery.

After this I took the images, cut out the components and exported them for as individual images. For the arrows I flipped them around as needed horizontally and vertically to have one for each direction. I also turned them 45 degrees such that they pointed toward each corner and side.

After exporting them I took the images and used them for the project.

I didn’t want to have to work at my machine learning machine though as it’s not the more comfortable positioning for long sessions so I opted to setup SSH tunneling for the notebook. This is a quick guide for that process on the AMD ROCM stack.

The first step is to get the W7900 configured with ROCM and the associated libraries. For this machine I set things up with Ubuntu 22.04 LTS, configured SSH via key, and had went through the setup process for ROCM on linux and the associated post installation instructions.

For TensorFlow itself I opted for an older version. I have been using EfficientNetV0 and its more complicated / larger versions as part of my model shrinking and have run into issues with newer versions around saving related to this bug.

In my case I first created a conda environment for machine-learning. I suppose I could have just installed the dependencies with pip but I’ve found conda to be helpful in terms of isolating my environments for various machine learning needs. It’s also nice to be able to start over more easily if the environment gets into a bad state.

wget https://repo.anaconda.com/miniconda/Miniconda3-py38_23.3.1-0-Linux-x86_64.sh
sha256sum Miniconda3-py38_23.3.1-0-Linux-x86_64.sh

After confirming the sha256 signature, install:

bash Miniconda3-py38_23.3.1-0-Linux-x86_64.sh

I then installed TensorFlow and several other dependencies (note I’m using 2.9.2 per that above issue):

conda create -n machine-learning
activate machine-learning
conda install pandas scikit-learn notebook matplotlib
pip install tensorflow-rocm==2.9.2

Next I start a new SSH session with a tunnel setup for port 8888:

ssh -L 8888:localhost:8888 user@192.168.1.100

As long as that SSH session is left open I can use the associated notebook URL as if it were running on my laptop.

As such on subsequent SSH sessions I can run:

conda activate machine-learning
jupyter notebook --no-browser --port=8888 --NotebookApp.allow_origin='https://colab.research.google.com'

Next you’ll want to take the generated URL, such as the example below, and enter it into the local runtime selection inside of Google colab.

http://localhost:8888/tree?token=94cb1ff48933128cf12ac7fb4745edb26a39c6798fdb923f

With that setup you can now use your machine to setup the notebook and begin running machine learning experiments on it.

You’ll know it’s working if the logs are spammed with the message:

2024-07-07 08:49:17.214980: I tensorflow/core/common_runtime/gpu_fusion_pass.cc:507] ROCm Fusion is enabled.

I did notice one negative of this approach is that my laptop becomes a bit slower in terms of network traffic while this is ongoing. I think given this a hybrid setup works well where I use the SSH tunnel to configure the project, confirm I have the general model setup correct, and then switch over to the machine itself to run the notebook for the training aspect one I can set it and leave it alone for a long period.

Steps to Create

Image Aqusition, Cleanup, and SVG Preparation

In the case of animal prints government websites are often a great source of information as there are several that compile track data for use of residents. Massachusetts, for example, provides an animal tracks information page. This was the one I primarily used for the project. For the below example and in my video I used one from Kentuky.

Taking a single track (the Elk) from the field guide:

After cleaning in GIMP (a free image editor) removing the marks outside of the track:

With the cleaned up image we can take it to EZGif’s PNG to SVG tool to convert it:

After selecting options to better convert it:

After downloading the SVG we’ll switch to Fusion 360.

Fusion 360

With Fusion 360 there is a personal edition which gives you a chance to learn the tooling if the following applies to you:

Autodesk Fusion for personal use is a limited, free version that includes basic functionality for qualifying users who generate less than $1,000 USD in annual revenue and use for home-based, non-commercial projects only.

For this part of the project we’ll utilize the fusion 360 tooling to imprint the animal track into the 3D model and also to emboss text into the tag.

For the purposes of this guide the starting point is the blank animal tag:

Once inside of the tool, in the Solid menu there’s the option to create a sketch. Once in the sketch view you can select the surface of the print and add sketch related elements.

From the insert menu there’s the option to “Insert SVG”:

With the SVG inserted you can scale and position it as needed until it’s in the proper location for extrusion. Once there click the button to finish the sketch you can then select the surfaces to extrude.

With a suitable distance set for extrusion you can cut into the surface:

The next step, if trying to emulate my design, is to create a sketch again and use the create text option to type out additional information for printing:

For my own settings I used a 0.75mm extrusion for the text:

Finally with Fusion 360 you’ll need to export the model for printing:

Prusaslicer

With the model exported for printing it can imported into Prusaslicer for printing (or any other similar software).

If you want a similar effect with the color change I did you can add a color change to the print. With my i3 MK3S the firmware pauses at this point and begins beeping alerting me to perform the change.

Once that is complete you can print the model. I think they turned out well.

Closing Thoughts

This approach works well for black and white images. I think having 3D printed objects also helps people visualize how the tracks look and it gives a great way to compare while out in the wild.

Model Setup

The first step is to get your vision AI sensor configured for the model. After some testing I found the Swift YOLO model effective for person detection.

The process to get setup is fairly straightforward:

• Using Chrome or Microsoft Edge Visit the SenseCraft Web Toolkit
• Connect to your device via the “Connect” button
• A web serial popup will appear allowing you to connect to your device
• Select a model from the available and send to the device

In the case of a self trained model there are additional steps required as you need to train it using the SSCMA library and associated notebooks (at the time of this writing). For this project though we’re using a built in model so with this step we’re done.

Telegram Setup

For the telegram setup you can refer to the Seeed Wiki article on the topic. I’ll go over the general steps here.

• Contact the BotFather sending the message /newbot to initiate the bot creation process
• Respond to the messages from the BotFather giving your bot a name and username
• After this the bot will respond with a token you can use for interfacing with the API
• Adding this bot to a group will associate a chat id with your user and the bot (until this step is taken the response will not contain a chat id)
• Hitting the endpoint https://api.telegram.org/bot{Token}/getUpdates after replacing the {Token} with your token will return a payload that includes your chat id
• After you’ve received this chat id you can subsequently send messages to the bot via the /sendMessage endpoint

With cURL you can send a message directly to the bot via:

curl https://api.telegram.org/bot{Token}/sendMessage -H 'Content-Type: application/json' -X POST --data '{"chat_id": 7216726720, "text":"Test Message"}'

Components / Circuit Setup

I’ve used the following components with this setup (affiliate links):

• DIY Level Shifter
• Grove Vision AI V2 Sensor
• Xiao ESP32C
• FOV Camera for RP
• 90 Degree USB Connector
• Enclosure
• Grove Shield for Xiao
• Grove LED Bar
• Solar Panel
• Buzzer
• Lipo Rider Pro

It’s a mostly no solder setup (aside from the DIY Level Shifter). I’ll walk through the connections here to help make the setup easier to follow. I suggest VHB tape from 3M for mounting as it holds well.

• First take the Lipo Rider Pro and position it such that there’s enough room for the 90 degree connector, connect the 90 degree connector
• Attach the solar panel via its connector
• Attach a lithium ion battery to its connector
• Attach the Xiao ESP32C3 to the Grove Shield and break off the extra HY 2.0 4P connectors (for this enclosure I could not fit the full shield)
• With the Xiao ESP32C3 now connected attach it to the 90 degree connector via the USB-C connection
• Connect the buzzer to the A1 A0 grove connector via a Grove cable (A1 is not used in this case as the Buzzer only uses the 4th pin)
• Connect the LED bar to the A2 A1 grove connector via a Grove cable (both pins are used here)
• You will need to level shift for the Grove Vision AI V2 (it seems to work with 3V3 but the wiki states it only takes 5V so likely not a good idea – the Grove connection leads to a 3V3 regulator and expects 5V from the schematic)
• For the level shifting connect SDA and SCL to the LV#s side of a level shifter, connect the LV to 3V3, GND to GND. On the HV side connect the HV to the 5V / VBUS from the Grove Shield extra pins, then connect the corresponding SDA and SCL wires leading to the Grove Vision AI V2 along with the GND wire. To make this process simpler I setup a DIY inline level shifter circuit I described in another article. I also designed a Xiao Level Shifting base board that’s on the way – hoping it simplifies future projects.
• With the connections in place use the VHB tape to prevent movement in the enclosure for most of the parts and electrical tape to hold the LED bar, solar panel, and camera to the roof.

So yeah it sounds mighty complicated but it really isn’t it’s just of Grove cables connecting various sensors to the device. I really don’t like soldering components in general (outside of individual pieces) as it limits future project reuse so I love situations like this where you can rely on the existing expansion boards to piece together a full device.

Given this project is relying on the Grove cables I’m not going to include a Fritzing image of the circuit. The level shifter circuit used is included in my other article which delves into how it works and provides a link to Falstad’s circuit tester where you can try it in action (really appreciate that site).

Code

For the code you’ll first want to setup Arduino for use with the Espressif boards. To do this you’ll need to:

• Press File from the menu bar and press Preferences from the list
• Near the bottom of the screen you’ll see an area for additional board management URLs to be added. Here you’ll want to add https://espressif.github.io/arduino-esp32/package_esp32_index.json to the comma separated list (it may be blank if this is the first non-Arduino board you’re configuring)
• After installing go to the boards submenu from the left-hand side bar selection menu
• Type in “Espressif” in the search bar
• You’ll see a esp32 board option, install this to setup the associated esp-tool tooling and related boards
• In the code screen pull down the board select and type in “Xiao ESP32C3” it should return the associated board
• For the libraries you’ll need to add the 1.0.1 version of the LED Bar from GitHub as it hasn’t been published at this time
• In addition the SSCMA library should be installed

The entire code for this example can be found with my gist. I’ll go over some of the associated code but it’s pretty simple.

// Threshold for detection
const int threshold = 70;
const int dataPin = D2;
const int clockPin = D1;
const int buzzerPin = D0;

Here I configured the associated pins for the LED bar, the buzzer’s pin, and the threshold needed to trigger the telegram alert.

SSCMA AI;
Grove_LED_Bar bar(dataPin, clockPin, 0, LED_BAR_10);

Creating the associated objects for interfacing and controlling the LED bar.

void setup() {
    AI.begin();
    Serial.begin(9600);
    WiFi.begin(ssid, password); 
    while (WiFi.status() != WL_CONNECTED) {
      delay(1000);
      Serial.println("Connecting to WiFi...");
    }
    Serial.println("Connected");

    bar.begin();
    pinMode(buzzerPin, OUTPUT);  // Buzzer on D0
}

The setup logic connects to the WiFi, retries until it connects, and then associates the buzzer pin as an output.

Each iteration of the loop it resets the count of people detected and the highest confidence found.

After that:

  if (!AI.invoke()) {
    for (int i = 0; i < AI.boxes().size(); i++) {
        if (AI.boxes()[i].score > threshold) {
            peopleDetected++;
            if (AI.boxes()[i].score > highestConfidence) {
                highestConfidence = AI.boxes()[i].score;
            }
        }
    }

It invokes the model and if that was successful then it loops over the boxes returned counting those that had a score higher than the threshold set and also what the highest confidence seen was.

    // Update LED bar
    int ledsToLight = map(highestConfidence, 0, 100, 0, 10);
    bar.setLevel(ledsToLight);

Here it uses this highest confidence to light up the LED bar. As I set the alerting confidence to 70% it will show 7 to 10 (likely never 10 though) lights depending upon the score. One could modify the above loop to move the confidence logic outside of the threshold check to view it from 0 to 10 but for my purposes I only wanted it showing when it alerted.

    if (peopleDetected > 0) {
        Serial.println("People detected");
        if (WiFi.status() == WL_CONNECTED) {
            String message = "People Detected: " + String(peopleDetected) + "\Confidence: " + String(highestConfidence);
            sendMessage(message);
        }

        // Trigger buzzer
        digitalWrite(buzzerPin, HIGH);
        delay(1000);  // Buzzer delay
        digitalWrite(buzzerPin, LOW);
    }

If people were detected in this iteration of the loop it then sends a message to telegram to trigger the alert.

void sendMessage(String text) {
  String url = "https://api.telegram.org/bot" + botToken + "/sendMessage";
  String payload = "{\"chat_id\":\"" + chatId + "\",\"text\":\"" + text + "\"}";
  
  HTTPClient http;
  http.begin(url);
  http.addHeader("Content-Type", "application/json");
  
  int statusCode = http.POST(payload);
  if (statusCode == 200) {
    Serial.println("Message sent successfully!");
  } else {
    Serial.println("Failed to send message.");
  }
  http.end();
}

Here the logic puts everything together from the BotFather. Using the token it provided earlier you can hit the /sendMessage API with the payload containing the chatId and associated text for the message. This sends the message to the end user via that chat.

Final Thoughts

In general I found this approach to work well; the components fit within the case, I’m able to get 5V from the lipo rider pro which I need for the Vision AI V2 sensor, and the telegram approach is effective for community.

You can test the general idea behind the circuit here (falstad). The two circuits shown are identical in that link aside from a change to the input and output to allow for both directions to be tested.

I believe this works by (my understanding came from this great reddit answer):

• When the LV side is LOW it causes a Vgs of 3V3 which is more than the 1V5 needed to fully activate the mosfet. Once activated it causes current to flow and pulls the HV side down as well. When it’s high the Vgs is 0 so current doesn’t conduct and with the pull up resistors both sides are kept at their respected voltage.
• When the HV side is brought LOW it causes the diode to become reverse biased (from what I’ve gathered) which in turn allows the body diode to allow current through it. This in turn causes the source voltage to drop in turn causing the Vgs to climb until the mosfet is fully activated and the LV side is also brought fully to LOW.

Purpose

A level shifter allows your microcontroller which tend to use 3V3 to interface with actuators and sensors that require a higher voltage. Sometimes a sensor may work with the lower voltage but just isn’t as accurate other times it may not run at all at the voltage level if it’s below a certain point. For example the Seeed Water Atomization module operates at 5V putting this module out of reach for most microcontrollers without a level shifter in the mix.

Using a Bidirectional Level Shifter

Bidirectional level shifters are fairly easy to use but quickly make a project a mess given the need for several wires. At their simplest setup you place wires for each signal line you want to shift to a LV# pin on the shifter. Their corresponding HV# pin is then connected to whatever device you wanted to utilize. The LV pin is associated with the lower voltage while the HV pin is associated with the higher voltage. In addition a common ground must be used between the two voltage sources.

Often times MCUs will provide a pin for the VBUS line which comes from the USB. One could use this as the HV side and have the LV side be the 3V3 from the microcontroller to level shift up to that level. If you need a lot of current a separate 5V voltage source would be ideal over using this though as your microcontroller will also require current to operate and USB 2.0 only allows for up to 500mA. USB PD allows for up to 3A@5V so there are a lot more possibilities when you bring something like a CH224K from WCH into the mix to negotiate for USB PD.

Grove Level Shifting Board

For this project I put together a little Grove level shifting board that allows for no solder level shifting. It’s just a circuit that uses the Adafruit Bidirectional Level shifter, 2 HY 2.0 4P connectors, a pin for the HV level, and then some wires to get it all in place.

For this setup it’s really basic you just want to make sure that you have the HY 2.0 4P connectors setup to the correct LV# and HV# pins on each side. The rest is really just routing the wires correctly per the above.

The end result is you can connect a Grove cable on one end with 3V3 and 3V3 signals and on the other end get 5V and 5V signals out another Grove cable with the help of one dupont cable to the 5V HV. This in turn ends up giving you a much smaller setup in terms of cables for shifting.

Testing Code Used in the Video

// Initialize the Grove LED Button (D6, D7 signals)
const int ledPin = D7;
const int buttonPin = D6;
// Atomization module is on D0
const int enablePin = D0;

// Initial state in the off position
bool enabled = false;
bool buttonState = false;
bool lastButtonState = false;

void setup() {
  // The three pins are setup with the button as an input and others as output
  pinMode(ledPin, OUTPUT);
  pinMode(enablePin, OUTPUT);
  pinMode(buttonPin, INPUT);
  
  // LED and atomization enable are pulled low to set initial state
  digitalWrite(ledPin, LOW);
  digitalWrite(enablePin, LOW);
}

void loop() {
  // Check if button has been driven low
  buttonState = digitalRead(buttonPin) == LOW;
  
  // If the button has changed its state
  if (buttonState && !lastButtonState) {
    // Toggle 
    enabled = !enabled;
    
    digitalWrite(ledPin, enabled ? HIGH : LOW);
    digitalWrite(enablePin, enabled ? HIGH : LOW);
  }
  
  lastButtonState = buttonState;
  
  delay(50);
}

My Level Up Xiao Board

My little level up Xiao board is coming soon!

I’ve ordered it from PCBWay (thanks Serene!) and it should be coming in the next week or so for testing.

I’ll go into more detail once the board arrives but I wanted to take the elements of the level shifter and make it a permanent feature of my helper board.

I’m a big fan of Seeed Studio Grove Base for XIAO (affiliate link). The board makes it very easy to get up and running with a project with little to no soldering. It has pins for an extra row of the main headers allowing for dupont wires to connect to any of those, comes with a battery bonding pad and charging circuit allowing for use with the Xiao without onboard battery ICs (RP2040 and SAMD21), and has an optional flash bonding pad allowing for expandability. In addition to those features it has a tons of HY 2.0 4P connectors allowing you to connect Grove modules easily. Given that I wanted to create a board that used the elements I relied on the most with it.

For the first iteration of my board I decided:

• Xiao pinout allowing for use with the Seeed’s Xiao line of boards (affiliate link) and Adafruit’s QT Py
• I wanted at least two Grove inputs (HY 2.0 4P) with one as I2C and the other UART
• I wanted the ability to optionally set either to 5V or have it still default to 3V3
• Given the I2C bus is easily expanded with a Grove I2C Hub (affiliate link) I didn’t want to overload the board with I2C ports
• Allow for expandability via the matching pins to the Xiao pinout

Prerequisites

For more information about the robot car kit you can check my article on the lessons from the Adeept tutorials with the car.

Background

For this project I’ve created Arduino libraries to control the car and its features. I did this such that I could use the SSCMA library from Seeed Studio. I contemplated porting it to CircuitPython but in the end decided this would be a good learning opportunity.

Code

The code can be found here. There are three directories that are self contained with the associated Arduino code. I included my test projects along with the final car control logic in that repository.

This code is written in C++ for Arduino. You’ll need the Espressif core board package installed with Arduino. Banana Pi does not include a board specifically for this in the board package so you need to use the “ESP32S3 Dev Module” instead. This also means you’ll need to use the GPIO pins from the ESP32S3 directly versus the silkscreen pinout from the Banana Pi PicoW S3.

For getting Arduino configured you can see the guide from Espressif. The short of it is you need to add the board support package located at https://espressif.github.io/arduino-esp32/package_esp32_index.json and then in the boards tab type “Espressif” to find and install.

For the configuration options in Arduino I relied on the Banana Pi Leaf S3 related documentation which worked in this case as well.

MotorControlTest

Initially I was thinking of using the ultrasonic sensor to detect the range of the person in front of the vehicle to aid with the distance tracking. As such I added support for it in this example but I didn’t end up using it in the final code.

I’ll hit some of the elements here to give some information:

#define SDA_PIN 5
#define SCL_PIN 6
#define NUM_LEDS 4
#define DATA_PIN 38
#define BUZZER_PIN 8

// Define trigger pin as 17 and echo pin as 47
Ultrasonic ultrasonic(17, 47); 
Adafruit_NeoPixel strip = Adafruit_NeoPixel(NUM_LEDS, DATA_PIN, NEO_GRB + NEO_KHZ800);

ServoControl servoControl(14); 
MotorControl motorControl;
I2C_LCD lcd(0x27);

The logic initializes and configures the different elements using their GPIO pins (versus the silkscreen).

void playTone(int pin, int frequency, int duration) {
    int period = 1000000L / frequency;
    int pulse = period / 2;
    for (long i = 0; i < duration * 1000L; i += period) {
        digitalWrite(pin, HIGH);
        delayMicroseconds(pulse);
        digitalWrite(pin, LOW);
        delayMicroseconds(pulse);
    }
}

void playAlertSound() {
    int frequencies[] = {370, 415, 330, 233, 311};
    int durations[] = {50, 50, 50, 50, 300};

    for (int i = 0; i < 5; i++) {
        playTone(BUZZER_PIN, frequencies[i], durations[i]);
    }
    digitalWrite(BUZZER_PIN, LOW);
}

There’s logic which attempts to play a sound on alert here. I tried to make it sound similar to the Metal Gear Solid alert noise but it was hard with a buzzer.

Inside the setup method:

    delay(5000);
    Serial.begin(9600);

    pinMode(BUZZER_PIN, OUTPUT);

    strip.begin();
    strip.show();
    for (int i = 0; i < NUM_LEDS; i++) {
        strip.setPixelColor(i, strip.Color(255, 0, 0));
    }
    strip.show();

    Wire.begin(SDA_PIN, SCL_PIN);
    lcd.begin(16, 2);

    lcd.setCursor(0, 0);
    lcd.print("Starting...");

    // Testing alert sound
    playAlertSound();

The logic is pretty straightforward first initializing the LED strip to red, it configures i2c, and the LCD with an initial message.

    delay(500);
    // Test servo: sweep from -90 to 90 degrees and back
    for (int angle = -90; angle <= 90; angle += 10) {
        Serial.print("Setting servo to ");
        Serial.print(angle);
        Serial.println(" degrees");
        lcd.setCursor(0, 1);
        lcd.print("Servo: ");
        lcd.print(angle);
        servoControl.setAngle(angle);
        delay(500);
        lcd.clear();
    }
    
    servoControl.setAngle(0);

The servo does a sweep from side. YOu can see it does it in 10 degree increments.

    for (int i = 0; i < NUM_LEDS; i++) {
        strip.setPixelColor(i, strip.Color(0, 255, 0));
    }
    strip.show();

Given the LEDs are RGB this sets them all to green. The array is 0-indexed and as such it updates all four LEDs by looping over them.

    // Test each motor in each direction for one second
    Serial.println("Testing forward");
    lcd.setCursor(0, 1);
    lcd.print("Forward ");
    motorControl.moveCar(MOVE, FORWARD, 50);
    delay(1000);
    motorControl.stopAllMotors();
    lcd.clear();
...

Each of the directions is tested here. It’s useful to compare the direction of the wheels to mecanum car directional graphics while testing.

    for (int i = 0; i < NUM_LEDS; i++) {
        strip.setPixelColor(i, strip.Color(0, 0, 255));
    }
    strip.show();

Finally the color is set to blue.

void loop() {
    // Get distance from ultrasonic sensor
    float distance = ultrasonic.getDistance();
    Serial.print("Distance: ");
    Serial.print(distance);
    Serial.println(" cm");

    // Display distance on LCD
    lcd.setCursor(0, 0);
    lcd.print("Distance: ");
    lcd.print(distance);
    lcd.print(" cm");

    delay(1000);
}

The loop is straightforward and just gets the distance to the item detected by the ultrasonic distance sensor and displays it on the LCD.

The motors code can be inspected to see how all that works. In short it’s using the mcpwm library for controlling the motors here.

VisionSensorTest

The vision sensor test is in this directory. For the most part the initialization is similar to the last test. The big difference is the presence of the SSCMA library for interfacing with the Seeed vision sensor v2 module.

As we’re already using the i2c bus for the LCD we don’t need to configure anything else there. I’m going to focus on the loop in particular for this example.

void loop() {
    static bool personDetected = false;
    static bool alertGiven = false;
    static unsigned long lastDetectionTime = 0;

    if (!Infer.invoke()) {
        if (Infer.boxes().size() > 0) {
            personDetected = true;
            lastDetectionTime = millis();

            if (!alertGiven) {
                // Red when person is detected
                setLEDColor(255, 0, 0); 
                playAlertSound();
                alertGiven = true;
            }

            int personX = Infer.boxes()[0].x;
            int personWidth = Infer.boxes()[0].w;

            lcd.clear();
            lcd.setCursor(0, 0);
            lcd.print("Width: ");
            lcd.print(personWidth);
            lcd.setCursor(0, 1);
            lcd.print("X: ");
            lcd.print(personX);

        } else {
            if (personDetected && (millis() - lastDetectionTime > 10000)) {
                setLEDColor(0, 0, 255); 
                personDetected = false;
                alertGiven = false;
            }
        }
    }
}

The logic is setup to invoke the model. After it invokes it gets back the bounding boxes and takes the first returned result, grabs the x value and the width of the box, and then outputs it on the LCD. If this was a new detection it sets the LEDs red and plays the alert noise. If a face has not been detected for 10 seconds it sets the LEDs to blue and returns back to “scanning mode.”

MotorControl

This is the main project and brings those elements together. I won’t repeat the above here but will go into the control code:

int personX = Infer.boxes()[0].x;
int personWidth = Infer.boxes()[0].w;

bool moveLeft = personX < 80;
bool moveRight = personX > 140;
bool moveForward = personWidth < 45;
bool moveBackward = personWidth > 50;
bool turnLeft = personX < 40;
bool turnRight = personX > 180;

The servo control logic shown in the SSCMA examples was a great starting point to learn how to use the API response here. I did some experiments with my face at various distances to determine the size of the box when I was close and further away. The x value here is located at the center of the bounding box and the w value is the width of the box.

I then used the above variables to control the car’s actual movement based on their state.

if (turnLeft) {
    Serial.println("Turn Left");
    motorControl.moveCar(MOVE, TURN_LEFT, 50);
    delay(100);
    motorControl.stopAllMotors();
    lcd.print("Turn Left");            
} else if (turnRight) {
    Serial.println("Turn right");
    motorControl.moveCar(MOVE, TURN_RIGHT, 50);
    delay(100);
    motorControl.stopAllMotors();
    lcd.print("Turn Right");      

Turning moves fairly quickly (in retrospect perhaps I should have used a smaller value for the speed) which can be a problem when using the face sensing so I opted to only turn for 100ms at a time.

} else if (moveForward) {
    lcd.print("Action: Moving");
    lcd.setCursor(0, 1);
    if (moveLeft) {
        Serial.println("Moving left forward");
        motorControl.moveCar(MOVE, LEFT_FORWARD, 50);
        lcd.print("Left Forward");
    } else if (moveRight) {
        Serial.println("Moving right forward");
        motorControl.moveCar(MOVE, RIGHT_FORWARD, 50);
        lcd.print("Right Forward");
    } else {
        Serial.println("Moving forward");
        motorControl.moveCar(MOVE, FORWARD, 50);
        lcd.print("Forward");
    }

For the forward and backward (not shown here) movement the logic determines if it should also move left or right and if so moves in that direction.

} else if (moveLeft) {
    lcd.print("Action: Moving");
    lcd.setCursor(0, 1);
    Serial.println("Moving left");
    motorControl.moveCar(MOVE, LEFT, 50);
    lcd.print("Left");
} else if (moveRight) {
    lcd.print("Action: Moving");
    lcd.setCursor(0, 1);
    Serial.println("Moving right");
    motorControl.moveCar(MOVE, RIGHT, 50);
    lcd.print("Right");
} else {
    Serial.println("Stopping all motors");
    motorControl.stopAllMotors();
    lcd.print("Action: Stopped");
    lcd.setCursor(0, 1);
}

If there’s no movement forward or backwards it strafes in that direction and if there’s no movement at all it stops the motors.

Summary

It was a fun project to work on that I learned quite a bit with. Up until this moment I haven’t spent much time with robotic programming. I’ll definitely use what I’ve gained here for projects in the future.

The Seeed Vision Sensor V2 has also been great. I’m a fan of how easy it is to program and train models for. I have a couple other projects I’ll be posting in the next few days.