A Sneak Peak at Berets (Oct 2021)

Hi! My name is Tom Bewley, and today we are talking about the COVID quarantine project that I worked on together with Ricardo Gorinstein. With this project, we are introducing Berets, which are little “carrier boards” designed to rapidly accelerate the development of low-cost, capable, and powerful robotic systems leveraging modern single board computers (SBCs).

I read somewhere online this nice quote that “white space is where unmet and unarticulated needs are uncovered to create innovation opportunities”. I believe our new little Berets indeed address a significant “white space” in the rapidly growing field of robotics, and I hope by the end of this talk you are as excited about their impending availability as we are.

To summarize this project in just a couple of slides, here is a recent-version Raspberry Pi, which has an install base of about 40 million units. These single-board computers, and their several clones, are remarkably fast and inexpensive, and are great for addressing many high-level tasks in complex robotics applications.

The central challenge, though, is that we are always stuck reinventing the wheel on several mundane low-level tasks, such as: - how to do efficient voltage regulation from LiPo batteries to the standard 12V, 5V, and 3.3V that you need to put a robotic system together, as well as several other subproblems, such as: - Incorporating H-bridges to drive brushed DC motors and stepper motors,

- Setting up brushless motor drivers (the tuning of which is a bit more delicate), - Generating PWMs to communicate with servos and ESCs, - Counting clicks from encoders in order to monitor shaft rotations, - Communicating with other sensors and actuators using I2C, SPI, & UART, - Integrating an IMU, magnetometer, barometer, and GPS for situation awareness, etc.

Dealing with all of this extraneous stuff, from scratch, every time you develop a new robotic system can delay project completion, both in the educational and the product development settings, often resulting in opportunities lost.

Our answer to this conundrum is to build the ultimate HAT for the Raspberry Pi, which we call … the Raspberry Beret. This little carrier board has most of the typical functionality that you need for small robotic systems built right in, and additionally has a little “shield”-like expansion area already wired up, so anything that we didn’t specifically include on the Beret that you might also need, you can easily and securely add on yourself.

Here is a map of some of the key functionality included on the Raspberry Beret: - 7 dedicated quadrature encoder counters for monitoring shaft rotations, - 2 flexible H-bridge systems capable of driving several motors and steppers, - all of the voltage regulation circuitry needed to support 2S to 6S LiPos, - standard 3-pin signal headers, for driving up to 10 servos and ESCs,

- a little STM32G4 microcontroller to coordinate everything, - CAN and RS458 transceivers and pinouts for communication to a daisy chain of several remote devices in challenging environments, - a balance connector, and an intuitive state of charge indicator, - a USB connector for programming from your laptop etc. We also wanted to have a substantial degree of platform portability, so if you start a

project on one single board computer, and later decide that you want to upgrade to, say, a cellphone-grade single-board computer, like the RB5 currently available from Qualcomm (and others in the 96 boards CE format), you easily can. Unlike many other developers, we actually aim to be platform agnostic.

We therefore set out to provide a standardized low-level interface to the common sensors, actuators, and power sources in typical robotic systems via a family of carrier boards. We

are thus also introducing today the Black Beret to support the 96boards CE family, such as the Qualcomm RB5. The Black Beret has essentially the same functionality as the Raspberry Beret, thus allowing you to easily port your high-level linux code from one class of single-board computers to another, with minimal changes to the low-level interface to the sensors, actuators, and power sources used, which may be accomplished using Berets.

In total, the Beret family is being designed, initially, as a family of six motor control boards that are compact, powerful, efficient, and easily extended. They can operate either as carrier boards to the popular linux-based single board computers available today, or standalone. Again, their primary functions are to regulate power from 2S to 6S LiPos

standalone. Again, their primary functions are to regulate power from 2S to 6S LiPos (so, up to 28 volts at up to 20 amps), and for feedback control of several motors of a wide variety of possible sizes.

The goal of the project is to simplify and accelerate the development of feedback controls for mechatronic systems. Berets are open design hardware, and are coordinated with open-source software, which readily facilitates people modifying these hardware and software designs to make their own custom controllers for specific applications. Such applications run the gamut, in: - mobile robotics, - industrial automation, - drones,

- precision agriculture, - pharmaceutical and vaccine development, - food preparation, cleaning, etc. Berets thus provide a platform-portable carrier board family that, again, allows you to port your high-level code from one linux-based single board computer system to another as the algorithmic demands in your system increase, such as for vision processing, while keeping the same low-level interface.

