Berets: Ausgleich hoher Ströme mit HDI und BGAs auf einer Familie von Motorsteuerungs-Leiterplatten – AltiumLive 2022

Diese Keynote ist eine Einführung in das Beret-System. Lernen Sie das Design eines neuen Ökosystems mit kleinen, leistungsstarken Motorsteuerungs-Leiterplatten kennen, die die Entwicklung und den Einsatz von Feedback-Controllern für komplexe mechatronische Systeme vereinfachen und beschleunigen.

Keynote-Highlights:

• Einführung in Berets: kleine erweiterbare Trägerplatten zur Beschleunigung der Entwicklung kostengünstiger Robotersysteme

• Plattformportabilität von Berets

• Was das Beret-System bietet

• Einblicke die Funktionsweise von Berets: Open-Design-Hardware, die durch Open-Source-Software koordiniert wird

• Wie Berets die Modifikation von Hardware- und Software-Designs vereinfachen, um maßgeschneiderte Controller für spezifische Anwendungen zu entwickeln

Zusätzliche Ressourcen:

• HDI-Designgrundlagen und der Herstellungsprozess für HDI-Leiterplatten
• Fortschrittliches Design von Leiterplatten mit hoher Dichte in Altium Designer

Transkript:

Thomas Bowley:

Hello, my name is Tom Bowley. And today we are talking about the COVID quarantine project that I worked on together with Ricardo Hornstein. With this project, we are introducing Berets, which are small extensible carrier boards designed to rapidly accelerate the development of low cost capable robotic systems, leveraging modern single board computers. Berets are characterized by both the ability to carry high power at up to 20AMPs and 28 volts where necessary, as well as the high density integration of about 20 advanced ICs. Notably, including the hundred pin and STM 32 G4 with a bulk grade array, thus incorporating the bulk of the functionality needed to coordinate and drive several motors servos in the ESCs of a small robot to a cyber physical system. I read somewhere online, this nice quote, that white spaces were unmet and unarticulated needs are uncovered to create innovation opportunities. I believe our Berets indeed address a significant white space in the rapidly growing field of robotics.

And I hope by the end of this talk, you're as excited about leveraging Berets in new future robotics projects as we are for ours. 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 and complex robotics applications. The central challenge, however, is that we are always stuck reinventing the wheel on several mundane, low level tasks such as how to do efficient voltage tribulation from lipo batteries to the standard 12 volts, five volts, and 3.3 volts that you need to put a robotic system together, as well as several other sub problems, such as incorporating H-bridges to drive fresh BDC 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 the SCs. Counting clicks from quadrature encoders to monitor shaft rotations, communicating with other sensors and actuators using I2C S SPI, UART as well as CAN and RS45 integrating an iMU, magnetometer barometer and GPS for situational awareness, et cetera. 

Dealing with all of this extraneous stuff from scratch every time we 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 much of the typical functionality that you need for small robotic systems built right in. And additionally has a 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's a map of some of the key functionality included on the Raspberry Beret. Seven dedicated quadrature encoder counters marked E one to E seven for monitoring shaft rotations, two flexible H-bridge systems marked DRVa and DRVb. Wired up to M one through M 12 and capable of driving several motors and steppers. All of the voltage regulation circuitry needed to support two 2S to 6S lipos, standard three pin signal headers for driving up to 10 servos in the SCS, a small SGM 32 G4 micro controller to coordinate everything, CAN and RS 45 transceivers and pin outs for communication to a Daisy chain of several remote devices and challenging environments with potentially significant ground potential differences, a lipo battery connector, and an intuitive state of charge indicator, a USB connector for programming from laptop, et cetera.

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 cell phone grade, single board computer like this one currently available from Qualcomm and others in the 96 board 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're thus also introducing today, the Black Beret to support the 96 boards 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.

Here's an outline of our talk today, I'll start with a brief overview of the family of boards that we are developing. And some of the background work that motivated it. I'll then shift into a technical description of the key Beret subsystems. I'll then tag team with Ricardo, who will give a survey of some of the heavy lifting that was done at Altium that made this whole project come together. In total, the Beret family has been 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 single board computers available today, or 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, feeding assistant, mobility enhancement, food preparation, cleaning, inspection, security, package delivery, the automatic opening and closing of windows and control of fans, et cetera. 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. Beret can also be used in standalone mode, eliminating Linux based single board computer altogether. Recall that an SDM 32 G4 micro controller is included, which is built around an ARM cortex M4 F 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 multi threaded code that efficiently controls an entire robotic system directly using only a small but mighty ARM cortex M class processor running a realtime operating system 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, multi threading coding techniques, but then working with a different team in a different country, speaking a different language to implement your tune feedback controllers on a 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 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 primarily focused on power regulation with well filtered switching regulators and feedback control of various types of motors. I've already mentioned many of these capabilities in my first few slides. I'll come back to this capability summary listed here at the very end of this talk.

