I Introduction
Recent advances in sensor design and rapid prototyping are enabling the manufacturing of lowcost robots with advanced sensing and perception capabilities. For instance, one can implement highprecision visualinertial navigation with inexpensive camera and MEMS inertial measurement units [1]. Similarly, modern embedded CPUGPU [2] offer highperformance computing in a compact formfactor and at a relatively affordable cost. These trends, together with the availability of lowcost micromotors are enabling fast and cheap production of robotic platforms. In these cases, the most expensive resource becomes the effort of the expert human designers who are in charge of designing all the aspects of the robotic platform, including hardware and software. While this solution is still acceptable in the case where lowcost robots must be produced in volumes (e.g., vacuum cleaning robots), it may not be desirable when only few robots need to be deployed. Consider, for instance, the design of a drone for 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 timesensitive mission. For instance, one may need to design a searchandrescue robot tailored to a specific mission (e.g., search for survivors in a narrow cave with a given size of the entry point). Finally, human design does not necessarily lead to optimal solutions. Designers typically consider different robotics modules in isolation in order to tame the design complexity, and such decoupling usually leads to suboptimal performance.
These reasons motivate us to investigate computational robot codesign, which aims to create an automatic algorithm that 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 of the resulting design). Here the term “computational” refers to the fact that the design techniques can be implemented on a machine, and require minimal human intervention. Moreover, the term “codesign” refers to the attempt to consider the robotic system as a whole, rather than (suboptimally) decoupling the design of each module.
Related Work. The problem of codesign in robotics touches a wide span of research topics. In the most general sense, it can be considered as the problem of designing both the mind (software) and the body (hardware) of the robot at the same time. A few seminal works tackle this problem from an evolutionary standpoint [4, 5, 6], with approaches that aim to either optimize specific behaviors (e.g., walking) or to explore catalogs of possible solutions to a general problem (e.g., locomotion). While related to the problem of computational codesign as discussed above, these approaches typically abstract away several practical aspects of hardware design, such as power consumption and material selection.
At the opposite side of the spectrum, a large body of work on software/hardware design exists in the embedded systems community, e.g. FPGA and ASIC design [1]. In this domain, the focus is on the synthesis of practical solutions that explicitly consider lowlevel aspects such as power optimization and realtime scheduling in electronic devices. Since Chinook [7], a highly influential early approach, the field of software/hardware codesign has flourished, reaching relevant applications in safetycritical fields such as the aerospace [8] and automotive industry. The inception of domainspecific languages such as the Architecture Analysis and Design Language (AADL) [9] has enabled a systemsofsystems approach in which codesign can be coupled with a wide array of tools for property 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 lowlevel embedded system design with highlevel functionality specifications. In modular robotics, the challenge is to create a diverse set of composable, programmable modules that can be used to form robots with different capabilities. The recent, rapid development of 3D printing is offering increasingly powerful tools to streamline the automatic design of robotic platforms, and will arguably foster the development of modular robotics. In a seminal paper, Mehta et al. [10] demonstrate the feasibility of a procedure that takes a highlevel humandefined specification of a robot and outputs the 3D description files of the components, along with instructions to assemble the robot, manufacture the electronics, and automatically generate the control firmware. To the best of our knowledge, no work exists in the automatic generation of specifications that can be input to this system.
A core issue in computational codesign is the conception of a suitable formalism to express the design problem. Ideally, an effective formalism for automatic design should combine adequate granularity along with guarantees of correctness. Evolutionary methods [4, 5, 6]
combine a lowlevel parametric representation, such as rigid bodies connected by joints or voxelbased artifacts, with neural networkbased control. The main issue of this representation is the amount of detail involved in the optimization process, which limits scalability, and the absence of correctness guarantees. Other formalisms closer to the human design process, such as the one from Mehta
et al. [10] and AADL [9], achieve expressive power by naturally incorporating modularity. Both languages represent a codesign problem as a tree composed of heterogenous nodes which represent hardware and software aspects of a robot. AADL, in particular, offers a set of tools specifically designed for early analysis of candidate solutions, but without support for automatic exploration of the solution space. Correctbydesign compositional approaches have also been the focus of recent studies in control theory. For instance, Hussien et al. [11] proposed an automatic method to decompose a large control problem into a cascade of simpler problem, under the assumption that the latter are feedback linearizable, while Kim et al. [12] devised a method to arbitrarily construct system abstractions from simpler, wellposed components. Lastly, Censi [13, 14] proposed a powerful codesign approach that enables the automatic generation of solutions from a specification that includes recursive constraints. Censi’s approach assumes that a monotone mapping between resources and performance exists, thus casting computational codesign as a fixedpoint problem in the solution space.Contribution. This paper builds on recent work by Censi [13, 14] and pushes the boundary of computational codesign by relaxing its monotonicity assumption. Monotonicity implies that investing more resources leads to an increase in the performance. However, it is easy to find interesting examples for which this property does not hold. For instance, in the design if a drone frame, the fact that we increase the size of the frame (resource) does not imply that the drone will fly faster (performance). Similarly, in a collaborative transportation problem, deploying a larger number of robots (resources) does not necessarily lead to an increase in the overall performance of the system [15].
This paper presents a more general computational codesign approach. Our problem formulation is presented in Sec. II
, where we discuss the characterization of the design space and classify the design specifications in terms of
systemlevel performance, systemlevel constraints, and intrinsic constraints. Sec. IICrephrases the resulting codesign problem in terms of a binary optimization problem, where each binary variable indicates whether a given component is chosen as part of the design or not. Sec.
III discusses in which case we can expect to be able to solve the binary optimization problem using offtheshelf optimization tools; in general, binary optimization is intractable, but there exist several algorithms and implementations that are able to solve moderatesized problems efficiently as long as some property (e.g., linearity) holds. We show that our approach allows recasting several functions that are nonlinear in the properties (or features) of the robotic modules as linear functions. The proposed optimization framework also makes it possible to model other constraints found in practice, such as compatibility constraints (e.g., we cannot use a LIDARbased algorithm to process data from a monocular camera), which was beyond reach for existing methods [13].We conclude the paper by presenting two applications of the proposed codesign approach to the design of an autonomous drone racing platform and a multirobot system. These examples are presented in Sec. IV. Drone design is an interesting topic per se, and has already received attention in the literature [16, 1], which however still lacks a computational design approach. New and untapped challenges arise in the codesign of multirobot systems. We are not aware of approaches that specifically tackle this problem; however, a vast literature exist on the automatic generation of control systems for robots swarms, including evolutionary methods [17] and automatic generation of composable control structures [18].
Ii General Robot Codesign
The codesign problem consists in jointly designing robot software and hardware components to maximize taskdependent performance metrics (e.g., endurance, agility, payload) subject to constraints on the available resources (e.g., cost). The complexity of the problems stems from the fact that a robotic system involves an intertwining of modules. Each module contributes to the overall performance of the system while potentially consuming resources. In this paper, we consider the realistic case in which we have to choose each module (e.g., motor, embedded computer, camera) in the robotic system from a given catalog, and we formulate the codesign as the combinatorial selection of modules that maximize performance while satisfying given systemlevel and modulelevel constraints. In Sec. IIA we introduce our abstraction of the modules forming the overall robotic system. In Sec. IIB we describe the interactions among the modules and how they contribute to the overall system performance and resource utilization. In Sec. IIC we state the codesign problem as a binary optimization problem.
Iia Modules, Catalogs, Features
We consider the case in which the robotic system comprises a given set of modules . The modules may include, for instance, the actuators, the sensors, the computational board, the perception algorithms, the control algorithms, the planning algorithms, etc. For each module , we have a catalog of potential choices: for instance, we can purchase different motor models, or we can utilize different approaches and implementations of a planning algorithm.
Design vector. The goal of the codesign is to select an element (catalog for module ), for each module
. We can represent this selection using a binary vector
for each module, where the th entry of is 1 if we select the th element in the catalog or zero otherwise. Clearly, , where is the cardinality (number of elements) of the catalog. Therefore, the design is fully specified by the design vector obtained by stacking for each . The design vector has size , 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. For example, the features of a motor may include the cost, torque, weight, maximum speed, power consumption, size of the motor, among other technical data. In general, the features are a list of properties one would find in the datasheet of a component. Similarly, for an algorithm, the set of features may include information about the expected performance and computational cost of the algorithm.
Clearly, each element in the catalog of module (e.g., different motor models) will have different values of each feature. We can thus succinctly describe the list of features for each element in the catalog of module as a feature matrix , where each row correspond to a given feature, and different columns correspond to different elements in the catalog. For instance, in a toy problem, we can have the following feature matrix for the motor module:
(1) 
where the th column describes the features of the element in the motor catalog. In practice, the values in the matrix are known from datasheet or from prior experiments.
Remark 1 (Beyond monotonicity)
A way to relate our approach (describing modules via catalogs and feature matrices) to the one of Censi [13] is as follows. Censi splits what we call features into resources and functionalities (imagine for instance, that the first rows or (1) are labeled as “resources” and the last as “functionalities”). Then, Censi assumes that the columns of (1) satisfy the monotonicity property, i.e., choices of components (columns) leading to better functionalities require more resources. This is not necessarily true in practice: if we design a drone system, choosing a larger frame (i.e., consuming more resources) does not necessarily imply that our drone will fly faster (i.e., better functionality). We go beyond [13] with two main innovations. First, the entries in our feature matrix (1) are completely arbitrary, hence relaxing the monotonicity assumption. We will further highlight the importance of relaxing monotonicity for multirobot design in Sec. IVB. Second, while resources and functionalities of each module may be problemdependent, feature matrices are designagnostic, as discussed in Remark 2 below.
Remark 2 (Feature matrices are designagnostic)
The notion of “module” and “feature matrix” are agnostic of the codesign problem, which is only defined in Sec. IIC. Indeed, the notion of “features” is general—the same modules can be used in any codesign problem involving that module. This is in sharp contrast with [13], where the definition of “resources” and “functionalities” (or “performance”) for each module depends on the interactions between modules, hence it is problemdependent. For instance: Fig. 21 in [13] classifies the battery capacity as a performance metric, but in other problems the battery capacity can be a resource. Our choice to create an intermediate abstraction, the feature matrix, resolves this dependence, enabling reusability of modules across problems.
IiB Design Specifications: Performance and Constraints
In a robotic system, the different modules interact to contribute to the overall performance of the system and potentially consume resources. In particular, both the overall system as well as each module require a minimum amount of resources to operate properly, thus imposing constraints on the design.
In this context, we distinguish three main design specifications: systemlevel performance, systemlevel constraints, and modulelevel constraints. Intuitively, systemlevel performance defines a set of metrics the codesign has to maximize, while systemlevel (resp. modulelevel) constraints specify a set of constraints 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 the catalogs of the modules we want to design, fully specify the codesign problem (Section IIC).
Explicit specifications: systemlevel performance and constraints. As an input to the codesign process, the user provides a set of performance metrics the design must maximize, as well as a set of constraints the overall system must satisfy. These specifications, which we refer to as explicit specifications, are at the system level, in the sense that they describe the task that the system must perform.
Systemlevel Performance. The systemlevel performance is a vectorvalue function of a choice of components. Recalling that a design is fully characterized by the design vector , the systemlevel performance is a function:
(2) 
where is the dimension of the design space and is the number of performance metrics the user specifies. To clarify (2), let us consider a simple example, in which the design must maximize the torque of the wheel motors of an autonomous race car. In this case, the systemlevel performance is described by:
(3) 
In (3), is the motor feature matrix in (1), is the design vector for the motor module, and extracts the row of corresponding to the motor torque. The factor “4” captures the fact that, for simplicity, we assumed four wheels mounting identical motors. We remark that the (linear) operator selects the row corresponding to a specific feature from the feature matrix, while the multiplication by has the effect of selecting a single column (i.e., choosing a motor model) from , due to the fact that has a single nonzero element.
Systemlevel Constraints. The systemlevel constraints are (scalar) equality or inequality constraints, describing hard requirements on the desired behavior of the system or constraints on the resources that can be used for the design. We express systemlevel constraints involving the design vector :
(4)  
(5) 
where and are the sets of inequality and equality systemlevel constraints, respectively. For instance, we can have an upper bound on the overall cost of the design:
(6) 
where, as before, the linear operator extracts the cost from the feature matrix of each module . Note that the “budget” must be provided by the user and it is specific to the design instance, hence (6) is a systemlevel constraint.
An example of systemlevel equality constraint is the case in which the user wants to consider only a subset of elements in the catalog (e.g., within a catalog of motors, only two motors are available inhouse). For instance, for the choice of module to be restricted to the subset , the user can add the following systemlevel equality constraint:
(7) 
where again selects the th element of ; the constraint (7) enforces one element in to be chosen, due to the binary nature of the vector .
Implicit specifications: modulelevel constraints. The user must provide explicit specifications to describe what the robotic system is required to do within which operational constraints. On the other hand, implicit specifications are transparent (or uninteresting) to the user and are only needed to guarantee that each module has sufficient resources to function as expected.
Similarly to the systemlevel performance, we express modulelevel (implicit) constraints as inequality or equality constraints involving the design vector :
(8)  
(9) 
where and are the sets of inequality and equality modulelevel constraints, respectively. While the mathematical nature of the systemlevel and modulelevel constraints is similar, we believe it makes sense to distinguish them, since the user has control over systemlevel constraints (e.g., to increase the design budget in (6)), while he/she typically does not have control over the implicit constraints.
For instance, the user cannot change the fact that, for the system to function properly, the onboard battery “b” has to provide enough power for all the active modules (say, motors “m”, sensors “s”, and computing “c”), which indeed translates into an implicit inequality constraint:
(10) 
where and are the current and voltage at module , and is again the feature matrix for module .
Implicit constraints are also useful to model compatibility constraints, which, again, the user is not typically free to alter. For instance, we may want to model the fact that we cannot run a certain algorithm (e.g., designed for FPGA) on a certain hardware (e.g., CPU), or we cannot use a LIDARbased signal processing frontend to process data from a monocular camera. Compatibility constraints can be expressed as follows, for a pair of modules “a” and “b”:
(compatibility)  
(incompatibility)  (11) 
The first inequality in (11) imposes that, when the th element in the catalog of module “a” is selected, we can only choose the module from the subset (subset of compatible modules in the catalog of ). The second inequality in (11) imposes that, when the th element in the catalog of module “a” is selected, then we cannot choose the module from the subset (subset of incompatible modules in the catalog).
IiC Codesign
The codesign problem can be now stated as follows.
Definition 3 (Robot Codesign)
Given the catalogs (and the corresponding feature matrices ) for each module to be designed, given the systemlevel performance function and the set of systemlevel inequality and equality constraints (), as well as the set of modulelevel inequality and equality constraints (), robot codesign searches for the choice of modules that maximizes the systemlevel performance, while satisfying the constraints:
(12)  
subject to  
where is the set of binary vectors that correspond to unique choices of each module (mathematically: ).
Problem (12) is a binary optimization problem, since the vectorvariable has binary entries. The formulation does not take any assumption on the nature of the functions involved in the objective function and the constraints. Our formulation is this general and it does not assume monotonicity: indeed, by introducing the notion of “feature matrix”, we circumvented the problem of reasoning in terms of resources and functionality of each module. As we will see, this framework allows one to solve nonmonotonic problems (see Sec. IV).
Remark 4 (Total Order)
In general, the optimization problem (12) is a multiobjective maximization, since the objective is vectorvalued. While a major concern in [13] was how to deal with partially ordered sets (e.g., vectors), here we take a more pragmatic approach. In the formulation (12) we assume a total order for the vector in the objective, while we restricted the constraints to be scalar equalities and inequalities, hence working on the totally ordered set of reals. In particular, we use the lexicographical order to enforce a total order on a vector space of performance vectors. In the lexicographical order two vectors and satisfy if an only if , or and , or , and etc. This order implies that the entries of the vector are sorted by “importance”. For instance, if we minimize a performance vector that includes , then we search for the design that minimizes cost, and if two designs have the same cost, we prefer the design with smaller size. Note that we can also use the lexicographical order to generalize the constraints to be vectorvalued functions.
Iii Linear Codesign Solvers
We now discuss several cases in which we can expect to solve Problem (12) in reasonable time using offtheshelf optimization tools. While Problem (12) is fairly general (we did not take any assumptions on the functions involved in the objective and the constraints), we do not expect to be able to solve (12) globally and efficiently in general. Indeed, binary optimization is NPhard and the computational cost of solving a problem grows exponentially with its size [19].
Despite the intrinsic intractability of binary optimization, integer and binary programming algorithms keep improving and modern implementations (e.g., IBM CPLEX [20]) are already able to solve linear and quadratic binary optimization problems involving thousands of variables in reasonable time (i.e., seconds to few minutes). In our codesign problem, this means that we can expect to solve problems with (dimension of ) in seconds, which would be the case if we have to design modules, where each module catalog has potential choices (remember ).
The possibility of solving linear and quadratic binary optimization problems of interesting size in reasonable time motivates use to investigate when we can expect to rephrase (12) as a linear or quadratic optimization problem (note: the answer is not as trivial as it might seem). In the rest of this section we focus on the cases where we can rephrase (12) as a binary linear program (BLP), since this already includes several cases of practical interest. Since the linearity of Problem (12) relies on the capability of expressing both the objective and the constraints are linear functions, in the following we discuss which type of functions we can expect to rephrase as linear.
(a) Linear functions. Choosing linear functions in the objective and constraints would make (12) a BLP. Therefore, if the objective and the constraints in (12) have the following form, then (12) is a BLP:
(13) 
where is a known vector. We remark that most of the examples in Section IIB, including (3), (6), (7), and (11), can be directly expressed in this form.
(b) Sum of nonlinear functions of a module. Under the setup of Section II, we can express the sum of any nonlinear function involving a single module as a linear function. Consider for instance the following function:
(14) 
where each function depends nonlinearly on the features of module . We already observed that picks the th column of the feature table , where is the only nonzero entry in and is equal to . It is easy to show that:
(15) 
where denotes the (known) row vector obtained by applying columnwise to the matrix :
(16) 
Using (15), we can rewrite (14) as:
(17) 
where is a known vector. The expression (17) is now linear and has the same form as (13). Note that the “trick” (15) only holds since in our codesign problem each has a single nonzero entry equal to 1. As an example, (10) involves a sum of nonlinear functions of each module and so, according to our discussion, it can be expressed as a linear constraint.
(c) Rational functions. We now show that we can express a family of rational functions of the modules as linear functions. Let us start by considering the case in which the objective function in (12) is a rational function in the following form:
(18) 
where and are arbitrary subsets of modules. Interestingly, it is possible to transform (18) into a linear function. For this purpose, we note that maximizing a quantity is the same as maximizing its logarithm, since the logarithm is a nondecreasing function. Therefore, we can replace the objective function (18) with the equivalent objective:
(19) 
Now, we note that (19) is a sum of nonlinear functions involving a single module, hence it can be simplified to the following linear function:
(20) 
The same approach can be applied to inequality (as well as equality) constraints in the following form ( is a given scalar):
(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 we have a nonlinear function involving multiple modules. For simplicity of exposition, let us consider the case of a generic nonlinear function involving two modules “a” and “b”:
(22) 
When does not have a specific structure (as the cases discussed above), it is still possible to obtain a linear expression for (22), but, as we will see, we will pay a price for this lack of structure. To express (22) as a linear function, we introduce an extra variable, a matrix which has size and that represents the joint choice of the modules “a” and “b”. In other words, is zero everywhere and has a single entry equal to in row and column , when we choose element for module “a” and element for module “b”. Clearly, the variables , , and are not independent and they have to satisfy the following linear constraints:
(23) 
where is a vector of ones of suitable dimension ( returns the rowwise sum of the entries of , while returns the columnwise sum). Intuitively, the constraints make sure that the matrix and the vectors and encode the same choice of components. By introducing the variable , we can write (22) as a linear function of following the same ideas of case (b) discussed above. The price to pay is an increase in the size of the optimization problem. In the general case, in which more than 2 variables are involved in a generic nonlinear function,
becomes a (sparse) tensor with a number of entries equal to
, whereis the set of modules involved in the (generic) nonlinear transformation.
Iv Codesign Experiments
This section presents two examples of applications of the proposed codesign approach: Sec. IVA focuses on the codesign of an autonomous racing drone, while Sec. IVB considers the codesign of a team of robots for collaborative transportation. In both examples we use IBM CPLEX [20] to solve the binary optimization program (12).
Iva Autonomous Drone Codesign
This section applies the proposed codesign framework to the problem of designing an autonomous micro aerial vehicle for drone racing. In particular, we answer the question: what is the best autonomous drone design we can obtain on a $1000 budget, using components chosen from a given catalog?
Modules. The first step of the design process is to identify the set of modules we want to design and prepare a catalog for each module. In this example, we design five key modules that form an autonomous drone: motors, frame, computation, camera, and battery. For the motors, frame, and batteries, we selected real components that are commonly used for drone racing. In particular, we considered 17 candidate motors, 6 candidate frames, and 12 candidate batteries. The websites we used to select those components (together with their cost and their specs) as well as the actual numbers we used in this example are available at https://bitbucket.org/lucacarlone/codesigncode/
. For the camera and the computation, we took a number of simplifying assumptions. For the camera, we disregarded the choice of the lens and we defined a set of (realistic) candidate cameras, where, however, only a single one is chosen from an actual catalog. For the design space of the “computation”, we actually considered the joint selection of the computing board and the visualinertial navigation (VIN) algorithm used for state estimation. Considering them as a single component has the advantage of allowing the use of statistics reported in other papers, e.g., stating that a VIN algorithm runs at a given framerate on a given computer
[1]. Therefore our modules are ( motors, frame, camera, computer, battery).An overview of the modules we design and their corresponding features is given in Fig. 2. For the sake of simplicity, in this toy example we preferred not to design other components. For instance, we disregarded other algorithms running on the board, e.g., for control, which are typically less computationally demanding. We also neglected the presence/design of voltage adapters and connectors, while we assumed that each choice of motors comes with a suitable choice of ESC (Electronic Speed Control boards) and propellers.
Systemlevel performance. The second step of the design process is to quantitatively define the systemlevel performance metrics (what is the “best drone”?). Since we consider an autonomous drone racing application, the best drone is one that can complete a given track as quickly as possible, hence a system that can navigate at high speed. Therefore, in this example, the system performance metric is the top speed of the drone. We mainly consider forward speed, but the presentation can 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 forward acceleration is zero, hence the horizontal component of the thrust must compensate the drag force (i) , and the vertical component of the thrust must compensate the force of gravity (ii) , where is the overall mass of the drone and is the acceleration due to gravity. Let us focus on (i), and note that (iii) and that the drag can be modeled as (iv) , where is the air density, is the drag coefficient (we take and ), is the crosssectional area, and is the forward speed of the drone. Substituting (ii), (iii), and (iv) back into (i), we obtain:
(24) 
Now we note that the crosssectional area can be approximated as , where is the pitch angle (basic trigonometry shows ), and is the length of the frame (approximated as a square). Substituting this expression for in (24) and rearranging the terms we obtain:
(25) 
Finally, assuming that we design a quadrotor, the cumulative thrust is the sum of the thrusts provided by each of the four motors, while the mass is the sum of the weight of all the modules :
(SP) 
where if (we have 4 motors on a quadrotor, each one weighting ), or otherwise.
In order to make explicit that the values of depend on our design, we observe that , , which makes (SP) a function of our design vector. Eq. (SP) represents the system performance metric our design has to maximize. It is apparent from (SP) that the design encourages drones which are small and lightweight ( and appear at the denominator) and with large thrust ( appears at the numerator).
Systemlevel constraints. System constraints provide further specifications (in the form of hard constraints) on the task the drone is designed for. For our drone example, we consider two main constraints: monetary budget and flight time.

[wide, labelwidth=!, labelindent=0pt]

Budget: Given a monetary budget , the budget constraint enforces that the sum of the costs of each module is within the budget:
(SC1) where again if or otherwise.

Flight time: Given a minimum flight time (this would be between 510 minutes in a real application), and calling the battery capacity, and the average Ampere drawn by the th component (all assumed to operate at the same voltage), then the time it takes to drain the battery must be :
(SC2) where if (again, we have 4 motors on a quadrotor), or otherwise; the constant (typically chosen to be around ) models the fact that we might not want to fully discharge our battery (e.g., LiPo batteries may be damaged when discharged below a recommended threshold).
We remark that while flight time and budget constraints already make for an interesting problem, one can come up with many more system constraints, e.g., size and weight limits to participate into a specific drone racing competition, or motor power constraints for safety or regulatory constraints.
Implicit (modulelevel) constraints. The implicit constraints make sure that each module can operate correctly and it is compatible with the other modules in the system. We identified five implicit constraints:

[wide, labelwidth=!, labelindent=0pt]

Minimum thrust: the cumulative thrust provided by the four motors has to be sufficient for flight. Calling the thrust provided by each motor, and the weight of the th module, the minimum thrust constraint can be written as:
(IC1) where is a given minimum thrustweight ratio ( in this example), to ensure that the thrust is sufficient to maneuver with agility, besides allowing the drone to hover.

Power: the battery should provide enough power to support the four motors, the camera, and the computer:
(IC2) where are the current and voltage for the th module.

Size: all components should fit on the frame. Assuming we can stack components on top of each other, the size constraint enforces that the size of each component should be smaller than the size of the frame:
(IC3) 
Minimum camera framerate: the framerate of the camera should be fast enough to allow tracking visual features, during fast motion. This is necessary for the visualinertial navigation (VIN) algorithms to properly estimate position and attitude of the drone. Assuming that our VIN frontend can track a feature moving by at most pixels between frames, and corresponding to the projection of a 3D point at distance from the camera (we assume pixels, meters), the framerate of the camera is bounded by [1]:
(IC4) where is the focal length of the camera, and is the maximum speed of the drone, given in (SP).

Minimum VIN framerate: the VIN algorithm operating on the embedded computer on the drone should be able to process each frame, hence the VIN framerate (recall that we select from a catalog of VIN+computer combinations) must be larger than the camera framerate:
(IC5)
Implementation and results. The “optimal” drone design solves the following optimization problem:
(26) 
Most of the constraints are already in a form that is amenable for our approach (Sec. III). Only the objective (SP) and the constraints (SC2) and (IC4) have a more involved expression, which we further develop in the appendix, where we show how to approximate those expressions in a form that fit a linear codesign solver.
The optimal design we found in our implementation suggests that an optimal configuration of modules would include a Stormer 220 FPV Racing Quadcopter Frame Kit, EMAX1045 motors, an NVIDIA TX2 computer, a 60 framepersecond camera, and a Tattu 5100mAh 3S 10C Battery Pack. The cost of such a drone would be , and the drone would have a flight time of minutes and a top speed of meters per second, which is compatible with the performance one expects from a racing drone [21]. CPLEX was able to find an optimal design in seconds. Since the design space is relatively small we can compute the estimated maximum speed and the cost of every potential combination of the modules in our catalog. These results are shown in Fig. 3, where we also report whether the configuration is feasible (it satisfied all system and implicit constraints) or not. The figure shows that there are indeed only four feasible designs in our catalog all attaining fairly similar performance and cost.
IvB Codesign of Heterogeneous MultiRobot Teams
This section applies the proposed framework to the codesign of a heterogeneous multirobot team. In particular, we consider a collective transport scenario, in which the robots must collectively carry a heavy object while avoiding obstacles. The robots must be configured to allow for efficient carrying and for wide sensor coverage, while battery power and frame size constrain the capabilities that any single robot possesses. The end result of our design is a heterogeneous team, composed of robots that specialize in carrying and robots that specialize in sensing. As a simplifying assumption, we focus 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’ features include size and weight; sensors’ features include coverage (as a percentage of the surrounding area), size, weight, and power consumption; motors’ features include weight, size, power consumption and force exerted; and batteries’ features include size, weight, and power generated.
Since we have to design multiple robots, we use the notation to denote the design vector associated to the th module of robot . As before, we use to denote the th entry of . if we chose the th element in the catalog of module on robot , or zero otherwise. We let where we calculate the upper bound by considering the maximum number of robots that can encircle the object when the smallest frame is used. If the radius of the object is and the radius of the smallest frame is , then
(27) 
Systemlevel performance. In a multirobot system, performance is inherently nonmonotonic. In Hamann’s analysis [15], performance is expressed as the ratio of two components: cooperation and interference . Cooperation refers to those phenomena that contribute to the task at hand; interference corresponds to the phenomena that diminish the system performance. A simple approach to capture both aspects is to cast the codesign problem as an interference minimization problem, while using cooperation measures as system constraints. In [15], is expressed as an exponential that decays with the size of the team , from which it follows
(28) 
where the symbol “” denotes that these changes of objective do not alter the solution of the optimization problem. In (28) we also observed that the team size is a function of our design (), i.e., the design algorithm can decide to use less robots than the upper bound (27). Eq. (28) shows that our design will attempt to use the least number of robots, in order to minimize interference. To capture , we augment with a binary element (later called the “slot”) that indicates whether the features of a robot are being used or not (in other words: if the robot is part of the team of not). We can thus define and write
(SP) 
Systemlevel constraints. We consider two families of system constraints concerning motors and sensing.

[wide, labelwidth=!, labelindent=0pt]

Push for object transportation: the team as a whole must be able to carry the object; this is essentially the cooperation measure mentioned above. For this, we need that the push exerted by the choice of motor exceeds the sum of the weights of each choice modules ( and ) plus the weight of the object to transport:
(SC1) In addition, each robot’s motor push must exceed the weight of the robot itself:
(SC2) 
Sensor coverage: the robot sensors must ensure that at least 50% of the area around the object is covered at any time:
(SC3) where is the coverage provided by the th sensor choice.
Meaning  Formalization  Tag 

If a slot is activated, the robot has one frame  (IC1)  
If a slot is activated, the robot has one motor  (IC2)  
If a slot is activated, the robot has one battery  (IC3)  
If a slot is activated, the robot has at most one sensor  (IC4)  
The power consumption of a robot is lower than the power given by the battery  (IC5)  
The total size of the components of a robot is lower than the size of the chassis  (IC6) 
Implicit (modulelevel) constraints. Table I summarizes the implicit constraints in our example. The symbol denotes the power offered by battery or used by the th choice of module . denotes the area offered by a frame or the area used by the th choice of module .
Implementation and results. To form the catalog of possible modules, we considered 10 alternatives for each type of module and 2 alternatives for the size of the robot frame, for a total of combinations. Using the size and weight of the object to transport, we explored the space of optimal solutions, which involved teams of up to robots. Fig. 4 reports the solutions we found by solving two instances of the problem, where the object to carry weighted and , respectively. In the left diagram, CPLEX concluded that two large robots are sufficient to carry a 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 capable of wide sensing; the smaller type is lighter and offers a higher pushing margin, but it performs no sensing. The presence of robots that carry no sensors allows them to collectively shoulder the bulk of the pushing. The interested reader can find the complete CPLEX implementation at https://bitbucket.org/lucacarlone/codesigncode/.
V Conclusion
We presented an approach for computational robot codesign that formulates the joint selection of the modules composing a robotic system in terms of mathematical programming. While our approach is rooted in the general context of binary optimization, we discussed a number of properties—specific to our codesign problem—that allow rephrasing several codesign problems including nonlinear functions of the features of each module in terms of
binary linear programming
(BLP). Modern BLP algorithms and implementations can solve problems with few thousands of variables in seconds, which in turn allows attacking interesting codesign problems. We demonstrated the proposed codesign approach in two applications: the design of an autonomous drone and the design of a multirobot team for collective transportation. Future work includes extending the set of functions for which we can solve the codesign problem in practice, and adding continuous variables (e.g., wing length, 3Dprinted frame size) as part of the codesign problem.a Drone Codesign
This section discusses how to approximate the objective (SP) and the constraints (SC2) and (IC4) using binary linear functions. The following paragraphs deal with each case.
A linear lower bound for the objective (SP). The design has to maximize the maximum forward speed, which, from (SP), has the following expression:
(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 simply lead to enumerating every possible design choice, implying a combinatorial explosion of the state space).
The approach we take in this section is to approximate Problem (26) by replacing its objective with a linear lower bound. We remark that, as shown in Section III, while the design is required to be linear in , it can be heavily nonlinear in the features . In the following we show how to obtain a linear lower bound for (29). For this purpose, we observe that from (IC1), the thrustweight ratio must be larger than , hence . Therefore, it holds:
(30) 
where is a constant, irrelevant for the maximization. The function (30) now falls in the case (c) discussed in Section III and can be made linear in by taking the logarithm.
A conservative linear approximation for (IC4). Similarly to the case discussed above, we approximate the “problematic” constraints via surrogates that are linear in .
The approach we take is to substitute a constraint in the form with a linear constraint , where for any . This guarantees that for any that makes , then also , i.e., we still guarantee to compute feasible (but potentially more conservative) designs.
Therefore, in the following we show how to obtain a linear upper bound for (IC4). Let us start by writing (IC4) more explicitly, by substituting from (9):
(31) 
or equivalently (taking the th power of each member):
(32) 
Taking the logarithm of both sides we obtain:
(33) 
where we defined the constant .
Rearranging the terms:
(34) 
We note that so far we did not take any approximation since each operation we applied (th power, logarithm, reordering) preserves the original inequality. Moreover, (34) is in the form . In the rest of this paragraph, we show how to compute a linearized upper bound for . For this purpose we note that the following chain of inequalities holds:
(35) 
where in (i) we dropped the and used the fact that the logarithm is a nondecreasing function, in (ii) we simply developed the logarithm of the ratio, and in (iii) we used the Jensen’s inequality:
(36)  
(37) 
which holds for any integer and positive scalar .
Making the dependence of , , , and on the design vector explicit in (35), we obtain:
(38) 
which now falls in the case (b) discussed in Section III and can be easily made linear with respect to .
A conservative linear approximation for (SC2). Similarly to the previous section, here we approximate the “problematic” constraint (SC2) via surrogates that are linear in . In particular, as before, we substitute a constraint in the form with a linear constraint , where for any . This guarantees that for any that makes , then also , i.e., we still guarantee to compute feasible (but potentially more conservative) designs.
Let us start by reporting the original expression we want to approximate (SC2):
(39) 
which, again, does not fall in cases (a), (b), (c) in Section III, and involves all modules, hence making the approach described in case (d) of Section III impractical.
In order to obtain a conservative approximation of the constraint (39), we first take the logarithm of both members:
(40) 
which does not alter the inequality since all involved quantities are positive. Rearranging the terms:
(41) 
We can find an upper bound for the lefthandside of (41) as follows:
(42) 
where we used (note: frame and batteries are assumed to draw zero current) which follows from the fact the motors are the modules that draw more current. Therefore we can substitute the original constraint (39) with a conservative linear approximation:
(43) 
which now falls in the case (b) discussed in Section III and can be easily made linear with respect to .
References
 [1] Z. Zhang, A. Suleiman, L. Carlone, V. Sze, and S. Karaman, “Visualinertial odometry on chip: An algorithmandhardware codesign approach,” in Robotics: Science and Systems (RSS), 2017.
 [2] NVIDIA, “Nvidia jetson tx2 module specifications.” [Online]. Available: https://developer.nvidia.com/embedded/buy/jetsontx2
 [3] D. Lipinski and K. Mohseni, “Feasible area coverage of a hurricane using microaerial vehicles,” in AIAA Scitech, 2014, pp. 824–829.
 [4] H. Lipson and J. B. Pollack, “Automatic design and manufacture of robotic lifeforms,” Nature, vol. 406, no. 6799, pp. 974–978, Aug. 2000.
 [5] H. Lipson, V. Sunspiral, J. Bongard, and N. Cheney, “On the difficulty of cooptimizing morphology and control in evolved virtual creatures,” in Proceedings of the European Conference on Artificial Life 13. MIT Press, 2016, pp. 226–233.
 [6] N. Cheney, J. Bongard, V. SunSpiral, and H. Lipson, “Scalable cooptimization of morphology and control in embodied machines,” Journal of The Royal Society Interface, vol. 15, no. 143, p. 20170937, June 2018.
 [7] P. H. Chou, R. B. Ortega, and G. Borriello, “The Chinook Hardware/Software Cosynthesis System,” in Proceedings of the 8th International 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 Highlevel Synthesis 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 Printable Robots,” 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 Feedback Linearizable 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 System Abstractions from Modular Components,” in Proceedings of the 21st International 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 CoDesign,” arXiv:1512.08055 [cs, math], Dec. 2015, arXiv: 1512.08055.
 [14] ——, “A Class of CoDesign Problems With Cyclic Constraints and Their Solution,” IEEE Robotics and Automation Letters, vol. 2, no. 1, pp. 96–103, Jan. 2017.
 [15] H. Hamann, “Towards Swarm Calculus: Universal Properties of Swarm Performance 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 a swarm of agile micro quadrotors,” Autonomous Robots, vol. 35, no. 4, pp. 287–300, 2013.
 [17] V. Trianni, Evolutionary Swarm Robotics  Evolving SelfOrganising Behaviours in Groups of Autonomous Robots, ser. Studies in Computational Intelligence. 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, “AutoMoDeChocolate: automatic design of 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]. Available: https://www.ibm.com/products/ilogcplexoptimizationstudio
 [21] FPV Drone Reviews, “Fastest FPV drones, https://fpvdronereviews.com/guides/fastestracingdrones/,” 2017.
Comments
There are no comments yet.