Berets can also be used in stand-alone mode, eliminating the linux-based single board computer altogether. Recall that a little STM32G4 microcontroller is included, which is built around an ARM

altogether. Recall that a little STM32G4 microcontroller is included, which is built around an ARM Cortex M4F with several dedicated hardware subsystems. This MCU is quite capable of coordinating many low-level tasks simultaneously in complex robotic systems. Further, working in standalone mode to debug multithreaded code that efficiently controls an entire robotic system directly

using only a small-but-mighty ARM Cortex M class processor running a real-time operating system (RTOS) helps to prepare a system for high volume production at substantially reduced system cost.

The alternative in the product development setting, prototyping new robots using full-featured linux boards with robust fault-tolerant multithreading coding techniques, but then working with a different team, in a different country, speaking a different language, to implement your tuned feedback controllers on low-cost ARM Cortex M class processors, can lead to fragile single-threaded production codes that are essentially impossible to maintain. We’ve been there and done that;

with the Berets, we aspire to significantly improve this prototype-to-production workflow for ourselves, and to enable others to do the same.

The capabilities of the Berets are, again, primarily focused on power regulation and feedback control. They include: - well-filtered switching regulators, generating

feedback control. They include: - well-filtered switching regulators, generating an essentially ripple-free 3.3V at up to 3A, 5V at up to 6A, and an adjustable 3.3 to 12V at up to 6A; - dedicated quadrature encoder counters, for monitoring shaft rotations; - several H-bridges, for driving brushed DC motors and stepper motors; - dedicated PWM generators to control servos and ESCs;

- a full set of attitude sensors (accels, gyros, barometer, and magnetometer); - standardized pinouts for SPI, I2C, and UART, for connecting to a wide range of other sensors, - CAN-FD and full-duplex RS485 transceivers, for long-range comm, and - a small analog subsystem with two 12-bit DACs and two 16-bit ADCs, with both an electronically-adjustable

gain and an electronically-adjustable cut-off frequency of its second-order low-pass filters, to get the most out of the available dynamic range of its analog subsystem.

Also, you can attach little expansion boards, called Beret Shields, on the Arduino-like headers to easily add a variety of extra functionality, like: - brushless DC motor drivers, - additional brushed DC motor drivers, - analog filters with digitally-adjustable poles, zeros, and gain, - OLED displays, - differential GPS units, - additional I2C and UART connectors and buttons, and - breadboards for quickly testing new circuit designs.

There are six variants of Berets currently being developed. I’ve already introduced the the Raspberry Beret, which is a full-featured Raspberry Pi daughterboard, sometimes called a HAT. We also have a reduced version of this board, called the Red Beret, that we

a HAT. We also have a reduced version of this board, called the Red Beret, that we will make available at low cost - it uses the same PCB, just partially populated, which helped us to save both development cost and production cost.

I’ve also already introduced the Black Beret, which fits the Qualcomm RB5 and other boards in the 96boards CE format. We additionally have a version called the White Beret under development, to fit the Beaglebone Black and AI.

We are also making a small wired standalone version called the Green Beret, which is designed to run as a CAN or RS485 slave device. On a factory floor, in a pharmaceutical lab, or on a farm, you’ll probably want to communicate to such slave devices over an environmentally rugged twisted pair using RS485, whereas if you're developing a smart-car type application, where you are worried about noisy voltage fluctuations and strong ground potential differences

(GPDs), you might want to use CAN. Note that the Green Beret is very small, and doesn’t even have any H-bridges on it, so if you need to drive brushed DC motors with a Green Beret, you would need to incorporate them using one or more of our Beret Shields.

Finally, we are also making a small wireless standalone version for mobile applications, called the Blue Beret. This board makes a little extra space, by getting rid of the CAN and RS485 subsystems and rearranging a bit, allowing us to fit in one H-bridge subsystem to drive at least a handful of brushed DC motors without requiring a Beret Shield.

We thus are planning on six distinct boards that have different numbers of motor drivers, encoder counters, and pinouts for servos, ESCs, and wired comm, as required for different applications: - 4 of these boards support CAN and RS485, - 4 of them are “full size” (2 for the Raspberry Pi, 1 for 96boards CE format like the Qualcomm RB5, and 1 for the BeagleBone Altoids-tin form factor), and