There is six variants of Berets currently being developed. I've already introduced the Raspberry Beret, which is a full featured Raspberry Pi board, sometimes called a hat. We have also a reduced version of this board called the Red Beret that we'll make available at low cost. It uses the same PCB just partially populated, which helps 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 96 boards CE format. We additionally have a version called the White Beret under development to fit the BeagleBone black and AI.

We're also making a small wired standalone version called the Green Beret which is designed to run as a CAN or RS45 slave device on the 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 RS45. Whereas if you're developing a smart car type application where you are worried about noisy voltage fluctuations and particularly strong ground potential differences, 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 brush DC motors with a Green Beret, you'll need to incorporate them using one or more of our Beret shields. Finally, we're also making a small wireless standalone version for mobile applications and the same compact form factor called the Blue Beret. This board will make a bit of extra space by getting rid of the CAN and RS45 subsystems and rearranging bit, allowing us to fit onboard one H-bridge subsystem to drive a handful of brush DC motors without requiring a Beret shield.

We are thus planning on six distinct boards that have different numbers of motor drivers encoder counters and pin outs for servos ESCs and wired com as required for different applications. Four of these boards support CAN and RS 45. Four of them are full size, two for the Raspberry Pi. One for 96 board CE format like the Qualcomm RB5 and one for the BeagleBone Altoids 10 form factor. And two of them are a bit smaller and designed for standalone applications. One of these standalone boards is designed for wired applications to be driven as a slave device over CAN or RS45. And one of these standalone boards is designed for wireless mobile applications. Again, small expansion boards or Beret shields round out this Beret ecosystem, extending the base functionality of the Berets to incorporate additional common functionality that you might need that is not already present on the Beret that you plan to use. Like breadboards for quickly testing new circuit designs, brushless DC motor drivers, additional brushed DC motor drivers, OLED displays, differential GPS units, analog filters with digitally adjustable polls, zeros in gain additional I2C and UART connectioners, et cetera.

Just one slide of background on how we got into this project. We played a key role working together with Jason Kridner and his team at beaglebone.org in developing the BeagleBone Blue. We learned many valuable lessons, some the hard way in that effort, including that surface mount JSTs break off of PCB pretty easily. You really need to use pin through whole 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 product development setting. Single board computers get faster every year as the march of progress in electronics also known as Morse 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 voltage regulation and motor control functionality. This is precisely what we're doing with the Beret family of boards.

There is a large range of wireless standards, wifi, LoRa, SIG Fox, Bluetooth, Bluetooth low energy, Zig B, Z-Wave, sub one GHz, LTEM and many others. And these standards are evolving quickly. Different applications demand different wireless standards. It is thus essential that the user be allowed to select which wireless standards they want to implement. So wireless connectivity and 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 single board computer that you might already be using,, you can select precisely which wireless standards that you want to use and connect it directly to the MC on the Beret with a fast dedicated SBI or UART connection. 2S lipos are insufficient from many applications of interest, 4S or 6S lipos with substantial current carrying capability provide for a much larger range of interesting robotics applications.

The IMU needs to have a dedicated SBI connection to the MCU, which should run a realtime operating system or RTOS to provide near realtime 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 the successor to eduMIP dubbed myMiP, which will support both the BeagleBone Blue, as well as the entire Beret family of boards. MyMiP will for the first time enable makers in high school and beyond to design and print shells, leveraging our free starter point designs. That easily slide onto the tabs at the shoulders of the bit frame attached securely by a small bolt holes at the front and back bumpers. Thus enabling essentially anyone with access to a 3D printer to bring their 3D prints to life balancing and driving within minutes of assembling the control board and chassis together with the user designed and 3D printed shell.

We aim to foster a friendly collaborative environment in which young makers may create, share, and modify such shell designs through any of the dozen or so popular 3D CAD sharing sites already out there like Thingiverse and GrabCAD. I'm particularly fond of the Easter island statues, but I very much look forward to finding out what creative young makers come up with themselves as myMiP shells. Other starting point ideas that you might bring to life using a myMiP chassis include busts of your favorite scientists, your least favorite politicians or your favorite composers. Spaces, of course included in the design to incorporate a powerful cube speaker inside. So your creation can announce its arrival appropriately. At the college and graduate level, additional challenges that can be addressed, include the perennial myth, bring me a beer problem. Leveraging the beer can holder attachment that we have already designed. Effective control design for this beer oriented problem is especially challenging as the total mass and distribution of the MiP change substantially when a full beer can is added or removed from the beer can holder. These control challenges are further amplified as multiple beer cans are successfully emptied during the course of this research investigation.

