PREPRINT VERSION. 1

Robot Co-design: Beyond the Monotone CaseLuca Carlone Carlo Pinciroli

Abstract—Recent advances in 3D printing and manufacturingof miniaturized robotic hardware and computing are pavingthe way to build inexpensive and disposable robots. This willhave a large impact on several applications including scientificdiscovery (e.g., hurricane monitoring), search-and-rescue (e.g.,operation in confined spaces), and entertainment (e.g., nanodrones). The need for inexpensive and task-specific robots clasheswith the current practice, where human experts are in chargeof designing hardware and software aspects of the roboticplatform. This makes the robot design process expensive and timeconsuming, and ultimately unsuitable for small-volumes low-costapplications. This paper considers the computational robot co-design problem, which aims to create an automatic algorithm thatselects the best robotic modules (sensing, actuation, computing)in order to maximize the performance on a task, while satisfyinggiven specifications (e.g., maximum cost of the resulting design).We propose a binary optimization formulation of the co-designproblem and show that such formulation generalizes previouswork based on strong modeling assumptions. We show thatthe proposed formulation can solve relatively large co-designproblems in seconds and with minimal human intervention. Wedemonstrate the proposed approach in two applications: the co-design of an autonomous drone racing platform and the co-designof a multi-robot system.

Index Terms—Mechanism Design, Multi-Robot Systems, AerialSystems: Perception and Autonomy.

I. INTRODUCTION

Recent advances in sensor design and rapid prototyp-ing are enabling the manufacturing of low-cost robots withadvanced sensing and perception capabilities. For instance,one can implement high-precision visual-inertial navigationwith inexpensive camera and MEMS inertial measurementunits [1]. Similarly, modern embedded CPU-GPU [2] offerhigh-performance computing in a compact form-factor and ata relatively affordable cost. These trends, together with theavailability of low-cost micro-motors are enabling fast andcheap production of robotic platforms. In these cases, the mostexpensive resource becomes the effort of the expert humandesigners who are in charge of designing all the aspects ofthe robotic platform, including hardware and software. Whilethis solution is still acceptable in the case where low-costrobots must be produced in volumes (e.g., vacuum cleaningrobots), it may not be desirable when only few robots needto be deployed. Consider, for instance, the design of a dronefor hurricane monitoring [3]: the drone must be disposable,hence inexpensive, and it is not typically produced in volumes.In other contexts, one may need to devise a design quickly,in order to create a robot to be deployed in a time-sensitive

L. Carlone is with the Laboratory for Information & Decision Systems(LIDS), Massachusetts Institute of Technology, USA, lcarlone@mit.edu

C. Pinciroli is with Robotics Engineering and the Department of ComputerScience, Worcester Polytechnic Institute, USA, cpinciroli@wpi.edu

This work was partially funded by ARL DCIST CRA W911NF-17-2-0181.

Fig. 1. (a) We apply the proposed co-design framework to the design of themodules (motors, frame, computing, camera, battery pack) of an autonomousracing drone, (ii) Force diagram during forward motion (side view).

mission. For instance, one may need to design a search-and-rescue robot tailored to a specific mission (e.g., searchfor survivors in a narrow cave with a given size of theentry point). Finally, human design does not necessarily leadto optimal solutions. Designers typically consider differentrobotics modules in isolation in order to tame the designcomplexity, and such decoupling usually leads to suboptimalperformance.

These reasons motivate us to investigate computationalrobot co-design, which aims to create an automatic algorithmthat selects the best robotic modules (sensing, actuation,computing) in order to maximize the performance on a task,while satisfying given specifications (e.g., maximum cost ofthe resulting design). Here the term “computational” refers tothe fact that the design techniques can be implemented ona machine, and require minimal human intervention. More-over, the term “co-design” refers to the attempt to considerthe robotic system as a whole, rather than (sub-optimally)decoupling the design of each module.

Related Work. The problem of co-design in roboticstouches a wide span of research topics. In the most generalsense, it can be considered as the problem of designing boththe mind (software) and the body (hardware) of the robotat the same time. A few seminal works tackle this problemfrom an evolutionary standpoint [4], [5], [6], with approachesthat aim to either optimize specific behaviors (e.g., walking)or to explore catalogs of possible solutions to a generalproblem (e.g., locomotion). While related to the problem ofcomputational co-design as discussed above, these approachestypically abstract away several practical aspects of hardwaredesign, such as power consumption and material selection.

At the opposite side of the spectrum, a large body ofwork on software/hardware design exists in the embeddedsystems community, e.g. FPGA and ASIC design [1]. In this

arX

iv:1

902.

0588

0v1

[cs

.RO

] 1

5 Fe

b 20

19

2 PREPRINT VERSION.

domain, the focus is on the synthesis of practical solutionsthat explicitly consider low-level aspects such as power opti-mization and real-time scheduling in electronic devices. SinceChinook [7], a highly influential early approach, the field ofsoftware/hardware co-design has flourished, reaching relevantapplications in safety-critical fields such as the aerospace [8]and automotive industry. The inception of domain-specific lan-guages such as the Architecture Analysis and Design Language(AADL) [9] has enabled a systems-of-systems approach inwhich co-design can be coupled with a wide array of tools forproperty verification, both at the software and hardware level.These tools, however, are thought to support human design.

The field of modular robotics attempts to bridge low-level embedded system design with high-level functionalityspecifications. In modular robotics, the challenge is to createa diverse set of composable, programmable modules that canbe used to form robots with different capabilities. The recent,rapid development of 3D printing is offering increasinglypowerful tools to streamline the automatic design of roboticplatforms, and will arguably foster the development of modularrobotics. In a seminal paper, Mehta et al. [10] demonstrate thefeasibility of a procedure that takes a high-level human-definedspecification of a robot and outputs the 3D description filesof the components, along with instructions to assemble therobot, manufacture the electronics, and automatically generatethe control firmware. To the best of our knowledge, no workexists in the automatic generation of specifications that can beinput to this system.

A core issue in computational co-design is the conceptionof a suitable formalism to express the design problem. Ideally,an effective formalism for automatic design should combineadequate granularity along with guarantees of correctness.Evolutionary methods [4], [5], [6] combine a low-level para-metric representation, such as rigid bodies connected by jointsor voxel-based artifacts, with neural network-based control.The main issue of this representation is the amount of detailinvolved in the optimization process, which limits scalability,and the absence of correctness guarantees. Other formalismscloser to the human design process, such as the one fromMehta et al. [10] and AADL [9], achieve expressive power bynaturally incorporating modularity. Both languages represent aco-design problem as a tree composed of heterogenous nodeswhich represent hardware and software aspects of a robot.AADL, in particular, offers a set of tools specifically designedfor early analysis of candidate solutions, but without supportfor automatic exploration of the solution space. Correct-by-design compositional approaches have also been the focusof recent studies in control theory. For instance, Hussien etal. [11] proposed an automatic method to decompose a largecontrol problem into a cascade of simpler problem, under theassumption that the latter are feedback linearizable, while Kimet al. [12] devised a method to arbitrarily construct systemabstractions from simpler, well-posed components. Lastly,Censi [13], [14] proposed a powerful co-design approach thatenables the automatic generation of solutions from a speci-fication that includes recursive constraints. Censi’s approachassumes that a monotone mapping between resources andperformance exists, thus casting computational co-design as