- 2 of them are a bit smaller, and designed for standalone applications: 1 is wired (to be driven as a slave device over CAN or RS485), and 1 is wireless (for mobile applications).

Just one slide of background of how we got into this project: We played a key role, working together with Jason Kridner and his team at Beagleboard.org, in developing the Beaglebone Blue. We learned many valuable lessons, the hard way, in that effort, including that: Surface mount JSTs break off a PCB pretty easily; you really need to use pin through hole (PTH) JSTs to reliably connect to other components, in order for your connectors to

survive hundreds or thousands of mating cycles, which are inevitable in the project development setting.

Single Board Computers get faster every year, as the march of progress in electronics, also known as Moore’s Law, is relentless. If you want to build a motor control board that stands the test of time, you really need to decouple the single board computer itself from the board that implements the voltage regulation and motor control functionality.

This is precisely what we are doing with the Beret family of boards.

There is a large range of wireless standards: WiFi, LoRa, SigFox, bluetooth, bluetooth low energy, Zigbee, Z-Wave, sub-1 GHz, LTE-M, and others, and these standards are still evolving quickly. Different applications demand different wireless standards. It is thus essential that the user be allowed to select which wireless standard(s)

standards. It is thus essential that the user be allowed to select which wireless standard(s) they want to implement. So, wireless connectivity, in the setting of general-purpose motor-control boards like the Berets, must really be provided as separate modules, on a shield. Thus, if

the wireless protocol you need isn’t already implemented on the attached motherboard, you can select precisely which standard(s) you want to use, wired up with a fast, dedicated SPI or UART connection directly to the MCU.

2S LiPos are insufficient for many applications of interest; 4S or 6S LiPos, with substantial current-carrying capability, provide for a much larger range of interesting applications.

The IMU needs to have a dedicated SPI connection to the MCU, which should run a real-time operating system, or RTOS, to provide near real-time feedback.

Finally, inexpensive and robust mobile inverted pendulums, or MIPs, in the classroom and remote teaching settings, are very effective in getting students started in embedded control.

We thus developed a kit called eduMIP a few years back, which was a big hit when it was introduced. We're currently working on its successor, dubbed myMiP, that will support

introduced. We're currently working on its successor, dubbed myMiP, that will support the entire Beret family of boards, and will further enable “makers” to 3D print shells that easily slide onto the myMiP frame and attach securely, thus enabling essentially anyone with access to a 3D printer to “bring their 3D prints to life”. myMIP is actually going into production quite soon, so stay tuned for that - we will discuss myMiP further in a separate video.

I'd now like to give a somewhat deeper technical overview of some key features of Berets. For

power input, a standard XT30 connector is incorporated, running at up to 15 amps continuous and 20 amps peak (and, at up to 28V). So, Berets are characterized by some pretty serious power-carrying capabilities. There is a MOSFET that protects the board, which can both shut

power-carrying capabilities. There is a MOSFET that protects the board, which can both shut the LiPo power off, and later turn it back on.

There is a switching regulator to provide Vs1, which is user-selectable somewhere in the range of 3.3 to 12V at up to 6A; Vs1 is used to drive the servos and ESCs.

There is a switching regulator to provide Vmb, which on most Berets is 5V at up to 6A, to drive the attached motherboard, and to drive some of the external peripherals that you might want to hook up.

Finally, there is a switching regulator to provide 3.3V at up to 3A, to drive the several ICs on the Beret, and to drive the rest of the external peripherals that you might want to hook up.

The outputs of all 3 of these switching regulators are well filtered, with very little voltage ripple.

We also have a power op amp that provides an intermediate voltage, Vs2, somewhere between 0 and 3.3V. This device can either source or sync up to 400 mA, and can act as a reference ground for the powerful analog subsystem, which operates between 0 and 3.3V; this op-amp provides a voltage right in the middle, which can thus act as the ground signal for the analog subsystem when operating in a bipolar setting.

The setup I just described is used on the 3 Berets that have 5V motherboards. The Black

Beret drives a motherboard that requires about a 12V input to operate, and communicates to its connected peripherals at only 1.8V. Some extra circuitry is thus needed on this board, to do the appropriate voltage shifting, so it can communicate with the common sensors and peripherals that you might want to hook up, which today normally require either 3.3V or 5V.