In short, myMiP provides an educational reference platform which can be used to motivate high school makers towards science, technology, engineering, arts, and mathematics, or STEAM, and introduces the capabilities of the BeagleBone Blue and the Berets as well as the effects of beer on the whole endeavor. At the college and graduate level many interesting embedded control challenges may be studied with this low-cost minimalist student owned controls lab. Of course myMiP only really intends to provide starting point inspirations. These motor control boards are really capable of so much more, which the student is substantially prepared to consider once he or she really unpacks everything that is being done to balance, including parallel threads that communicate with each other, with each thread running at a different rate and a different priority. And with motors, encoders and various other external digital and analog devices connected to the control board using standard protocols like SBI, UART CAN and RS45.

I'd now like to shift gears to get into a somewhat deeper technical overview of some of the key features of Berets starting with power regulation. For lipo or wall power input, the standard XT 30 connector is incorporated running it up to 15 amps continuous and 20 amp peak and at up to 28 volts. So Berets are characterized by some pretty serious power carrying capabilities. There is a MOSFET together with an ideal diode controller that protects the board, which can both shut the main power and put off and later, turn it back on. There is a switching regulator to provide Vs1, which selectable somewhere in the range of 3.3 volts to 12 volts. And up to six amps. Vs1 is normally used to drive the servos and the ESCs. There is a switching regulator to provide VMB, which on most Berets is five volts and up to six amps to drive the attached mother board and to drive some of the external peripherals that you might want to hook up.

Finally, there is a switching regulator to provide 3.3 voltage up to three amps to drive the several ICS on the Berets and to drive the rest of the external peripherals that you might want to hook up. The outputs of all three of these switching regulators are well filtered with very little voltage ripple. We also have the power op amp that provides an intermediate voltage Vs2. This can either source or sync up to 400 mA and connect a reference ground for the powerful analog subsystem, which normally operates at about 1.65 volts halfway between zero and 3.3 volts. This op amp output can thus act as the ground signal for the powerful analog subsystem when operating in a bipolar setting. The setup I just described is used on the three Berets that have five volt motherboards. The Black Beret drives the motherboard that requires about 12 volts input to operate and communicates to its connected peripherals at only 1.8 volts.

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.3 volts or five volts. Note that we use effective 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 12 volt mother board. Also, a 96 board CE format board itself generates five volts from the 12 volts provided to the mother board. So we simply pass that five volt bus back up to the Beret over the low speed header. The black Beret itself does not actually generate five volts. Note that Vin powers the motor drivers directly, Vs1 one powers the five servos CS that you hook up to signal header B.

You can power five more servos or ECs on signal header A with either Vs1 or the Vin directly. There is a 12 amp sub connector, which allows you to bring a whole lot of power up to 28 volts at up to 12 amp out on signal header A. VMB powers the attached motherboard through the motherboard header. The 3.3 volts and five volt buses power the logic circuits of the Beret the GSTs and the digital analog headers. And finally, all of the digital outputs are 3.3 volts, TTL and five volts tolerant. So it can drive and communicate with peripherals that operate natively at either 3.3 volts or five volts. Here's the Bill of materials, so most significant ICs use ordered by vendor and sub ordered approximately by cost. Advanced ICs are implemented in the Berets across the board. I told Ricardo I wouldn't use that pun.

I think I hear him crying over there in the background. The vendor data sheets that describes these individual ICs and our data sheet that describes how these ICs are used on the Berets, which I'll give a link to at the end of this talk, go 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 sub problems that must be solved when building up control boards for small robotic systems. We just finished talking about the power regulation quadrant of the Berets. The most important ICs related to power regulation are the power MOSFET and the ideal diode controller that drives it. And the switching regulators implemented to generate Vs1, VMB and 3.3 volts. Note that, the power MOSFET that we have selected has a remarkably low RDS on, of only 0.8 mohm and has a remarkably fast turnoff delay time TD off of 44 nanoseconds, thus reducing power losses at the MOSFET while providing excellent protection to the board. In the event of unexpected short circuits. 

The switching regulators we have selected have very fast integrated switches substantially reducing their overall footprint on the Berets and allowing the use of relatively high switching frequencies up to about one megahertz without substantial loss of efficiency. Thus enabling us to easily filter out the PWM oscillations of their outputs using LC filters with relatively small inductors and capacitors and resulting in essentially ripple free regulated voltages. We previously discussed the CAN and RS45 functionality implemented, here are the modern transceivers that we have selected to implement these features. In the following few pages of this talk, I'm going to focus in particular on the SDM 32G4 micro controller that we have selected to coordinate everything on these boards and the remarkably flexible brushed motor drivers or DRVs that we have implemented.

The functionality of the small 100 pin micro controller that we chose is significantly extended by implementing a seven channel LED driver that implements both low frequency and high frequency for both brightness control and signaling on our important LEDs. A 24 channel GPIO expander from an XP and a 32 kilohertz MEMS oscillator, which makes the timing tasks executed by the micro controller and IMU significantly more stable and accurate.