a fixed-point problem in the solution space.Contribution. This paper builds on recent work by

Censi [13], [14] and pushes the boundary of computational co-design by relaxing its monotonicity assumption. Monotonicityimplies that investing more resources leads to an increasein the performance. However, it is easy to find interestingexamples for which this property does not hold. For instance,in the design if a drone frame, the fact that we increase thesize of the frame (resource) does not imply that the dronewill fly faster (performance). Similarly, in a collaborativetransportation problem, deploying a larger number of robots(resources) does not necessarily lead to an increase in theoverall performance of the system [15].

This paper presents a more general computational co-designapproach. Our problem formulation is presented in Sec. II,where we discuss the characterization of the design space andclassify the design specifications in terms of system-level per-formance, system-level constraints, and intrinsic constraints.Sec. II-C rephrases the resulting co-design problem in termsof a binary optimization problem, where each binary variableindicates whether a given component is chosen as part of thedesign or not. Sec. III discusses in which case we can expectto be able to solve the binary optimization problem using off-the-shelf optimization tools; in general, binary optimization isintractable, but there exist several algorithms and implementa-tions that are able to solve moderate-sized problems efficientlyas long as some property (e.g., linearity) holds. We showthat our approach allows recasting several functions that arenonlinear in the properties (or features) of the robotic modulesas linear functions. The proposed optimization frameworkalso makes it possible to model other constraints found inpractice, such as compatibility constraints (e.g., we cannot usea LIDAR-based algorithm to process data from a monocularcamera), which was beyond reach for existing methods [13].

We conclude the paper by presenting two applications of theproposed co-design approach to the design of an autonomousdrone racing platform and a multi-robot system. These ex-amples are presented in Sec. IV. Drone design is an inter-esting topic per se, and has already received attention in theliterature [16], [1], which however still lacks a computationaldesign approach. New and untapped challenges arise in the co-design of multi-robot systems. We are not aware of approachesthat specifically tackle this problem; however, a vast literatureexist on the automatic generation of control systems for robotsswarms, including evolutionary methods [17] and automaticgeneration of composable control structures [18].

II. GENERAL ROBOT CO-DESIGN

The co-design problem consists in jointly designingrobot software and hardware components to maximize task-dependent performance metrics (e.g., endurance, agility, pay-load) subject to constraints on the available resources (e.g.,cost). The complexity of the problems stems from the factthat a robotic system involves an intertwining of modules.Each module contributes to the overall performance of thesystem while potentially consuming resources. In this paper,we consider the realistic case in which we have to choose

CARLONE AND PINCIROLI: GENERAL ROBOT CO-DESIGN 3

each module (e.g., motor, embedded computer, camera) inthe robotic system from a given catalog, and we formulatethe co-design as the combinatorial selection of modules thatmaximize performance while satisfying given system-leveland module-level constraints. In Sec. II-A we introduce ourabstraction of the modules forming the overall robotic system.In Sec. II-B we describe the interactions among the modulesand how they contribute to the overall system performanceand resource utilization. In Sec. II-C we state the co-designproblem as a binary optimization problem.

A. Modules, Catalogs, Features

We consider the case in which the robotic system comprisesa given set of modules M. The modules may include, forinstance, the actuators, the sensors, the computational board,the perception algorithms, the control algorithms, the planningalgorithms, etc. For each module i ∈ M, we have a catalogCi of potential choices: for instance, we can purchase differentmotor models, or we can utilize different approaches andimplementations of a planning algorithm.

Design vector. The goal of the co-design is to select anelement j ∈ Ci (catalog for module i), for each module i ∈M.We can represent this selection using a binary vector xi foreach module, where the j-th entry of xi is 1 if we select thej-th element in the catalog Ci or zero otherwise. Clearly, xi ∈{0, 1}|Ci|, where |Ci| is the cardinality (number of elements)of the catalog. Therefore, the design is fully specified by thedesign vector x obtained by stacking xi for each i ∈M. Thedesign vector has size N .

=∑i∈M |Ci|, which we refer to as

the dimension of the design space.Feature matrix. Each module has a number of features

describing the technical specifications of the module. Forexample, the features of a motor may include the cost, torque,weight, maximum speed, power consumption, size of themotor, among other technical data. In general, the featuresare a list of properties one would find in the datasheet ofa component. Similarly, for an algorithm, the set of featuresmay include information about the expected performance andcomputational cost of the algorithm.

Clearly, each element in the catalog of module i (e.g.,different motor models) will have different values of eachfeature. We can thus succinctly describe the list of features foreach element in the catalog of module i as a feature matrix Fi,where each row correspond to a given feature, and differentcolumns correspond to different elements in the catalog. Forinstance, in a toy problem, we can have the following featurematrix for the motor module:

Fm =

W (1) W (2) W (3)

V (1) V (2) V (3)

A(1) A(2) A(3)

C(1) C(2) C(3)

T (1) T (2) T (3)

← weight← voltage← current← cost← torque

(1)

where the j-th column describes the features of the j elementin the motor catalog. In practice, the values in the matrix areknown from datasheet or from prior experiments.

Remark 1 (Beyond monotonicity): A way to relate our ap-proach (describing modules via catalogs and feature matrices)

to the one of Censi [13] is as follows. Censi splits what wecall features into resources and functionalities (imagine forinstance, that the first nr rows or (1) are labeled as “resources”and the last np as “functionalities”). Then, Censi assumesthat the columns of (1) satisfy the monotonicity property, i.e.,choices of components (columns) leading to better function-alities require more resources. This is not necessarily true inpractice: if we design a drone system, choosing a larger frame(i.e., consuming more resources) does not necessarily implythat our drone will fly faster (i.e., better functionality). We gobeyond [13] with two main innovations. First, the entries inour feature matrix (1) are completely arbitrary, hence relaxingthe monotonicity assumption. We will further highlight theimportance of relaxing monotonicity for multi-robot designin Sec. IV-B. Second, while resources and functionalities ofeach module may be problem-dependent, feature matrices aredesign-agnostic, as discussed in Remark 2 below.

Remark 2 (Feature matrices are design-agnostic): The no-tion of “module” and “feature matrix” are agnostic of the co-design problem, which is only defined in Sec. II-C. Indeed,the notion of “features” is general—the same modules canbe used in any co-design problem involving that module.This is in sharp contrast with [13], where the definitionof “resources” and “functionalities” (or “performance”) foreach module depends on the interactions between modules,hence it is problem-dependent. For instance: Fig. 21 in [13]classifies the battery capacity as a performance metric, butin other problems the battery capacity can be a resource. Ourchoice to create an intermediate abstraction, the feature matrix,resolves this dependence, enabling re-usability of modulesacross problems.

B. Design Specifications: Performance and Constraints

In a robotic system, the different modules interact to con-tribute to the overall performance of the system and potentiallyconsume resources. In particular, both the overall system aswell as each module require a minimum amount of resourcesto operate properly, thus imposing constraints on the design.