Note that we use efficient step-down (buck) converters for voltage regulation, so we need to use at least a 4S LiPo to drive the Black Beret, which connects to a 12V motherboard.

Also, a 96boards CE format board itself generates 5V, from the 12V provided to the motherboard, so we simply pass that 5V bus back up to the Beret over the low-speed header; the Black Beret itself thus does not actually generate 5V.

Note that: - Vin powers the motor drivers directly.

- Vs1 powers the five Servos or ESCs that you hook up to Signal Header B.

- You can power five more Servos or ESCs, on Signal Header A, with either Vs1, or with Vin directly. - There is a 12A shunt connector which allows

Vin directly. - There is a 12A shunt connector which allows you to bring a whole lot of power (up to 28V at up to 12A) out on Signal Header A.

- Vmb powers the attached motherboard, through the motherboard header.

- The 3.3V and 5V busses power the logic circuits on the Beret, the JSTs, and the digital and analog headers. - Finally, all of the digital outputs are

analog headers. - Finally, all of the digital outputs are 3.3V TTL and 5V tolerant, so we can drive and communicate with peripherals that operate natively at either 3.3V or 5V.

The stack up that we converged to is central to the Berets’ broad functionality.

Berets are 8-layer PCBs designed with a very deliberate trade-off: - sufficiently thin copper layer thicknesses are needed to facilitate the fine features required to break out a 0.8mm pitch ball grid array (BGA) while, simultaneously, - sufficiently thick layer thicknesses are needed, in other sections of the board, to handle high current where necessary.

We thus actually use different thicknesses of copper on the 8 different layers of the PCB, based on each layer’s primary functions. In some regions, some layers carrying high current are even stitched together.

For electromagnetic interference (EMI) and signal integrity considerations: - we put power and ground planes next to each high-speed signal trace, - we use curved traces with no sharp corners, - we perform careful impedance matching to prevent signal reflections, and - we use matched trace lengths for high-speed comm and the corresponding clock signals. - Also, signal ground is carefully isolated from the (noisier) power ground.

Looking at the overall layout of the board, we can map the board into quadrants: - The logic, sensor, and expansion quadrant is in the NE.

- The connector quadrant is split between the NW and the SE.

- The power quadrant is in the SW, and - The motor quadrant is just N of the power quadrant.

To see how power is distributed efficiently, note first that all high current traces are short and fat and, as I mentioned previously, in some cases layers even stitched together to carry more current. For example, Vin travels N here on multiple layers, and Vs1 travels E here, again on multiple layers.

The microcontroller used is a 100-pin version of the STM32G4, with 512KB of flash. These

are its specs. This MCU has a several supplemental hardware units, which are very useful in feedback control settings. We use this supplemental functionality on the STM32G4 very thoroughly

control settings. We use this supplemental functionality on the STM32G4 very thoroughly on the Berets… so much so that we actually didn’t have enough extra digital pins on the MCU, after we were done wiring all these modules up, to use as GPIOs to drive random other simple functions on the board. We thus added a GPIO expander to provide 24 more GPIOs to handle various other flags and simple functions.

We also included a 7-channel LED driver for the main LED indicators on the board, in addition to several status LEDs hooked directly to various GPIOs.

Note that dedicated hardware subsystems on the MCU drive most of the several subsystems on the Beret without loading the main ARM core.

To better illustrate this, here is the connectivity chart of the Berets. The MCU is in the middle, and all of these green ovals are the various hardware subsystems that surround the ARM Cortex M4 on the STM32G4. So: - to send out PWMs to drive servos and ESCs, or - to count the transitions of quadrature encoders to track shaft rotations, or - to communicate over SPI or UART or I2C,

etc… all such repetitive tasks are handled by dedicated hardware subsystems on the MCU, leaving the ARM core free to tackle more involved calculations.

Primarily, the ARM core needs to be available to take care of situational awareness, fusing together inputs coming in from the IMU, the magnetometer, and the barometer, together with additional inputs from the wheel encoders, the GPS unit, etc., in order to estimate the evolving dynamics of the system. Since the other more mundane tasks, including the repeated calculation of many of the FIR and IIR filters using ring buffers (as required to evaluate

the feedback itself), are offloaded to dedicated hardware subsystems on the STM32, we have plenty of clock cycles left over to perform this sensor fusion on the ARM core itself.

