Robot Project 2021 Notes
From HacDC Wiki
Robot Project Notes
See the Codeberg repository for the most up-to-date notes.
Sparkfun Red Hat Co.Lab Robot
(BBC micro:bit + Sparkfun moto:bit)
Sparkfun moto:bit Carrier Board
The moto:bit - micro:bit Carrier Board (Qwiic) uses a Qwiic interface? and offers pins for:
- six 3-pin sensors,
- two 3-pin servo motors
- two 2-pin “big” motors
and an I2C bus (as well as a Qwiic “port” and power switch)
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ micro:bit CONNECTOR BUS ANALOG DIGITAL DIGITAL ONLY | | +-+----+-------+ +------+------+-+ | | | | | | SCL ☐ P0 • • P1 P2 • • P8 P12 • • P14 P15 • • P16 SDA ☐ 3V3 • • 3V3 3V3 • • 3V3 3V3 • • 3V3 VCC • • VCC 3V3 ☐ GND • • GND GND • • GND GND • • GND GND • • GND GND ☐ SENSOR SENSOR SENSOR SERVO I2C BUS BLACK • LEFT RIGHT • RED RED • MOTOR MOTOR • BLACK POWER IN INPUT RANGE VCC: 3 - 11V QWIIC STOP RUN MOTORS MOTORS
Wheel Motor Assembly
- Geez! They weren’t kidding! Getting the front motor mounts over the big motors was a PITA! Ultimately, brute forcing it with my hand rather than pliers proved the most successful.
- The rear motor mounts were only slightly better.
- Mounting the assemblage to the bottom chassis, I was sure I was going to snap something in two or tear out a wire.
- The motor I’ve mounted on the right side has a black wire whose solder point looks suspect…
Line folowing sensors
- The pins should be sticking out on the smooth side of the “bottom” mount.
- By contrast, this slipped together so easily that I worry it might be too loose, though it will undoubtedly tighten up when mounted to the chassis.
- This tutorial seems to be a thinly disguised advertisment for electrical tape…
Chassis
- 10-year-olds my ass. This required a hell of a lot of strength to snap the chassis together without snapping.
- Don’t forget: there are eight snap points: Four at the corners and two above the wheels. I got the outer four, and didn’t notice the wheel ones until after the fact. It took forever to get those to snap into place.
Wiring
- Motor wires may need to be flipped (black to red and vice versa).
- IMPORTANT SAFETY TIP: The instructions fail to mention that the battery pack should be rotated 90 degrees after slipping in the back so that the power cable is coming out the left side behind the wheel – or if the instructions did mention it, that tidbit wasn’t clear to me. After assembling, I found a guide to assembling the chassis without the moto:bit or micro:bit, and it has an entire section specifically devoted to installing the battery pack
- God help you if you ever have to replace the batteries…
Powering on
- Providing power causes the
micro:bit
to boot with an introductory “H…E…L…L…O” and then prompts you to push buttons A and then B.
Uploading code to the micro:bit
- Connecting the micro:bit to desktop or laptop computer via USB provides sufficient power to program it. No need to waste the “eternal life” batteries, while downloading code to the micro:bit. So I would recommend keeping the moto:bit disconnected from the battery pack.
- The short MicroUSB to USB cable works better for me if I disconnect the micro:bit from the moto:bit and flip it upside down, exposing the side with all the writing, the RESET button, and the yellow LED.
- Identify your micro:bit version. There is a bit of contradictory information on the page, but it turns out, my kit contained a micro:bit v 1.5 but there’s a newer v 2.0. Disappointing… One would have expected SparkFun to send the latest and greatest.
- REALLY disappointing! The v 2.0 has a built-in microphone and speaker. The v 1.5 does not! That kind of blows my whole reason for playing with this! And it’s out of stock on SparkFun and AdaFruit. I’m back-ordering it on SparkFun.
- Speaking of latest and greatest, just to be sure, I like to know I’m using the most recent version of the firmware.
- After “upgrading” (though I think it already had the latest) my
DETAILS.TXT
contains:
# DAPLink Firmware - see https://mbed.com/daplink Unique ID: 9901000052374e450046100f000000100000000097969901 HIC ID: 97969901 Auto Reset: 1 Automation allowed: 0 Overflow detection: 0 Daplink Mode: Interface Interface Version: 0249 Bootloader Version: 0243 Git SHA: 9c5fd81e6545d00b7f7c21ca9d8577dbd6a5fed2 Local Mods: 0 USB Interfaces: MSD, CDC, HID, WebUSB Bootloader CRC: 0x32eb3cfd Interface CRC: 0xcdb7b2a3 Remount count: 0 URL: https://microbit.org/device/?id=9901&v=0249
- The device is supposed to pair via the web using Chromium. I’m using “Chromium Version 87.0.4280.141 (Developer Build) built on Debian 10.7, running on Debian bullseye/sid (64-bit)” according to Chromium’s [chrome://settings/help “About” page].
- The WebUSB troubleshooting guide offers the Linux fix to pairing. At the command line:
- ???
- After pairing? Or perhaps uploading? there is a new file out on the micro:bit:
ASSERT.TXT
which contains:
Assert File: ..\..\..\source\daplink\drag-n-drop\file_stream.c Line: 165 Source: Application
- The uploaded .hex file appears in the directory momentarily but then is consumed by the microprocessor and disappears.
- The backslashes seem suspiciously Microsoft and I’m wondering what three levels up from “root” is being represented by
..\..\..\
Disconnect from the web
I want to write Python code, and load it into the beastie without need of a network. I have a computer, I have a USB cable and I have a micro:bit / moto:bit. I should not need the internet in order to make use of that. On Ubuntu 20.04, the following works:
- ???
- The
uflash
is needed to flash the code onto the micro:bit, apparently. - MicroPython on the micro:bit
- a simple moto:bit driver
REPL achieved!
It probably completely messes up the Microsoft MakeCode flow completely, but I now have the MicroPython REPL prompt:
- ???
This appeared to work, in that the cp command flashed the yellow LED and after starting screen
, I could see that typing was causing the yellow LED to flash, but it wasn’t echoing or, for that matter, responding to carefully typed Python statements. In an attempt to correct…
- ???
Was it the fact that I used a freshly downloaded firmware as a result pf switching to firmware-microbit-micropython-dl
or was it the fact that I used uflash
instead of cp ...
that made the whole thing work? Or perhaps that replacing screen
with minicom
…
(By the way, further investigation showed minicom
reporting a baud rate of 115200.)