In this context, we distinguish three main design specifica-tions: system-level performance, system-level constraints, andmodule-level constraints. Intuitively, system-level performancedefines a set of metrics the co-design has to maximize, whilesystem-level (resp. module-level) constraints specify a set ofconstraints that need to be satisfied for the overall system (resp.each module) to operate correctly. These design specifications,which we discuss in more detail below, together with thecatalogs of the modules we want to design, fully specify theco-design problem (Section II-C).

Explicit specifications: system-level performance andconstraints. As an input to the co-design process, the userprovides a set of performance metrics the design must maxi-mize, as well as a set of constraints the overall system mustsatisfy. These specifications, which we refer to as explicitspecifications, are at the system level, in the sense that theydescribe the task that the system must perform.

System-level Performance. The system-level performance isa vector-value function of a choice of components. Recalling

4 PREPRINT VERSION.

that a design is fully characterized by the design vector x, thesystem-level performance is a function:

SP(x) : {0, 1}N 7→ RNp , (2)

where N is the dimension of the design space and Np isthe number of performance metrics the user specifies. Toclarify (2), let us consider a simple example, in which thedesign must maximize the torque of the wheel motors of anautonomous race car. In this case, the system-level perfor-mance is described by:

SP(x) = 4 [Fm]T xm (3)

In (3), Fm is the motor feature matrix in (1), xm is the designvector for the motor module, and [Fm]T extracts the row ofFm corresponding to the motor torque. The factor “4” capturesthe fact that, for simplicity, we assumed four wheels mountingidentical motors. We remark that the (linear) operator [·]Tselects the row corresponding to a specific feature from thefeature matrix, while the multiplication by xm has the effect ofselecting a single column (i.e., choosing a motor model) fromFm, due to the fact that xm has a single non-zero element.

System-level Constraints. The system-level constraints are(scalar) equality or inequality constraints, describing hard re-quirements on the desired behavior of the system or constraintson the resources that can be used for the design. We expresssystem-level constraints involving the design vector x:

SC(x)k ≤ 0 for k ∈ SC≤ (4)SC(x)k′ = 0 for k′ ∈ SC= (5)

where SC≤ and SC= are the sets of inequality and equalitysystem-level constraints, respectively. For instance, we canhave an upper bound on the overall cost of the design:∑i∈M

[Fi]C xi ≤ budget⇒ SC(x)k =∑i∈M

[Fi]C xi − budget

(6)where, as before, the linear operator [·]C extracts the cost fromthe feature matrix of each module i. Note that the “budget”must be provided by the user and it is specific to the designinstance, hence (6) is a system-level constraint.

An example of system-level equality constraint is the case inwhich the user wants to consider only a subset of elements inthe catalog (e.g., within a catalog of motors, only two motorsare available in-house). For instance, for the choice of modulei to be restricted to the subset Si ⊂ Ci, the user can add thefollowing system-level equality constraint:∑

j∈Si

[xi]j = 1 ⇒ SC(x)k′ =∑j∈Si

[xi]j − 1 (7)

where again [xi]j selects the j-th element of xi; the con-straint (7) enforces one element in Si to be chosen, due to thebinary nature of the vector xi.

Implicit specifications: module-level constraints. The usermust provide explicit specifications to describe what therobotic system is required to do within which operationalconstraints. On the other hand, implicit specifications aretransparent (or uninteresting) to the user and are only needed to

guarantee that each module has sufficient resources to functionas expected.

Similarly to the system-level performance, we expressmodule-level (implicit) constraints as inequality or equalityconstraints involving the design vector x:

IC(x)k ≤ 0 for k ∈ IC≤ (8)IC(x)k′ = 0 for k′ ∈ IC= (9)

where IC≤ and IC= are the sets of inequality and equalitymodule-level constraints, respectively. While the mathematicalnature of the system-level and module-level constraints issimilar, we believe it makes sense to distinguish them, sincethe user has control over system-level constraints (e.g., toincrease the design budget in (6)), while he/she typically doesnot have control over the implicit constraints.

For instance, the user cannot change the fact that, for thesystem to function properly, the onboard battery “b” has toprovide enough power for all the active modules (say, motors“m”, sensors “s”, and computing “c”), which indeed translatesinto an implicit inequality constraint:

AbVb ≥ AmVm +AsVs +AcVc ⇒IC(x)k =

∑i={m,s,c}

([Fi]Axi)([Fi]V xi)− ([Fb]Axb)([Fb]V xb)

(10)where Ai and Vi are the current and voltage at module i, andFi is again the feature matrix for module i.

Implicit constraints are also useful to model compatibilityconstraints, which, again, the user is not typically free to alter.For instance, we may want to model the fact that we cannotrun a certain algorithm (e.g., designed for FPGA) on a certainhardware (e.g., CPU), or we cannot use a LIDAR-based signalprocessing front-end to process data from a monocular camera.Compatibility constraints can be expressed as follows, for apair of modules “a” and “b”:

[xa]j ≤∑j′∈Sj

[xb]j′ (compatibility)

[xa]j ≤ 1−∑j′∈Sj

[xb]j′ (incompatibility) (11)

The first inequality in (11) imposes that, when the j-th elementin the catalog of module “a” is selected, we can only choosethe module b from the subset Sj (subset of compatible modulesin the catalog of b). The second inequality in (11) imposesthat, when the j-th element in the catalog of module “a” isselected, then we cannot choose the module b from the subsetSj (subset of incompatible modules in the catalog).

C. Co-design

The co-design problem can be now stated as follows.Definition 3 (Robot Co-design): Given the catalogs (and the

corresponding feature matrices Fi) for each module i ∈ Mto be designed, given the system-level performance functionSP(x) and the set of system-level inequality and equalityconstraints (SC≤,SC=), as well as the set of module-level

CARLONE AND PINCIROLI: GENERAL ROBOT CO-DESIGN 5

inequality and equality constraints (IC≤, IC=), robot co-design searches for the choice of modules M that maximizesthe system-level performance, while satisfying the constraints:

maxx∈X

SP(x) (12)

subject to SC(x)k ≤ 0 for k ∈ SC≤SC(x)k′ = 0 for k′ ∈ SC=IC(x)k ≤ 0 for k ∈ IC≤IC(x)k′ = 0 for k′ ∈ IC=

where X is the set of binary vectors that correspond tounique choices of each module (mathematically: X .

={{0, 1}N :

∑|Ci|j=1[xi]j = 1 for each module i ∈M}).

Problem (12) is a binary optimization problem, since thevector-variable x has binary entries. The formulation does nottake any assumption on the nature of the functions involved inthe objective function and the constraints. Our formulation isthis general and it does not assume monotonicity: indeed, byintroducing the notion of “feature matrix”, we circumventedthe problem of reasoning in terms of resources and function-ality of each module. As we will see, this framework allowsone to solve non-monotonic problems (see Sec. IV).