The low-level software library driving this entire system is designed to be compatible with the Robot Control (RC) library developed previously by James Strawson, a former student in our lab. We worked closely with both Mathworks and National Instruments during this previous work with BeagleBoard.org, and aim to stay consistent with the containerized environments that we used back then, so we can still deploy control codes developed in such advanced graphical

programming environments directly to the Berets.

Of course, we will also have a ROS interface wrapping all of the low-level functions that the Berets can support.

The key idea is that, by handling all of the low-level feedback needs on the MCUs of the Beret, we free up the attached linux-based computer for more complex high-level tasks, like vision based mapping and audio processing.

Berets are very small boards packed with advanced functionality.

Their High Density Integration (HDI) is achieved using a variety of techniques, most notably Via-in-Pad technology. As an example, there is a component that solders to the PCB right

Via-in-Pad technology. As an example, there is a component that solders to the PCB right here; instead of putting the solder pad for this component here, and then routing a little trace out to a via somewhere else on the board (which then takes this signal to a different layer, and routes it to a different component), we instead put the required via directly underneath the solder pad itself. This modern PCB fabrication (fab) technique, when used properly, allows

you to move components into a much denser arrangement, accomplishing much more in a tiny footprint, which can easily be fit into a small robotic system, like a robotic hand.

Further, implementing via-in-pad technology is actually not that expensive at most fab houses, as compared to implementing the older technology of blind and buried vias, as illustrated here.

Blind and buried vias for HDI are expensive, because they require a separate drill step for each layer of the PCB, before it is sandwiched together. Berets thus have no blind or buried vias anywhere; instead, all of the vias on the Berets go all the way through the board, which eliminates some expensive steps in the manufacturing process. Berets still achieve a very dense integration of components in layout, primarily as a result of the effective

use of via-in-pad technology.

In order to detangle traces on this complex 8-layer board, some basic “traffic” rules are employed: some layers, like these, are primarily slated for N-S communication, and others, like these, for E-W communication.

We also removed the unused pads around the vias under the BGA, to open up additional space to snake through traces around the dense array of vias under the BGA.

Here is an example of the length matching that was done on traces corresponding to high-speed signals and their corresponding clock traces, as indicated by the extra squiggles in these purple lines, which results in the lengths of these three traces matching exactly, on each of the three layers that they travel through.

The net result of all of this care is faster and more reliable communication between components.

The advanced eCAD software program that was used, Altium, makes the design of such complex layouts straightforward.

Advanced ICs are implemented in the Berets, across the board. The datasheet that describes them, which I’ll give the link to at the end of this talk, goes a long way towards illustrating the amazing levels of efficiency and advanced functionality that are now possible, in a very small footprint, for many of the subproblems that must be solved when building up small robotic systems. Particularly impressive are the DRV8912-Q1 motor drivers used, from Texas Instruments

(TI), which deserve special mention here. A pair of these DRVs are implemented. Each

of them has 12 half bridges, and each generates up to 4 PWMs. A fast dedicated SPI connection attaches these DRVs to the MCU; the MCU thus simply instructs the DRVs the commanded direction and duty cycle to actuate the motors over SPI, and the DRVs generate the PWMs necessary to make it happen. This setting facilitates, nominally, simultaneous independent bi-directional

control of eight brushed DC motors. There’s quite a bit more that these motor drivers can do, however, as shown on the next slide.

Note that the DRVs operate directly at Vin (up to 28V, at up to 6A per DRV). This power

flows N from the XT30 input and the power MOSFET.

Note also that the voltage on Vin can drop by over 25% as the connected LiPo battery discharges. This is accounted for in software by monitoring the voltage of the LiPo on the

discharges. This is accounted for in software by monitoring the voltage of the LiPo on the Vin bus, and scaling the feedback gains of the brushed DC motors accordingly, to be inversely proportional to this input voltage.

The DRV outputs are wired to JST-ZH connectors, which are shrouded for electrical protection, and are PTH (that is, they go all the way through the board, and are soldered on the opposite side), so they are very durable. (In fact, across the board, all of the connectors illustrated in dark blue are JST-ZH.)

The DRV8912-Q1 can operate in 3 separate modes: The first is independent mode, in which you just hook up one motor to each pair of outputs from the DRV, so you can actually hook up 6 motors per DRV, each operating at 1A. Recall