We will also discuss the best in class magnetometer barometer and IMU that we have selected for situational awareness, as well as the power op we have selected for the DAC outputs in the powerful analog subsystem on the board. I'd also like to take a moment to recognize that essentially all of us who are tasked with designing and fabricating new printed circuit boards, these days suffer from a newly identified medical condition known as acute BOM angst. In this regard, I'd like to personally thank our collaborators at ST and SV tronics in particular for assisting us in hobbling into the early prototyping stages of these Beret boards, helping us to identify a few small stashes of the particular ICs that we need to get prototyping moving. Large scale production schedules of the Berets however, remains significantly uncertain as a result of this condition that we face now as an entire industry.

As we look at the festering worldwide supply chain issues and integrated circuits, maybe in our discussion at the end of this talk, we can explore if there is any further lobbying that we can do effectively as an industry block, including industry giants, like Apple, Samsung, Google, GM, and Ford, to expedite the world out of this self-inflicted jam. I would like to see a collective request articulated that IC manufacturers and the governments of the respective countries that they operate in redouble their commitments to ensure that this acute condition does not become chronic, less, both innovative prototyping and production of the vast range of advanced technological solutions and products continue to be stunted. 

In particular, the inspiration and education of the next generation of engineers must not take a backseat during this recovery. This new generation will be charged with finding engineering solutions of some truly perplexing problems that my generation is leaving them, including an environmental catastrophe, mass extinctions, and massive inequality in access to basic human needs, such as clean water and food. The next generation of engineers cannot afford to fail as they confront these life threatening challenges. We need to invest in their generation now. Anyway, I digress. Back to Berets, The micro controller used by the Berets is a hundred pin version of the STM 32 G4 with 512 kilobytes of flash.

These are its specs. This MCU has several supplemental hardware units, including CORDIC units for the computation trigonometric functions, filter math units with hardware ring buffers for computing FAR IR filters, cache memory accelerators, and counters, timers, and dedicated communication units. All of which are immensely useful in feedback control settings. We use this supplemental functionality on the STM 32 G4, 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 of these modules up to use these GPIOs to drive random other simple functions on the board. We thus added a GPIO expander to provide 24 GPIOs to handle various other flags and simple functions and a seven channel LED driver for the main LED indicators on the board. We also included of course, several status LEDs directly to various traces already existing on the board. 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's the essential connectivity chart of the Berets. The MCUs in the middle, and all of the green ovals are the various hardware subsystems that surround the ARM cortex M4 on the SDM 32 G4. So to send out PWMs to drive servos and ESCs to count the transitions of quadrature encoders to track shaft rotations or to communicate over SBI, UART, to I2C et cetera, 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, et cetera.  In order to estimate the evolving dynamics of the system since the other more mundane tasks, including the repeated calculation of many of the FAR and filters using ring buffers as required to evaluate the feedback itself are offloaded to dedicated hardware subsystems on the SDM 32. We have plenty of clock cycles left over to perform this centrifusion and state estimation on the ARM core itself. 

The STM 32 runs multi threaded C code and multiple threads each running at a different rate and a different priority and all coordinated under freeRTOS. The low level software library driving this entire system is designed to be compatible with robot control library developed previously by James Charleson a former student in our lab. The execution of the tasks, which can be invoked by this API will be split between the single board computer being used and the Beret itself. We worked closely with both MathWorks and National Instruments during our previous work with BeagleBone.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. Let's to move now to the DRV 89 12-Q1 motor drivers from Texas instruments.

A pair of these DVS are implemented on most of the Berets. Each of them has 12 half-bridges and each generates up to four PWM, a fast dedicated SBI connection attaches these DRVS to the micro controller. The micro controller, thus simply instructs the DRVS that command a direction cycle to actuate the motors over SBI and the DRVS generate the PWMs necessary to make it happen. This setting facilitates nominally simultaneous independent bidirectional control of eight brush DC motors. There's quite a bit more to the story that these motors can do however, as shown on the next slid. Note first that the DRVS operate directly at Vin up to 28 volts at up to six amps per DRV. This power flows north from the XT 30 input and the power MOSFET. Note also that the voltage Vin can drop by over 25% as the connected lipo battery discharges.

This is counted for in software by monitoring the voltage of the lipo and the Vin bus and scaling the feedback gains of the brush 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 pin through hole. That is, they go all the way through the board and are soldered on the opposite side. So they're very durable. In fact, across the board, all of the connectors illustrated in dark blue are JST ZH. The DRV 89 12-Q1 can operate in three 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 six motors per DRV, each operating on one amp, recall that you only have four independent PWMs per DRV though. So at any moment you can end up only four motors.

Note, however that you can change, which four motors are driven independently at whatever duty you want at any moment. The other two motors are called slaves and can operate in full forward, full, reverse, full break, or full coast, or they can duplicate to the PWM frequency and duty cycle of any of the four independent motors. This is actually sufficient flexibility in most applications, which usually have some diversity of driving requirements such that you usually don't 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 into the DRV itself. We can set this logic and software to coordinate some outputs, to get to an identical PWM signal accurately synchronized from a single PWM generator, and then gang these one amp outputs together using external wire harnesses to drive more powerful motors.