Remark 4 (Total Order): In general, the optimization prob-lem (12) is a multi-objective maximization, since the objectiveis vector-valued. While a major concern in [13] was how todeal with partially ordered sets (e.g., vectors), here we take amore pragmatic approach. In the formulation (12) we assumea total order for the vector in the objective, while we restrictedthe constraints to be scalar equalities and inequalities, henceworking on the totally ordered set of reals. In particular, weuse the lexicographical order to enforce a total order on avector space of performance vectors. In the lexicographicalorder two vectors y = [y1 y2 . . . yn] and z = [z1 z2 . . . zn]satisfy y ≤ z if an only if y1 ≤ z1, or y1 = z1 and y2 ≤ z2, ory1 = z1, y2 = z2 and y3 ≤ z3 etc. This order implies that theentries of the vector are sorted by “importance”. For instance,if we minimize a performance vector that includes [cost, size],then we search for the design that minimizes cost, and if twodesigns have the same cost, we prefer the design with smallersize. Note that we can also use the lexicographical order togeneralize the constraints to be vector-valued functions.

III. LINEAR CO-DESIGN SOLVERS

We now discuss several cases in which we can expectto solve Problem (12) in reasonable time using off-the-shelfoptimization tools. While Problem (12) is fairly general (wedid not take any assumptions on the functions involved in theobjective and the constraints), we do not expect to be able tosolve (12) globally and efficiently in general. Indeed, binaryoptimization is NP-hard and the computational cost of solvinga problem grows exponentially with its size [19].

Despite the intrinsic intractability of binary optimization,integer and binary programming algorithms keep improvingand modern implementations (e.g., IBM CPLEX [20]) arealready able to solve linear and quadratic binary optimizationproblems involving thousands of variables in reasonable time(i.e., seconds to few minutes). In our co-design problem, this

means that we can expect to solve problems with N = 2, 000(dimension of x) in seconds, which would be the case if wehave to design 10 modules, where each module catalog has200 potential choices (remember N .

=∑i∈M |Ci|).

The possibility of solving linear and quadratic binary opti-mization problems of interesting size in reasonable time mo-tivates use to investigate when we can expect to rephrase (12)as a linear or quadratic optimization problem (note: the answeris not as trivial as it might seem). In the rest of this sectionwe focus on the cases where we can rephrase (12) as a binarylinear program (BLP), since this already includes several casesof practical interest. Since the linearity of Problem (12) relieson the capability of expressing both the objective and theconstraints are linear functions, in the following we discusswhich type of functions we can expect to rephrase as linear.

(a) Linear functions. Choosing linear functions in theobjective and constraints would make (12) a BLP. Therefore,if the objective and the constraints in (12) have the followingform, then (12) is a BLP:

f(x) =∑i∈M

vTi xi + constant (13)

where vi is a known vector. We remark that most of theexamples in Section II-B, including (3), (6), (7), and (11),can be directly expressed in this form.

(b) Sum of nonlinear functions of a module. Under thesetup of Section II, we can express the sum of any nonlinearfunction involving a single module as a linear function.Consider for instance the following function:

f(x) =∑i∈M

fi(Fixi) (14)

where each function fi depends nonlinearly on the featuresof module i. We already observed that Fixi picks the j-thcolumn of the feature table Fi, where j is the only non-zeroentry in xi and is equal to 1. It is easy to show that:

fi(Fixi) = f̂i(Fi)xi (15)

where f̂i(Fi) denotes the (known) row vector obtained byapplying fi(·) column-wise to the matrix Fi:

f̂i(Fi).=[fi(F

(1)i ) fi(F

(2)i ) . . . fi(F

(|Ci|)i )

](16)

Using (15), we can rewrite (14) as:

f(x) =∑i∈M

f̂i(Fi)xi (17)

where f̂i(Fi) is a known vector. The expression (17) is nowlinear and has the same form as (13). Note that the “trick” (15)only holds since in our co-design problem each xi has a singlenon-zero entry equal to 1. As an example, (10) involves a sumof nonlinear functions of each module and so, according to ourdiscussion, it can be expressed as a linear constraint.

(c) Rational functions. We now show that we can express afamily of rational functions of the modules as linear functions.Let us start by considering the case in which the objectivefunction in (12) is a rational function in the following form:

f(x) =

∏i∈N fi(Fixi)∏i∈D fi(Fixi)

(18)

6 PREPRINT VERSION.

where N ⊆M and D ⊆M are arbitrary subsets of modules.Interestingly, it is possible to transform (18) into a linearfunction. For this purpose, we note that maximizing a quantityis the same as maximizing its logarithm, since the logarithmis a non-decreasing function. Therefore, we can replace theobjective function (18) with the equivalent objective:

f ′(x) = log

∏i∈N

fi(Fixi)∏i∈D

fi(Fixi)=∑i∈N

log fi(Fixi)−∑i∈D

log fi(Fixi)

(19)Now, we note that (19) is a sum of nonlinear functionsinvolving a single module, hence it can be simplified to thefollowing linear function:

f ′(x) =∑i∈N

log f̂i(Fi)xi −∑i∈D

log f̂i(Fi)xi (20)

The same approach can be applied to inequality (as well asequality) constraints in the following form (r̄ is a given scalar):∏

i∈N fi(Fixi)∏i∈D fi(Fixi)

≤ r̄ (21)

which can be reformulated as equivalent linear constraints.(d) Nonlinear functions of multiple modules. We conclude

this section by considering the more general case, in which wehave a non-linear function involving multiple modules. Forsimplicity of exposition, let us consider the case of a genericnon-linear function involving two modules “a” and “b”:

f(x) = f(xa,xb) (22)

When f(·) does not have a specific structure (as the cases dis-cussed above), it is still possible to obtain a linear expressionfor (22), but, as we will see, we will pay a price for this lackof structure. To express (22) as a linear function, we introducean extra variable, a matrix Zab which has size |Ca| × |Cb| andthat represents the joint choice of the modules “a” and “b”.In other words, Zab is zero everywhere and has a single entryequal to 1 in row ja and column jb, when we choose elementja for module “a” and element jb for module “b”. Clearly, thevariables Zab, xa, and xb are not independent and they haveto satisfy the following linear constraints:

Zab1 = xb , 1TZab = xa (23)

where 1 is a vector of ones of suitable dimension (Zab1returns the row-wise sum of the entries of Zab, while 1TZabreturns the column-wise sum). Intuitively, the constraints makesure that the matrix Zab and the vectors xa and xb encodethe same choice of components. By introducing the variableZab, we can write (22) as a linear function of Zab followingthe same ideas of case (b) discussed above. The price to payis an increase in the size of the optimization problem. In thegeneral case, in which more than 2 variables are involved in ageneric non-linear function, Z becomes a (sparse) tensor witha number of entries equal to

∏i∈N |Ci|, where N is the set of

modules involved in the (generic) non-linear transformation.When increasing the size of the optimization problem is

not an option, we can still use (12) and substitute non-linear

Fig. 2. Drone co-design overview: modules and features.functions with linear (or linearizable, as the cases above)surrogates. We show an example of this approach in Sec. IV-A.

IV. CODESIGN EXPERIMENTS

This section presents two examples of applications of theproposed co-design approach: Sec. IV-A focuses on the co-design of an autonomous racing drone, while Sec. IV-Bconsiders the co-design of a team of robots for collaborativetransportation. In both examples we use IBM CPLEX [20] tosolve the binary optimization program (12).

A. Autonomous Drone Co-design