that you only have 4 independent PWMs per DRV, though, so at any moment you can independently drive only 4 motors. Note, however, that you can change which 4 motors are driven independently (at whatever duty cycle you want) at any moment.

The other 2 motors are called slaves, and can operate in full forward, full reverse, full brake, or full coast, or they can duplicate the PWM frequency and duty cycle of one of the 4 independent motors. This is actually sufficient flexibility in most applications, which usually have some diversity of driving requirements, such that you don't usually need to drive all six motors independently at the same time. So, this setting can often

be put to very good use. But wait! There's more.

In parallel mode, you can gang together various outputs, leveraging the logical connectivity options built in to the DRV itself. We can set this logic, in software, to coordinate some outputs to get an identical PWM signal, accurately synchronized, from a single PWM generator, and then gang these 1A outputs together using external wire harnesses to drive more powerful motors. In the case shown here, we illustrate the driving of one motor

at 4A and one motor at 2A. Other ganging configurations are also possible: one motor at 6A, two motors at 3A each, three motors at 2A each, etc. But wait! There’s more.

If the operating voltage is low enough that it is insufficient to drive two motors in series, because the operating voltage doesn’t overcome the stall torque of two motors in series, then a unique sequential mode is also available, in which: - you can set outputs 3, 6, 9, and 12 as high impedance inputs, shown here in red, while driving the 4 motors indicated here in green for a while, then

- you can permute which 4 outputs you set as high impedance inputs, and drive the 4 motors now indicated in green for a while, then - you can permute again, and drive those 4 motors for a while, etc. Thus, using this mode, you can drive a remarkable 12 motors per DRV, or 24 motors total, at reduced duty cycles, with a single Beret, which is pretty amazing. In assembly-line

sort of configurations, such as robotic machines designed to make hamburgers, where only one cluster of motors needs to operate at a time, this setting can be used especially effectively.

Various combination of these independent, parallel, and sequential modes are also possible.

------------------------ Berets are set up, by default, to drive up to 10 Servos or ESCs of a variety of sizes, up to 3A each (again, assuming some diversity in driving requirements). These connections

are made using Signal Headers with 0.1” male pins providing Signal, Power, and GND, as is standard. Again, on Single Header A, we can select Power between Vs1 or Vin. By

default, of course, the Beret provides PWM signals to these Signal Headers, for driving standard Servos and ESCs.

However, there are several alternative hardware-supported modes that you can select on the digital pins of the Signal Headers: - you can set up 2 additional I2C channels, possibly breaking them out on a Beret Shield if you have a large number of external I2C devices to hook up, or - you can set up a few hardware unidirectional encoder counters on these these signal pins, if you don't have enough encoders elsewhere

on the board. - Or, like all other digital signals broken out on the Berets, you can always simply drive the digital signals as GPIOs, coordinated by the ARM core itself.

Berets are also set up, by default, with 7 quadrature encoder counters, prewired on convenient JST connectors that include Power and GND, where Power is selectable between 3.3V and 5V. Like the PWM generators driving the Signal Headers, the counting associated with the

5V. Like the PWM generators driving the Signal Headers, the counting associated with the encoder connectors is performed on dedicated hardware units on the STM32G4, which do the bulk of the repetitive work in the background without loading the main ARM core.

Again, there are several alternative hardware-supported modes that you can set up on the digital pins of the encoder connectors: - you can set up an additional I2C channel, - you can set up both a UART channel and a low-power UART channel (for instance, to connect to a standard DSM radio receiver), - you can set up PWMs to drive 14 additional Servos and ESCs, etc.

So, again, there is remarkable flexibility of how you can configure the several digital channels made available on the various connectors of a Beret, depending on your specific system requirements.

There's also an analog header that has: - two 12-bit DACs, - the inputs and output of a spare op-amp, ready for the user to wire up, and - two 16-bit ADCs, So, for example, you can easily hook up a Beret to a 2-input, 2-output analog system, and take its full 2 x 2 Bode plot, leveraging the Beret’s flexible built-in analog subsystem.

Additionally, the Beret monitors the individual cell voltages of the LiPo, and integrates an intuitive state-of-charge indicator for the battery. It also monitors and regulates the two adjustable voltages that it generates, Vs1 and Vs2.