In the case shown here, we illustrate the driving of one motor at four amps and one motor at two amps. Other ganging configurations are also possible. One motor at six amps, two motors at three amps, three motors at two amps each et cetera, but wait, there's more. If the operating voltage is low enough that it is insufficient to drive two motors and series because the operating voltage doesn't overcome the stall torque of two motors and series, then a unique sequential motor is also available in which you can set the outputs three, six, nine and 12 as high impedance inputs shown here in red while driving the four motors indicated here in green for a while. 

Then you can permute which four outputs you set as high impedance inputs and drive the four motors now indicated in green for a while. Then you can permute again and drive these four motors for a while, et cetera. 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 advanced assembly line sort of applications 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. Let's actually pause this discussion [crosstalk 00:28:21].

(music).

Berets are particularly well suited for controlling the mini motors in such novel assembling line type applications, which have a significant driving requirements. That is the motors are never all on at the same time. Note, also that various combinations of the DRVS independent, sequential and parallel modes are also possible as necessary in a given application. Berets are set up by default to drive ten servos or ESCs of a variety of sizes up to three amps each. Again, assuming some diversity of driving requirements. These connections are made using signal headers with 0.1 inch mil pens, providing signal power. Again on signal header A, we can select power between Vs1 one or Vin by default ff course, the Beret provides signals on pin one of these signal headers for driving standard servos and ESCs. However, there are several alternative hardware supported nodes that you can select on the digital ends of the signal headers.

You can set up to two 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 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 seven quadrature encoder tenants prewired on convenient JST connectors that include power and . Power is selectable between 3.3 and five volts like the PWN generators driving the signal headers. The counting associated with these encoder connectors is performed on dedicated hardware units on the STM 32 G4. the bulk of the in the background without loading manual.

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, 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 in ESCs, et cetera. So again, there's remarkable flexibility of how you can configure the several digital channels made available in the various connectors of the Beret depending upon your system requirements. There's also an analog header that has two 12 bit DACs, the inputs and outputs of the spare opamp, ready for the user to wire up and two 16 bit ADCs. So for example, you can easily hook up a Beret to a two input, two output analog system and take its full two by two. Leveraging the Beret's, builtin analog subsystem.

Additionally, the Beret monitors, the individual cell voltages of a lipo and includes 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 coordinate lipo battery charging with the Berets. We made a different design decision here than we did with 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 this lipo charging separate from the robot itself and use it whenever you're plugging into 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 tuneable gain and a software tuneable cutoff frequency. To get the most out of the available dynamic range of the STM 32 G4's, ADC inputs. The components in red here are actually included on the STM 32 G4 itself. And the additional components in black are on the Beret. The digital shown allow you in software to adjust both the gain of the filter between a factor of one X and 4,000 X and the cutoff frequency of the filter between 34 and 3,400 Hertz. For an attitude estimation, we have implemented the best in class magnetometer barometer and IMU available today. Their sensitivities, which are pretty remarkable are indicated here. Note that many such sensors, especially 9-axis IMUs that integrate an IMU with a magnetometer together on one IC are not nearly this accurate. So buyer beware.

There's also a 32 kilohertz MEMs oscillator that hooks to both a realtime clock of the SDM 32 Q4 as well as the IMU, which significantly improves timing accuracy. By default, these onboard sensors perform fixed rate measurements, sending out a data ready signal every time a fresh measurements is available. This data ready signal can then be used as an interrupt when performing state estimation using a filter, thus pulling in the measured data into the estimator the moment it becomes available. Indeed for convenience, we typically take the clock signal, coordinating the distribute time calculations of the filter to be the data ready signal of the IMU itself.

Alternatively, you can set up flags for background monitoring and keep the Beret in a low power sleep state in which it is just sipping power off of a coin cell. Then when there's a tap, a shake, a magnetic field spike, or a change in the ambient temperature pressure or an off board sensor detects a change in liquid level or pressure or temperature or pH, et cetera, you can wake up 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, turning on a fan, advancing a conveyor belt, or turning a valve. To briefly review the connectors again, the several dark blue connectors are JST TZH which can drive up to one amp per pin and are used for discrete connections to the nearby motors and encoders and various other peripherals, as well as to connect to the CAN and RS45 transceivers for long distance communication.

A key idea here is that if you're using CAN or RS45, you would use a short jumper from these JSTs to ruggedize connectors mounted on the bulkhead of environmentally protective housing, a few centimeters away. Then use a shielded twisted pair to connect from that ruggedized connector to say the barn or the chicken coop quarter mile away. The 30.1 inch one by nine per Arduino like shield connectors are used to expand the functionality of the Beret and can drive up to three amps 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 0.1 inch three by five signal headers are standard connectors for servos and ESCs and can drive up to three amps per pin. And an industry standard JST X H connector is used for monitoring the voltage of each cell of a lipo battery.