This section applies the proposed co-design framework tothe problem of designing an autonomous micro aerial vehiclefor drone racing. In particular, we answer the question: what isthe best autonomous drone design we can obtain on a $1000budget, using components chosen from a given catalog?

Modules. The first step of the design process is to identifythe set of modulesM we want to design and prepare a catalogfor each module. In this example, we design five key modulesthat form an autonomous drone: motors, frame, computation,camera, and battery. For the motors, frame, and batteries, weselected real components that are commonly used for droneracing. In particular, we considered 17 candidate motors, 6candidate frames, and 12 candidate batteries. The websiteswe used to select those components (together with their costand their specs) as well as the actual numbers we used inthis example are available at https://bitbucket.org/lucacarlone/codesigncode/. For the camera and the computation, we tooka number of simplifying assumptions. For the camera, wedisregarded the choice of the lens and we defined a set of(realistic) candidate cameras, where, however, only a singleone is chosen from an actual catalog. For the design space ofthe “computation”, we actually considered the joint selectionof the computing board and the visual-inertial navigation(VIN) algorithm used for state estimation. Considering themas a single component has the advantage of allowing the useof statistics reported in other papers, e.g., stating that a VINalgorithm runs at a given framerate on a given computer [1].Therefore our modules are M .

= {m, f, s, c, b} (m = motors,f = frame, s = camera, c = computer, b = battery).

An overview of the modules we design and their corre-sponding features is given in Fig. 2. For the sake of simplicity,

CARLONE AND PINCIROLI: GENERAL ROBOT CO-DESIGN 7

in this toy example we preferred not to design other compo-nents. For instance, we disregarded other algorithms runningon the board, e.g., for control, which are typically less compu-tationally demanding. We also neglected the presence/designof voltage adapters and connectors, while we assumed thateach choice of motors comes with a suitable choice of ESC(Electronic Speed Control boards) and propellers.

System-level performance. The second step of the designprocess is to quantitatively define the system-level perfor-mance metrics (what is the “best drone”?). Since we consideran autonomous drone racing application, the best drone is onethat can complete a given track as quickly as possible, hencea system that can navigate at high speed. Therefore, in thisexample, the system performance metric is the top speed of thedrone. We mainly consider forward speed, but the presentationcan be extended to maximize agility and accelerations.

In order to derive an expression for the top (forward) speed,we observe Fig. 1(b) and note that at its top speed, the forwardacceleration is zero, hence the horizontal component Th of thethrust T must compensate the drag force (i) Th = D, and thevertical component Tv of the thrust must compensate the forceof gravity (ii) Tv = Fg = Mg, where M is the overall massof the drone and g is the acceleration due to gravity. Let usfocus on (i), and note that (iii) T 2 = T 2

h + T 2v and that the

drag can be modeled as (iv) D = 12ρcdAv

2, where ρ is the airdensity, cd is the drag coefficient (we take ρ = 1.2kg/m3 andcd = 1.3), A is the cross-sectional area, and v is the forwardspeed of the drone. Substituting (ii), (iii), and (iv) back into(i), we obtain:√

T 2 − (Mg)2 =1

2ρ cdAv

2max (24)