Note that we do not regulate LiPo battery charging with the Berets. We made a different design decision here than we did on the Beaglebone Blue. Since we're enabling the use of high power LiPos with the Berets, we recommend the use of an external, high-quality, dedicated LiPo battery charger, available separately. (You need to plug the LiPo into a wall outlet or car battery anyway to recharge, so we figured you might as well also keep the electronics

used to coordinate the charging of the LiPo separate from the robot itself, and use it whenever you are plugging in to an external power source to charge the LiPo.)

Our analog system has a remarkably flexible Sallen-Key second order low-pass filter, with both a software-tunable gain and a software-tunable cut-off frequency, to get the most out of the available dynamic range of its ADC inputs. The components in red are actually included on the STM32G4 itself, and the additional components in black are on the Beret. The

digital potentiometers shown allow you, in software, to adjust both the gain of the filter, between a factor of 1x and 4000x, and the cutoff frequency of the filter, between 34 and 3400 Hz.

For attitude estimation, we have implemented the best-in-class magnetometer, barometer, and IMU available today; their sensitivities, which are pretty remarkable, are shown here.

Note that many such sensors (especially “9 axis” IMUs that integrate an IMU with a magnetometer) are not nearly this accurate… so, buyer beware!

There is also a 32 kHz MEMS oscillator that hooks both to the real-time clock of the STM32 as well as the IMU, which significantly improves timing accuracy.

By default, these on-board sensors perform fixed-rate measurements, sending out a data-ready signal every time a fresh measurement is available. This data ready signal can then be used as an interrupt when performing state estimation using a Kalman filter, thus pulling in the measured data the moment it becomes available. Indeed, for convenience, we typically take the clock signal coordinating the discrete-time calculations of the Kalman filter to be the

data-ready signal of the IMU itself.

Alternatively, you can set up flags for background monitoring, and keep the Beret into a low power sleep state, in which it is sipping power off a coin cell. Then, when there's a tap, a shake, a magnetic field spike, or a change in ambient temperature or pressure, or when an off-board sensor detects a change in liquid level, pressure, temperature, pH, etc., you can wake up both the Beret and the connected motherboard via the power MOSFET,

and actuate something as necessary, like opening or closing a window, moving a robot arm, advancing a conveyer belt, or turning a valve.

To quickly review the connectors again: the several dark blue connectors are JST-ZH, which can drive up to 1A of power per pin, are used for discrete connections to the nearby motors and encoders and various other peripherals, as well as to connect to the CAN and RS485 transceivers for long-distance communication.