A USB microB input is used for programming the micro controller using a laptop computer. And of course, a motherboard header is included to attach the motherboard. The new pinout standard for the powered and unpowered connectors used on the Berets was designed with exquisite care. We call them Recon and Yukon and will motivate and describe them briefly on the following three slides. The actual pin outs on the Raspberry Beret are shown here. This and other such highly detailed information is available in the comprehensive Beret data sheet, a link to which will be given at the end of this talk. In general, when scouring the literature, we found that existing I2C SPI and UART connector standards were either unnecessarily large wasting valuable board space or were too fragile, requiring delicate surface mount housings on the PCB. Further such existing standards, lacked flexibility for incorporating optional pins, which was an important feature that we wanted. We thus set out to establish a new set of connector standards.

What we came up with is a design we dubbed Recon Renaissance connectors and Yukon unpowered connectors. This new family of connectors standards is based on the use of JST ZH connectors, which are the smallest broadly available connectors that are low cost, one amp per pin, non reversible mating and shrouded headers, and are pin through hole for durability. Further, these connectors exhibit a unique flexibility wire housings connected to the clients with fewer pins can fit into shrouded headers on hosts with optional, additional pins. Each of the recon standards like the recon SPI standard shown here starts with power and ground and the required digital pins, mostly MISO clock and in a single slave select line. Followed by additional optional pins, more slave select lines, interrupt, reset lines, et cetera. As long as the host supports at least as many of these additional pins as a given client needs, you can connect one to the other further.

Further VCC is always on pin one of a recon connector. Thus, if you misinsert to connector from a client and fail to engage pin one on the host, you simply failed to power that client and it doesn't work, but you don't fry the client by applying power to a pin that shouldn't be connected to power. A Yukon connector is simply a recon connector that drops the power in the ground, which is useful if you're specifically wiring up a self powered device. VCC equals 3.3 volts is provided by defaults and 3.3 volt TTL digital logic is implemented on all recon hosts. To support a broader range of clients other voltages may be selectable typically via a solder jumper on a recon host. But if such a feature is selectable, then those voltages need to be handled properly by the recon host itself on all digital I/O channels.

That is if VCC equals five volts is selectable, then the host 3.3 volt TTL digital pins need to be five vol tolerant. And if VCC equals 1.8 volts, is selectable, then the host must provide all necessary level shifting to and from VCC on all of its digital I/O pins. In the near term if there is sufficient demand, wire harnesses will be made available to connect recon hosts like the Beret directly to the cornucopia of peripherals that implement other standards that are available out there today. It is hoped that in the longer term, other vendors might actually consider adopting the small, durable and uniquely flexible recon standard that we are introducing today with the Berets. Note that all connectors on the Berets implement the new recon and Yukon standards in one version or another. Note that we also define a stackable version of these standards using popular Arduino, like 0.1 inch stackable headers.

For more details on these new connector standards I'll again, refer you to the Beret data sheet, which I'll provide a link to at the end of this talk. Beret shields are connected on top of these Arduino like header pins. Optionally shields can also connect to one or all three 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 28 volts at up to 12 amp over the V A and ground pins. All of these pins on the one by nine headers, as well as signal header A are aligned on a standard 0.1 inch grid. So it is quite easy to attach to them. Shields provide substantially increased optional functionality to the Beret ecosystem. They can be of regular size, which is 1.3 inch by 0.9 inch. They can be a little bit taller picking up one or all three rows of signal header A or they can be even larger covering up a bit of the functionality exposed elsewhere on the Beret in order to provide additional surface area on the Beret's shield if you need it.

Note that shield connectors are high enough that you can actually sneak wires underneath it, connecting to the Beret JSTs underneath. 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 it up to 24 volts and up to two amps. Beret shields come in three different types. The first type called prototyping Beret shields have just an array of predrilled holes on a 0.1 inch grid. They can either be non plated to provide mechanical backing to commercial off the shelf PCBs or plated for rapid development and testing of your own custom circuit designs. You can easily populate a prototyping Beret shield with a few small components on a standard 0.1 inch 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 we'll 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 a modern sensorless BLDC motor driver 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 of backside solder jumpers configured differently on each shield used. So it can actually stack up to four of these shields without getting their communication signals crossed. 

Here's a shield with additional brush DC motor drivers, again, with a couple of backside solder jumpers to make them stackable. Here's a shield with a 0.96 inch 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 runtime. Here is a shield with the differential GPS unit note that several other prefabricated Beret shields are also currently under active development. The third important type of Beret shields is custom a category, which includes all of the Beret shields designed by you the growing Beret community. To get started, you can modify the open hardware circuit designs of the several prefabricated Beret shields that we will provide at our community spot and GitHub repository and tweak them to your own precise needs.