Now we note that the cross-sectional area can be approximatedas A = sin(β)`2 = Mg

T L2f , where β is the pitch angle (basic

trigonometry shows sin(β) = MgT ), and Lf is the length of the

frame (approximated as a square). Substituting this expressionfor A in (24) and rearranging the terms we obtain:

vmax =

(4T 2

ρ2c2dL4f

(T 2

(Mg)2− 1

)) 14

(25)

Finally, assuming that we design a quadrotor, the cumulativethrust is the sum of the thrusts Tm provided by each of thefour motors, while the mass is the sum of the weight Wi ofall the modules i ∈M:

vmax =

(4(4Tm)2

ρ2c2dL4f

((4Tm)2

(g∑i∈M ωiWi)2

− 1

)) 14

(SP)

where ωi = 4 if i = m (we have 4 motors on a quadrotor,each one weighting Wm), or ωi = 1 otherwise.

In order to make explicit that the values of Tm,Wi, Lfdepend on our design, we observe that Tm = [Fm]Txm,Wi = [Fi]Wxi Lf = [Ff]Lxf, which makes (SP) a functionof our design vector. Eq. (SP) represents the system per-formance metric our design has to maximize. It is apparentfrom (SP) that the design encourages drones which are smalland lightweight (Lf and Wi appear at the denominator) andwith large thrust (Tm appears at the numerator).

System-level constraints. System constraints provide fur-ther specifications (in the form of hard constraints) on the taskthe drone is designed for. For our drone example, we considertwo main constraints: monetary budget and flight time.1) Budget: Given a monetary budget b̄, the budget constraintenforces that the sum of the costs Ci of each module i iswithin the budget: ∑

i∈M ωiCi ≤ b̄ (SC1)

where again ωi = 4 if i = m or ωi = 1 otherwise.2) Flight time: Given a minimum flight time T̄ (this would bebetween 5-10 minutes in a real application), and calling Qbthe battery capacity, and Ai the average Ampere drawn by thei-th component (all assumed to operate at the same voltage),then the time it takes to drain the battery must be ≥ T̄ :

αQb∑i∈M ωiAi

≥ T̄ (SC2)

where ωi = 4 if i = m (again, we have 4 motors on a quadro-tor), or ωi = 1 otherwise; the constant α ∈ (0, 1] (typicallychosen to be around 0.8) models the fact that we might notwant to fully discharge our battery (e.g., LiPo batteries may bedamaged when discharged below a recommended threshold).

We remark that while flight time and budget constraintsalready make for an interesting problem, one can come up withmany more system constraints, e.g., size and weight limits toparticipate into a specific drone racing competition, or motorpower constraints for safety or regulatory constraints.

Implicit (module-level) constraints. The implicit con-straints make sure that each module can operate correctly andit is compatible with the other modules in the system. Weidentified five implicit constraints:1) Minimum thrust: the cumulative thrust provided by the fourmotors has to be sufficient for flight. Calling Tm the thrustprovided by each motor, and Wi the weight of the i-th module,the minimum thrust constraint can be written as:

4Tm ≥ r̄ g∑i∈M

ωiWi (IC1)

where r̄ is a given minimum thrust-weight ratio (r̄ = 2 in thisexample), to ensure that the thrust is sufficient to maneuverwith agility, besides allowing the drone to hover.2) Power: the battery should provide enough power to supportthe four motors, the camera, and the computer:

AbVb ≥ 4AmVm +AsVs +AcVc (IC2)

where Ai, Vi are the current and voltage for the i-th module.3) Size: all components should fit on the frame. Assuming wecan stack components on top of each other, the size constraintenforces that the size of each component should be smallerthan the size of the frame:

Lf ≥ Li with i ∈ {m, s, c, b} (IC3)

4) Minimum camera frame-rate: the framerate of the camerashould be fast enough to allow tracking visual features, duringfast motion. This is necessary for the visual-inertial navigation(VIN) algorithms to properly estimate position and attitude

8 PREPRINT VERSION.

0 0.5 1 1.5 2 2.5

design 104

0

20

40

60

80

100

120m

ax s

pe

ed

[m

/s]

(a)

0 0.5 1 1.5 2 2.5

design 104

0

500

1000

1500

2000

2500

3000

cost [$

]

(b)Fig. 3. (a) Estimated maximum speed and (b) cost for any potentialconfiguration of modules in our catalog. Infeasible designs are marked inred, while feasible designs are marked with a green star.

of the drone. Assuming that our VIN front-end can track afeature moving by at most δu pixels between frames, andcorresponding to the projection of a 3D point at distance dfrom the camera (we assume δu = 30 pixels, d = 5 meters),the frame-rate FPSs of the camera is bounded by [1]:

FPSs ≥fvmax

δud(IC4)

where f is the focal length of the camera, and vmax is themaximum speed of the drone, given in (SP).5) Minimum VIN frame-rate: the VIN algorithm operating onthe embedded computer on the drone should be able to processeach frame, hence the VIN frame-rate (recall that we selectfrom a catalog of VIN+computer combinations) must be largerthan the camera frame-rate:

FPSc ≥ FPSs (IC5)

Implementation and results. The “optimal” drone designsolves the following optimization problem:

maxx∈X (SP)subject to (SC1), (SC2)

(IC1), (IC2), (IC3), (IC4), (IC5)(26)

Most of the constraints are already in a form that is amenablefor our approach (Sec. III). Only the objective (SP) and theconstraints (SC2) and (IC4) have a more involved expression,which we further develop in the appendix, where we show howto approximate those expressions in a form that fit a linear co-design solver.

The optimal design we found in our implementation sug-gests that an optimal configuration of modules would include aStormer 220 FPV Racing Quadcopter Frame Kit, EMAX1045motors, an NVIDIA TX2 computer, a 60 frame-per-secondcamera, and a Tattu 5100mAh 3S 10C Battery Pack. The costof such a drone would be $700.84, and the drone would have aflight time of 10.42 minutes and a top speed of 35.52 metersper second, which is compatible with the performance oneexpects from a racing drone [21]. CPLEX was able to findan optimal design in 0.3 seconds. Since the design space isrelatively small we can compute the estimated maximum speedand the cost of every potential combination of the modulesin our catalog. These results are shown in Fig. 3, where wealso report whether the configuration is feasible (it satisfiedall system and implicit constraints) or not. The figure showsthat there are indeed only four feasible designs in our catalogall attaining fairly similar performance and cost.

B. Codesign of Heterogeneous Multi-Robot TeamsThis section applies the proposed framework to the co-

design of a heterogeneous multi-robot team. In particular,we consider a collective transport scenario, in which therobots must collectively carry a heavy object while avoidingobstacles. The robots must be configured to allow for efficientcarrying and for wide sensor coverage, while battery powerand frame size constrain the capabilities that any single robotpossesses. The end result of our design is a heterogeneousteam, composed of robots that specialize in carrying and robotsthat specialize in sensing. As a simplifying assumption, wefocus on objects and robots with circular shapes (see Fig. 4).

Modules. We consider four types of modules: frames (f),sensors (s), motors (m), and batteries (b). Frames’ featuresinclude size and weight; sensors’ features include coverage(as a percentage of the surrounding area), size, weight, andpower consumption; motors’ features include weight, size,power consumption and force exerted; and batteries’ featuresinclude size, weight, and power generated.

Since we have to design multiple robots, we use the notationxki to denote the design vector associated to the i-th moduleof robot k. As before, we use [xki ]j to denote the j-th entry ofxki . [xki ]j = 1 if we chose the j-th element in the catalog Ci ofmodule i on robot k, or zero otherwise. We let k ∈ {1, . . . ,K}where we calculate the upper bound K by considering themaximum number of robots that can encircle the object whenthe smallest frame is used. If the radius of the object is Robject

and the radius of the smallest frame is Rmin frame, then

K =

⌊π(Robject +Rmin frame)

Rmin frame

⌋. (27)

System-level performance. In a multi-robot system, per-formance is inherently non-monotonic. In Hamann’s analy-sis [15], performance is expressed as the ratio of two compo-nents: cooperation C(x) and interference I(x). Cooperationrefers to those phenomena that contribute to the task athand; interference corresponds to the phenomena that diminishthe system performance. A simple approach to capture bothaspects is to cast the co-design problem as an interferenceminimization problem, while using cooperation measures assystem constraints. In [15], I(x) is expressed as an exponentialthat decays with the size of the team R, from which it follows

minx∈X

I(x) ≡ minx∈X

eR(x) ≡ minx∈X

R(x) ≡ maxx∈X−R(x) (28)

where the symbol “≡” denotes that these changes of objectivedo not alter the solution of the optimization problem. In (28)we also observed that the team size is a function of our design(R = R(x)), i.e., the design algorithm can decide to use lessrobots than the upper bound (27). Eq. (28) shows that ourdesign will attempt to use the least number of robots, in orderto minimize interference. To capture R(x), we augment xwith a binary element (later called the “slot”) that indicateswhether the features of a robot k are being used or not (inother words: if the robot is part of the team of not). We canthus define R(x) =

∑Kk=1 x

kslot and write

SP(x) = −∑Kk=1 x

kslot. (SP)

CARLONE AND PINCIROLI: GENERAL ROBOT CO-DESIGN 9

TABLE IIMPLICIT CONSTRAINTS FOR THE MULTI-ROBOT CO-DESIGN EXAMPLE.

Meaning Formalization TagIf a slot is activated, therobot has one frame ∀k xk

slot =∑

j∈Cf[xk

f ]j (IC1)

If a slot is activated, therobot has one motor ∀k xk

slot =∑

j∈Cm[xk

m]j (IC2)

If a slot is activated, therobot has one battery ∀k xk

slot =∑

j∈Cb[xk

b ]j (IC3)

If a slot is activated, therobot has at most one sensor ∀k xk

slot ≥∑

j∈Cs[xk

s ]j (IC4)

The power consumption ofa robot is lower than thepower given by the battery

∀k∑

j∈CbPb,j [x

kb ]j ≥∑

i∈{m,s},j∈CiPi,j [x

ki ]j

(IC5)

The total size of the com-ponents of a robot is lowerthan the size of the chassis

∀k∑

j∈CfAf,j [x

kf ]j ≥∑

i∈{m,s,b},j∈CiAi,j [x

ki ]j

(IC6)

1110˚ 2 120˚10 kg 1120˚ 1 120˚80 kg

Fig. 4. Collective transport example (top view), where multiple robots (graycircles) carry a large object (black circle). The figure shows two solutionsfound by CPLEX when the object weighs 10 kg (left) and 80 kg (right).

System-level constraints. We consider two families ofsystem constraints concerning motors and sensing.1) Push for object transportation: the team as a whole mustbe able to carry the object; this is essentially the cooperationmeasure mentioned above. For this, we need that the pushPj exerted by the choice of motor j exceeds the sum of theweights Wi,j of each choice modules (i ∈ M and j ∈ Ci)plus the weight W of the object to transport:∑

k∈{1,...,K},j∈Cm

Pj [xkm]j ≥

∑k∈{1,...,K},i∈M,j∈Ci

Wi,j [xki ]j +W (SC1)

In addition, each robot’s motor push must exceed the weightof the robot itself:∑j∈Cm

Pj [xkm]j ≥

∑i∈M,j∈Ci

Wi,j [xki ]j ∀k ∈ {1, . . . ,K} (SC2)

2) Sensor coverage: the robot sensors must ensure that at least50% of the area around the object is covered at any time:∑

j∈Cs

Sj [xks ]j ≥ 50% (SC3)

where Sj is the coverage provided by the j-th sensor choice.Implicit (module-level) constraints. Table I summarizes

the implicit constraints in our example. The symbol Pi,jdenotes the power offered by battery j or used by the j-thchoice of module i. Ai,j denotes the area offered by a framej or the area used by the j-th choice of module i.

Implementation and results. To form the catalog of pos-sible modules, we considered 10 alternatives for each typeof module and 2 alternatives for the size of the robot frame,for a total of 2, 000 combinations. Using the size and weightof the object to transport, we explored the space of optimalsolutions, which involved teams of up to K = 65 robots. Fig. 4reports the solutions we found by solving two instances ofthe problem, where the object to carry weighted 10 kg and80 kg, respectively. In the left diagram, CPLEX concluded

that two large robots are sufficient to carry a 10 kg object.The robots are equipped with identical motors and batteries,and differ only in their sensor coverage. In the right diagram,CPLEX generated a solution including two types of robots:the larger type offers a lower pushing margin, but is capableof wide sensing; the smaller type is lighter and offers a higherpushing margin, but it performs no sensing. The presenceof robots that carry no sensors allows them to collectivelyshoulder the bulk of the pushing. The interested reader canfind the complete CPLEX implementation at https://bitbucket.org/lucacarlone/codesigncode/.

V. CONCLUSION

We presented an approach for computational robot co-design that formulates the joint selection of the modulescomposing a robotic system in terms of mathematical pro-gramming. While our approach is rooted in the general contextof binary optimization, we discussed a number of properties—specific to our co-design problem—that allow rephrasing sev-eral co-design problems including non-linear functions of thefeatures of each module in terms of binary linear programming(BLP). Modern BLP algorithms and implementations cansolve problems with few thousands of variables in seconds,which in turn allows attacking interesting co-design problems.We demonstrated the proposed co-design approach in twoapplications: the design of an autonomous drone and thedesign of a multi-robot team for collective transportation.Future work includes extending the set of functions for whichwe can solve the co-design problem in practice, and addingcontinuous variables (e.g., wing length, 3D-printed frame size)as part of the co-design problem.

APPENDIX

A. Drone Co-design

This section discusses how to approximate the objec-tive (SP) and the constraints (SC2) and (IC4) using binarylinear functions. The following paragraphs deal with each case.

A linear lower bound for the objective (SP). The de-sign has to maximize the maximum forward speed, which,from (SP), has the following expression:

vmax =

(4(4Tm)2

ρ2c2dL4f

((4Tm)2

(g∑i∈M ωiWi)2

− 1

)) 14

(29)

This expression does not fall in cases (a), (b), (c) in Section III;moreover, it involves all modules, hence taking the approach(d) of Section III would be impractical (it would simplylead to enumerating every possible design choice, implyinga combinatorial explosion of the state space).

The approach we take in this section is to approximateProblem (26) by replacing its objective with a linear lowerbound. We remark that, as shown in Section III, while thedesign is required to be linear in x, it can be heavily nonlinearin the features Fi. In the following we show how to obtaina linear lower bound for (29). For this purpose, we observe

10 PREPRINT VERSION.

that from (IC1), the thrust-weight ratio must be larger than r̄,hence (4Tm)/(g

∑i∈M ωiWi) ≥ r̄. Therefore, it holds:

vmax =

(4(4Tm)2

ρ2c2dL4f

((4Tm)2

(g∑i∈M ωiWi)2

− 1

)) 14

≥(

4(4Tm)2

ρ2c2dL4f

(r̄2 − 1

)) 14

= κT

12

m

Lf= κ

([Fm]T xm)12

[Ff]Lxf(30)

where κ is a constant, irrelevant for the maximization. Thefunction (30) now falls in the case (c) discussed in Section IIIand can be made linear in x by taking the logarithm.

A conservative linear approximation for (IC4). Similarlyto the case discussed above, we approximate the “problematic”constraints via surrogates that are linear in x.

The approach we take is to substitute a constraint in the formf(x) ≤ 0 with a linear constraint f̂(x) ≤ 0, where f(x) ≤f̂(x) for any x ∈ X . This guarantees that for any x thatmakes f̂(x) ≤ 0, then also f(x) ≤ 0, i.e., we still guarantee tocompute feasible (but potentially more conservative) designs.

Therefore, in the following we show how to obtain a linearupper bound for (IC4). Let us start by writing (IC4) moreexplicitly, by substituting vmax from (9):

FPSs ≥f

δud

(4(4Tm)2

ρ2c2dL4f

((4Tm)2

(g∑i∈M ωiWi)2

− 1

)) 14

(31)

or equivalently (taking the 4-th power of each member):

FPS4s ≥

4f4

δ4ud4ρ2c2d

(4Tm)2

L4f

((4Tm)2

(g∑i∈M ωiWi)2

− 1

)(32)

Taking the logarithm of both sides we obtain:

4 log(FPSs) ≥ β + 2 log(4Tm)− 4 log(Lf) +

+ log

((4Tm)2

(g∑i∈M ωiWi)2

− 1

)(33)

where we defined the constant β .= log( 4f4

δ4ud4ρ2c2d

).

Rearranging the terms:

2 log(4Tm)− 4 log(Lf) +

+ log

((4Tm)2

(g∑i∈M ωiWi)2

− 1

)− 4 log(FPSs) + β ≤ 0 (34)

We note that so far we did not take any approximation sinceeach operation we applied (4-th power, logarithm, reordering)preserves the original inequality. Moreover, (34) is in the formf(x) ≤ 0. In the rest of this paragraph, we show how to

compute a linearized upper bound for f(x). For this purposewe note that the following chain of inequalities holds:

2 log(4Tm)− 4 log(Lf) +

+ log

((4Tm)2

(g∑i∈M ωiWi)2

− 1

)− 4 log(FPSs) + β

(i)

≤

2 log(4Tm)− 4 log(Lf) +

+ log

((4Tm)2

(g∑i∈M ωiWi)2

)− 4 log(FPSs) + β

(ii)=

4 log(4Tm)− 4 log(Lf) +

−2 log

(∑i∈M

g ωiWi

)− 4 log(FPSs) + β

(iii)

≤

4 log(4Tm)− 4 log(Lf) +

−2∑i∈M

1

|M|log (g ωiWi)−2 log(|M|)−4 log(FPSs) + β (35)

where in (i) we dropped the −1 and used the fact that thelogarithm is a non-decreasing function, in (ii) we simplydeveloped the logarithm of the ratio, and in (iii) we used theJensen’s inequality:

log

(∑ni=1 yin

)≥∑ni=1 log(yi)

n⇐⇒ (36)

log

(n∑i=1

yi

)≥

n∑i=1

1

nlog(yi) + log(n) (37)

which holds for any integer n and positive scalar yi.Making the dependence of Tm, Lf, Wi, and FPSs on the

design vector x explicit in (35), we obtain:

f̂(x).= 4 log(4[Fm]Txm)− 4 log([Ff]Lxf) +

−2∑i∈M

1

|M|log (g ωi [Fi]Wxi) +

−2 log(|M|)− 4 log([Fs]FPSxs) + β (38)

which now falls in the case (b) discussed in Section III andcan be easily made linear with respect to x.

A conservative linear approximation for (SC2). Similarlyto the previous section, here we approximate the “problematic”constraint (SC2) via surrogates that are linear in x. In particu-lar, as before, we substitute a constraint in the form f(x) ≤ 0with a linear constraint f̂(x) ≤ 0, where f(x) ≤ f̂(x) for anyx ∈ X . This guarantees that for any x that makes f̂(x) ≤ 0,then also f(x) ≤ 0, i.e., we still guarantee to compute feasible(but potentially more conservative) designs.

Let us start by reporting the original expression we want toapproximate (SC2):

αQb∑i∈M ωiAi

≥ T̄ (39)

which, again, does not fall in cases (a), (b), (c) in Section III,and involves all modules, hence making the approach de-scribed in case (d) of Section III impractical.

In order to obtain a conservative approximation of theconstraint (39), we first take the logarithm of both members:

log(αQb)− log

(∑i∈M

ωiAi

)≥ log(T̄ ) (40)

CARLONE AND PINCIROLI: GENERAL ROBOT CO-DESIGN 11

which does not alter the inequality since all involved quantitiesare positive. Rearranging the terms:

log

(∑i∈M

ωiAi

)− log(αQb) + log(T̄ ) ≤ 0 (41)

We can find an upper bound for the left-hand-side of (41) asfollows:

log

(∑i∈M

ωiAi

)− log(αQb) + log(T̄ ) ≤

log(6Am)− log(αQb) + log(T̄ ) (42)

where we used∑i∈M ωiAi = As + Ac + 4Am ≤ 6Am

(note: frame and batteries are assumed to draw zero current)which follows from the fact the motors are the modules thatdraw more current. Therefore we can substitute the originalconstraint (39) with a conservative linear approximation:

f̂(x).= log(6[Fm]Axm)− log(α[Fb]Qxb) + log(T̄ ) ≤ 0 (43)

which now falls in the case (b) discussed in Section III andcan be easily made linear with respect to x.

REFERENCES

[1] Z. Zhang, A. Suleiman, L. Carlone, V. Sze, and S. Karaman, “Visual-inertial odometry on chip: An algorithm-and-hardware co-design ap-proach,” in Robotics: Science and Systems (RSS), 2017.

[2] NVIDIA, “Nvidia jetson tx2 module specifications.” [Online]. Available:https://developer.nvidia.com/embedded/buy/jetson-tx2

[3] D. Lipinski and K. Mohseni, “Feasible area coverage of a hurricaneusing micro-aerial vehicles,” in AIAA Scitech, 2014, pp. 824–829.

[4] H. Lipson and J. B. Pollack, “Automatic design and manufacture ofrobotic lifeforms,” Nature, vol. 406, no. 6799, pp. 974–978, Aug. 2000.

[5] H. Lipson, V. Sunspiral, J. Bongard, and N. Cheney, “On the difficultyof co-optimizing morphology and control in evolved virtual creatures,”in Proceedings of the European Conference on Artificial Life 13. MITPress, 2016, pp. 226–233.

[6] N. Cheney, J. Bongard, V. SunSpiral, and H. Lipson, “Scalable co-optimization of morphology and control in embodied machines,” Journalof The Royal Society Interface, vol. 15, no. 143, p. 20170937, June 2018.

[7] P. H. Chou, R. B. Ortega, and G. Borriello, “The Chinook Hard-ware/Software Co-synthesis System,” in Proceedings of the 8th Interna-tional Symposium on System Synthesis, ser. ISSS ’95. New York, NY,USA: ACM, 1995, pp. 22–27.

[8] B. C. Schafer and K. Wakabayashi, “Divide and Conquer High-levelSynthesis Design Space Exploration,” ACM Trans. Des. Autom. Electron.Syst., vol. 17, no. 3, pp. 29:1–29:19, July 2012.

[9] “Architecture Analysis and Design Language.” [Online]. Available:http://www.aadl.info/aadl/currentsite/

[10] A. Mehta, J. DelPreto, and D. Rus, “Integrated Codesign of PrintableRobots,” Journal of Mechanisms and Robotics, vol. 7, no. 2, pp.021 015–021 015–10, May 2015.

[11] O. Hussien, A. Ames, and P. Tabuada, “Abstracting Partially FeedbackLinearizable Systems Compositionally,” IEEE Control Systems Letters,vol. 1, no. 2, pp. 227–232, Oct. 2017.

[12] E. S. Kim, M. Arcak, and M. Zamani, “Constructing Control SystemAbstractions from Modular Components,” in Proceedings of the 21stInternational Conference on Hybrid Systems: Computation and Control(Part of CPS Week), ser. HSCC ’18. New York, NY, USA: ACM, 2018,pp. 137–146.

[13] A. Censi, “A Mathematical Theory of Co-Design,” arXiv:1512.08055[cs, math], Dec. 2015, arXiv: 1512.08055.

[14] ——, “A Class of Co-Design Problems With Cyclic Constraints andTheir Solution,” IEEE Robotics and Automation Letters, vol. 2, no. 1,pp. 96–103, Jan. 2017.

[15] H. Hamann, “Towards Swarm Calculus: Universal Properties of SwarmPerformance and Collective Decisions,” in Swarm Intelligence, D. e. a.Hutchison, Ed. Berlin, Heidelberg: Springer Berlin Heidelberg, 2012,vol. 7461, pp. 168–179.

[16] A. Kushleyev, D. Mellinger, C. Powers, and V. Kumar, “Towards aswarm of agile micro quadrotors,” Autonomous Robots, vol. 35, no. 4,pp. 287–300, 2013.

[17] V. Trianni, Evolutionary Swarm Robotics - Evolving Self-Organising Be-haviours in Groups of Autonomous Robots, ser. Studies in ComputationalIntelligence. Springer, 2008, vol. 108.

[18] G. Francesca, M. Brambilla, A. Brutschy, L. Garattoni, R. Miletitch,G. Podevijn, A. Reina, T. Soleymani, M. Salvaro, C. Pinciroli, F. Mascia,V. Trianni, and M. Birattari, “AutoMoDe-Chocolate: automatic designof control software for robot swarms,” Swarm Intelligence, vol. 9, no. 2,pp. 125–152, Sept. 2015.

[19] A. Schrijver, Theory of Linear and Integer Programming. New York,NY, USA: John Wiley & Sons, Inc., 1986.

[20] IBM, “CPLEX: IBM ILOG CPLEX Optimiz Studio.” [Online]. Avail-able: https://www.ibm.com/products/ilog-cplex-optimization-studio

[21] FPV Drone Reviews, “Fastest FPV drones,https://fpvdronereviews.com/guides/fastest-racing-drones/,” 2017.