[A key idea here is that, if you're using CAN or RS485, you would use a short jumper from these little JSTs to ruggedized connectors mounted on the bulkhead of an environmentally protective housing a few centimeters away, then use a shielded twisted pair to connect from that ruggedized connector to, say, the barn or chicken coop a quarter mile away.]

the 0.1” 1x9 Arduino-like “shield” connectors are used to expand the functionality of the Beret, and can drive up to 3A per pin; they include two digital headers, which include SPI and I2C connectivity to the MCU, and an analog header, which handles the DAC and ADC functionality.

the two blocks of 3x5 signal headers are standard connectors for servos and ESC’s, and can drive up to 3A per pin, and an industry-standard JST-XH connector is used for monitoring the voltage of each cell of a LiPo battery, a USB micro B input is used for for programming the MCU using your laptop computer, and, of course, a motherboard header is included, for convenience, to attach to the motherboard.

Beret shields are connected on top of these Arduino-like header pins. Optionally, shields

can also connect to 1 (or, to all 3) rows of Signal Header A, which can thus provide five extra digital signals from the MCU, in addition to providing a whole lot of power (up to 28V at up to 12A).

All of the pins of the 1x9 headers, as well as Signal Header A, are aligned on a standard 0.1” grid, so it is quite easy to attach to them.

Shields provide substantially increased optional functionality to the Beret ecosystem.

- They can be of a “regular size”, which is 1.3” by 0.9”.

- They can be a bit taller, picking up 1 (or, all 3) rows of Signal Header A.

- Or, they can even be larger, covering up a bit of the functionality exposed elsewhere on the Beret, in order to provide additional surface area on a Beret Shield if you need it; note that the Shield connectors are high enough that you can actually sneak wires underneath it, to connect to the Beret JSTs.

As an example, here is our low current brushless DC motor beret shield. We actually have six connectors on this shield, for driving six small brushless DC motors, running at up to 24V and up to 2A.

Beret shields come in three types.

The first type, Prototyping Beret Shields, just have an array of pre-drilled holes on a 0.1” grid. They can either be: - non-plated, to provide a mechanical backing of COTS PCBs, or - plated, for rapid development and testing of your own circuit designs. You can easily populate a prototyping Beret shield with a few small components on a standard 0.1” grid.

We are also making available a Beret Shield with two custom 128-pin breadboards, as shown here, to make the problem of quickly testing new circuit designs even easier.

The second type of Beret shield is Prefabricated. Our team is currently designing a variety of dense Beret shields, with commonly-needed functionality, and will develop a GitHub repository where the open hardware designs of these shields will be shared (by us, by other vendors, and by individuals) in a community-supported effort. We will prefabricate many of these shields, as demands dictate. Prefabricated Beret Shields will thus provide you, out of the box, with

a wealth of additional, optional functionality that didn't make it onto the Berets themselves.

For instance, the first Prefabricated Beret Shield that many people are going to want is one with brushless DC motor drivers. As shown here, we selected some modern “sensorless” BLDC motor drivers from the TI catalog to make the first such Beret Shield.

- Here it is mounted on a Raspberry Beret. - And, here it is stacked.

Note that, when making such Shields stackable, we identify which Shield is which electronically by using a couple pf backside solder jumpers, configured differently on each shield used, so we can actually stack up to four of these shields without getting their communication signals crossed.

Here is a shield with additional brushed DC motor drivers, again with a couple of backside solder jumpers to make them stackable.

Here is a shield with a little 0.96” OLED display and a couple of buttons, which fit quite compactly into the expansion quadrant, providing an effective mechanism for displaying quite a bit of useful information at run time.

Note that several other prefabricated Beret Shields ideas are also currently under active development.

The third important class of Beret shield is Custom, a category which includes all of the Beret Shield designs to be developed by you, the growing Beret community. To get started, you can modify directly the open-hardware circuit designs of the several prefabricated Beret Shields that we will provide at our community-support GitHub repository, and tweak them to your own precise needs. (Hopefully, you will be willing to share at least some

of your Shield designs back with the Beret community, by providing links back to your own public GitHub repository, to assist others by contributing your own hardware designs.)

The ability to quickly design and inexpensively manufacture custom Beret Shields is a game changer, as it facilitates the dense and secure arrangement of your choice of components into a robotic system for long-term use… a solution that is much better than implementing fragile little white breadboards in prototype robotic systems!

We are also working with a couple of other expansion board layouts in the Beret ecosystem, including high-current brushless DC motor driver boards (the size of a Raspberry Pi), and smaller SHIMs for breaking out the functionality of a motherboard header.

A few other random points worth noting: - There’s Manchester encoding for IR communication available on a pin. - There's a place for affixing a rechargeable coin cell on the back. - The CAN and RS485 transceivers can optionally be terminated on the back. - There’s a spot where an additional 6mm x 8mm QSPI flash memory IC can be soldered on (with capacity up to 512MB). This IC just

has eight pins, so you can actually solder this on yourself pretty easily, if you need it… - There are backside solder jumpers built right around the pins of several connectors, which provide a compact way to enable the option of powering that connector with either 3.3V or 5V, as needed.

- There is limited ESD protection on some inputs, as specified here. Of course, this protection is not provided everywhere, so please do be careful, you can indeed fry this board if the events of the day conspire against you.

With that, I wanted to offer a heartfelt THANK YOU, in advance.

It is primarily going to be via the support of the already growing Beret community, hopefully to include you, that such community-supported open hardware designs, and the community-supported open-source software driving the Beret ecosystem, is going to grow and flourish and realize its full potential, in both the education and the product development settings. We look forward to being an active participant in this broader open design effort.

settings. We look forward to being an active participant in this broader open design effort.

With your help, will be also working up some hat designs soon (I mean, the kind that you wear on your head), and provide them essentially at cost, to recognize and advocate your essential and valuable involvement in this unique effort.

The data sheet for the Beret family of boards, and other related boards in the growing Beret ecosystem, is being developed as chapter 5 of a new book that we are writing, called Renaissance Robotics. You can pick up that datasheet, and find a ton of other useful

Renaissance Robotics. You can pick up that datasheet, and find a ton of other useful related information, at robotics.ucsd.edu/RR.