Hopefully you'll be willing to share at least some of your Beret shield designs back with the Beret community, by providing links back to your own public GitHub repository, to assist others by contributing in 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 level white red boards and prototype robotic systems. We're also working with a couple of other expansion board layouts in the Beret ecosystem, including high current brushless DC motor drivers, the size of a Raspberry Pi and smaller for breaking out the functionality of motherboard header to the outside of the footprint of the Raspberry Pi itself. A few other random points are worth noting.

There's a Manchester encoding for IR communication available on a pin. We incorporate a few convenient buttons in both user programmable and system status LEDs directly on the board. There's a place for fixing a rechargeable coin cell on the back, which keeps the real time clock current for a scheduled system. Note that this coin cell is automatically recharged when the board is powered from a lipo. The CAN RS45 transceivers can optionally be terminated on the back, this spot or an additional six millimeter by eight millimeter QSPI flash memory IC can be soldered on with capacities up to 512 megabytes. This IC has just eight pins. So you can actually, solder this on the solve 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.3 or five volts as needed.

And there's a 12 amp shunt connector to provide high current at either Vs1 or Vin to signal header A and thus to the extended Beret shields. And finally, there's 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'd like to hand this talk over now to Ricardo, who will discuss how we implemented everything described above on some remarkably small PCBs leveraging many of the advanced features of all team.

Ricardo Hornstein:

Thank you, professor Bowley. Let me now give you a peek at some of the design tools and strategies we used when executing this design. First let's look at the stack up we converged to which is central to the Beret's functionality. Berets are eight layer PCBs designed with a very deliberate trade off, sufficiently thin copper layer thicknesses are needed to facilitate the breakout of a 0.8 millimeter pitch BGA while simultaneously sufficiently thick layers are needed in other sections of the board for high current traces. Thus, we actually use different thicknesses of copper on the eight layers based on each of the layers' primary functions and higher current planes were additionally stitched together on multiple layers. For electromagnetic interference and signal integrity considerations, we interlaced power and ground layers with signal layers. We used curve traces. So we avoided any sharp corners, even 45 degree angles.

We performed careful impedance matching to prevent signal reflections, and we used matched trace lengths per layer for high speed signals. In addition, analog ground is carefully isolated from the noisier power ground in sensitive circuits. Looking at the overall layout, we can map the board into quadrants. The logic sensor and expansion quadrant is in the Northeast. The connector quadrant is split between the Northwest and the Southeast and the power quadrant is in the Southwest with the motor quadrant just north of that. For efficient power distribution, high current traces are laid out as wide pores and kept as short as possible by some very strategic component placement, which honestly is probably the best Tetris that I've ever played. For example, take a look here. ViN travels north on multiple layers and similarly Vs1 travels east.

So it's easy to lose sight of the actual size of these small boards when I'm working on a 27 inch monitor with the board filling the screen but Berets are actually quite small and they're packed with quite a bit of functionality. The design of Berets is a balancing act between cost and density. In particular, a 0.8 millimeter pitch BGA, like we said, cannot be broken out with some HDI techniques, while we could have used the more expensive approach of blind and buried vias. We were able to implement via-in-pad technology well enough throughout the board to fit all the functionality we discussed earlier into a board smaller than even the Raspberry Pi. Via-in-pad technology allows the placement of vias underneath an SMD component pad rather than running a trace from the pad and then running the via up or down from there.

This saves significant space, which is important in some of the more crowded areas of the Berets. There are some important considerations when using via-in-pad technology, the most important of which is to work with your manufacturer to ensure that you achieve a nice flat surface on your pads so that the SMD component sits well on top of that and makes good contact. And so typically that means choosing the right fill process for your vias. And that will then result in a flat copper pad being placed on top of that. This modern PCB fabrication technique when used properly allows you to move components into a much denser arrangement, accomplishing a smaller overall footprint, which can be, for example, easily fit into a small robotic system, like a robot hand. All without breaking the bank with possibly more advanced density techniques. In order to detangle traces on this complex eight layer board some we call traffic rules were created. 

So we have one layer which is designated for north/south routing. As you can see here, and two layers were designated for east/west routing. While this was still challenging, the method of dividing the directionality greatly reduced the complexity of the routing puzzle given the spread of the interconnected components across our board. Another simple trick that proved helpful in tight spots primarily under the BGA was the reduction of pad sizes on layers, not connecting to the via. So while manufacturers recommend against the removal altogether of pads that are not connected on a particular layer, still a reduction in diameter is possible typically. And it was essential for the BGA on the Berets. Here's an example of the length matching by layer that was done on high speed signals and their corresponding clock traces. All teams interactive length tuning tool makes this process simple. And at least to me quite fun, actually, I like playing with the squiggles figuring out where they go. 

So note that the extra squiggles and these purple lines actually cause the lengths of these three traces to match exactly on each of the layers that they travel through. The net result of all this care is faster and more reliable communication between all of the components. Altium has proved to be a vital tool in developing this project for a number of reasons. And I'll cover a few of the standout or possibly lesser known tools right now. So we've had a few collaborators over the course of designing these boards and running version control through Altium 365 has allowed multiple people to work on different aspects of the board, simultaneously all through a centralized repository for a project or multiple projects for that matter. Shared access to all of those projects makes referencing colleagues' designs, even my own designs and things like mentorship, much smoother and effective.

The web interface has also been essential. So, when we're at a group meeting or when we're meeting with a collaborator and we want to pull out our phone or tablet, or even our computer without firing up Altium that web interface has proved to be a very useful tool. As discussed earlier, Berets are an ecosystem of boards that will benefit from the portability across the different platforms, like Raspberry Pi, BeagleBone 96 boards and others. The Black, White and Raspberry Berets though are nearly identical. They really only defer in the geometry power and connectivity based on their respective motherboard requirements. So in addition to that, the Green and the Blue Berets that were discussed are simply reduced versions of these three boards in one area or another. When we started designing this ecosystem then, the natural question we had was how do we ensure the consistency across these designs? When we make changes, say to a simple resistor  value or worse, something more complex without having to tediously repeat the changes for each board in each of the schematic project files. 

So the answer turned out to simply be managed schematic sheets in Altium. And so the way these work is that schematics are typically created as you would for a single project, but then they're uploaded to Altium 365 as a managed schematic sheet. Then these schematic sheets can be updated in a simple manner, similar to if you've ever updated a servo based component, or you've pushed to commit to a version controlled project. And so once the schematic sheet is on your server, it can simply be added to a schematic in any project, by anyone on your team for that matter. And treated as a read only schematic sheet in a hierarchical design.

So any changes that you make now to the master schematic are propagated to all the instances of that sheet throughout any of your projects thus maintaining a consistent design without much overhead. Lastly, when presenting to a group like this one, for example, where we hope at least a few of you will be interested in poking around our design. Altium viewer is really easy to implement in your own website resulting in a simple HTML page that gives a beautiful window into your project. Similar to this the sharing of projects within the Altium 365 portal has made sharing information with our manufacturer and other interested parties really just the simple click of a share button. So with that, let me pass it back to professor Bowley to wrap this up.

Thomas Bowley:

Thanks Ricardo. Before I conclude, I want to admit to you all a little secret though, this talk attempted to organize the final result of what the Beret system is and does in as structured linear manner as possible. The creative process of ideation and design of this new board ecosystem was highly nonlinear and a ridiculous number of back to the drawing board moments were encountered as later design tweaks, necessitated very significant changes to decisions that we previously thought were effectively finalized. I'd very much like to thank Ricardo for patiently putting up with me through this at times soul crushing creative process. I think the end result, which he did the bulk of the heavy lifting on is nothing short of spectacular. A less patient colleague manager or board of directors would certainly have never put up with our iterative creative process. So from the bottom of my heart here, Ricardo, thank you.

To summarize, as we said at the beginning, 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 SBCs available today or standalone. Their primary functions are to regulate power from 2S to 6S lipos and for the feedback control of several motors of a variety of possible sizes. The project goal 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. Potential applications are quite broad. Berets thus provide a platform, portable carrier board family that allows you to port your high level code from one Linux based single board computer system to another, as the algorithmic demands on your system increase while keeping the same low level interface. Berets can also be used in standalone mode eliminating the Linux SPC altogether.

The MCU on the Beret is quite capable of coordinating many low level tasks simultaneously in complex robotic systems. Working in such standalone modes to debug multi-threaded codes that efficiently controls an entire robotic system directly using only an ARM cortex M class processor running on RTOs helps to prepare a system for high volume production at substantially reduced system cost. Simply put our overarching goal with Berets is to significantly improve the lab prototype to consumer product workflow. The capabilities of the Berets are again, primarily focused on power regulation and feedback control. They include well filtered switching regulators generating an essentially ripple free 3.3 volts at up to three amps, five volts at up to six amps and an adjustable 3.3 to 12 volt at up to six amps. Dedicated hardware encoder counters for monitoring shaft rotations, several H-bridges for driving brush DC motors and stepper motors, dedicated PWN generators to control servos and ESCs, a full set of best in class attitude sensors, standardized pin outs for SBI I2C and UART, CAN FD and full Duplex RS45 transceivers for long range com 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 cutoff frequency of its second order low pass filters to get the most out of the available dynamic range of the analog subsystem.

With that, I wanted to offer a sincere thank you, in advance. It is primarily going to be by the support of the already growing Beret community, hopefully to include you that such community supported open hardware designs, as well as 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 interacting with all of you who desire to be active participants in this broad, open design effort. With your help, we will also be working up some hat design soon. I mean the kind that you actually wear in your head and provide them as 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 the other related boards in the growing Beret ecosystem has been developed as chapter five of new book that we are writing called Renaissance Robotics. You can pick up that data sheet and find a ton of other useful related information at robotics.uscd.edu/Berets. Thank you, and we hope to move to the question and answer period.