text:
# American Institute of Mathematical Sciences

June  2016, 8(2): 179-197. doi: 10.3934/jgm.2016003

## Picard group of isotropic realizations of twisted Poisson manifolds

 1 Department of Mathematics, Cornell University, Ithaca, NY 14853, United States

Received  March 2015 Revised  December 2015 Published  June 2016

Let $B$ be a twisted Poisson manifold with a fixed tropical affine structure given by a period bundle $P$. In this paper, we study the classification of almost symplectically complete isotropic realizations (ASCIRs) over $B$ in the spirit of [10]. We construct a product among ASCIRs in analogy with tensor product of line bundles, thereby introducing the notion of the Picard group of $B$. We give descriptions of the Picard group in terms of exact sequences involving certain sheaf cohomology groups, and find that the `Néron-Severi group' is isomorphic to $H^2(B, \underline{P})$. An example of an ASCIR over a certain open subset of a compact Lie group is discussed.
Citation: Chi-Kwong Fok. Picard group of isotropic realizations of twisted Poisson manifolds. Journal of Geometric Mechanics, 2016, 8 (2) : 179-197. doi: 10.3934/jgm.2016003
##### References:

show all references

##### References:
 [1] Nicola Sansonetto, Daniele Sepe. Twisted isotropic realisations of twisted Poisson structures. Journal of Geometric Mechanics, 2013, 5 (2) : 233-256. doi: 10.3934/jgm.2013.5.233 [2] Jan J. Sławianowski, Vasyl Kovalchuk, Agnieszka Martens, Barbara Gołubowska, Ewa E. Rożko. Essential nonlinearity implied by symmetry group. Problems of affine invariance in mechanics and physics. Discrete & Continuous Dynamical Systems - B, 2012, 17 (2) : 699-733. doi: 10.3934/dcdsb.2012.17.699 [3] Michael Usher. Floer homology in disk bundles and symplectically twisted geodesic flows. Journal of Modern Dynamics, 2009, 3 (1) : 61-101. doi: 10.3934/jmd.2009.3.61 [4] Hongyan Guo. Automorphism group and twisted modules of the twisted Heisenberg-Virasoro vertex operator algebra. Electronic Research Archive, 2021, 29 (4) : 2673-2685. doi: 10.3934/era.2021008 [5] Terasan Niyomsataya, Ali Miri, Monica Nevins. Decoding affine reflection group codes with trellises. Advances in Mathematics of Communications, 2012, 6 (4) : 385-400. doi: 10.3934/amc.2012.6.385 [6] Frol Zapolsky. On almost Poisson commutativity in dimension two. Electronic Research Announcements, 2010, 17: 155-160. doi: 10.3934/era.2010.17.155 [7] Anna Maria Candela, J.L. Flores, M. Sánchez. A quadratic Bolza-type problem in a non-complete Riemannian manifold. Conference Publications, 2003, 2003 (Special) : 173-181. doi: 10.3934/proc.2003.2003.173 [8] Luis García-Naranjo. Reduction of almost Poisson brackets and Hamiltonization of the Chaplygin sphere. Discrete & Continuous Dynamical Systems - S, 2010, 3 (1) : 37-60. doi: 10.3934/dcdss.2010.3.37 [9] Carlos Matheus, Jean-Christophe Yoccoz. The action of the affine diffeomorphisms on the relative homology group of certain exceptionally symmetric origamis. Journal of Modern Dynamics, 2010, 4 (3) : 453-486. doi: 10.3934/jmd.2010.4.453 [10] Agust Sverrir Egilsson. On embedding the $1:1:2$ resonance space in a Poisson manifold. Electronic Research Announcements, 1995, 1: 48-56. [11] Marianito R. Rodrigo, Rogemar S. Mamon. Bond pricing formulas for Markov-modulated affine term structure models. Journal of Industrial & Management Optimization, 2021, 17 (5) : 2685-2702. doi: 10.3934/jimo.2020089 [12] Gerhard Rein, Christopher Straub. On the transport operators arising from linearizing the Vlasov-Poisson or Einstein-Vlasov system about isotropic steady states. Kinetic & Related Models, 2020, 13 (5) : 933-949. doi: 10.3934/krm.2020032 [13] Nuh Aydin, Nicholas Connolly, Markus Grassl. Some results on the structure of constacyclic codes and new linear codes over GF(7) from quasi-twisted codes. Advances in Mathematics of Communications, 2017, 11 (1) : 245-258. doi: 10.3934/amc.2017016 [14] Marco A. Fontelos, Lucía B. Gamboa. On the structure of double layers in Poisson-Boltzmann equation. Discrete & Continuous Dynamical Systems - B, 2012, 17 (6) : 1939-1967. doi: 10.3934/dcdsb.2012.17.1939 [15] Chao Wang, Ravi P Agarwal. Almost automorphic functions on semigroups induced by complete-closed time scales and application to dynamic equations. Discrete & Continuous Dynamical Systems - B, 2020, 25 (2) : 781-798. doi: 10.3934/dcdsb.2019267 [16] Bin-Guo Wang, Wan-Tong Li, Liang Zhang. An almost periodic epidemic model with age structure in a patchy environment. Discrete & Continuous Dynamical Systems - B, 2016, 21 (1) : 291-311. doi: 10.3934/dcdsb.2016.21.291 [17] Toshikazu Kuniya, Jinliang Wang, Hisashi Inaba. A multi-group SIR epidemic model with age structure. Discrete & Continuous Dynamical Systems - B, 2016, 21 (10) : 3515-3550. doi: 10.3934/dcdsb.2016109 [18] Xueqin Li, Chao Tang, Tianmin Huang. Poisson $S^2$-almost automorphy for stochastic processes and its applications to SPDEs driven by Lévy noise. Discrete & Continuous Dynamical Systems - B, 2018, 23 (8) : 3309-3345. doi: 10.3934/dcdsb.2018282 [19] Manuel de León, Juan Carlos Marrero, David Martín de Diego. Linear almost Poisson structures and Hamilton-Jacobi equation. Applications to nonholonomic mechanics. Journal of Geometric Mechanics, 2010, 2 (2) : 159-198. doi: 10.3934/jgm.2010.2.159 [20] Jing Feng, Bin-Guo Wang. An almost periodic Dengue transmission model with age structure and time-delayed input of vector in a patchy environment. Discrete & Continuous Dynamical Systems - B, 2021, 26 (6) : 3069-3096. doi: 10.3934/dcdsb.2020220

2020 Impact Factor: 0.857

## Metrics

• HTML views (0)
• Cited by (0)

• on AIMS


text:
It is currently 22 Jan 2018, 18:06

### GMAT Club Daily Prep

#### Thank you for using the timer - this advanced tool can estimate your performance and suggest more practice questions. We have subscribed you to Daily Prep Questions via email.

Customized
for You

we will pick new questions that match your level based on your Timer History

Track

every week, we’ll send you an estimated GMAT score based on your performance

Practice
Pays

we will pick new questions that match your level based on your Timer History

# Events & Promotions

###### Events & Promotions in June
Open Detailed Calendar

# At a certain fruit stand, the price of each apple is 40 cents and the

Author Message
TAGS:

### Hide Tags

Math Expert
Joined: 02 Sep 2009
Posts: 43361
At a certain fruit stand, the price of each apple is 40 cents and the [#permalink]

### Show Tags

20 Oct 2015, 02:19
Expert's post
63
This post was
BOOKMARKED
00:00

Difficulty:

95% (hard)

Question Stats:

51% (02:26) correct 49% (02:36) wrong based on 1258 sessions

### HideShow timer Statistics

At a certain fruit stand, the price of each apple is 40 cents and the price of each orange is 60 cents. Mary selects a total of 10 apples and oranges from the fruit stand, and the average (arithmetic mean) price of the 10 pieces of fruit is 56 cents. How many oranges must Mary put back so that the average price of the pieces of fruit that she keeps is 52 cents?

(A) 1
(B) 2
(C) 3
(D) 4
(E) 5

Kudos for a correct solution.
[Reveal] Spoiler: OA

_________________
SVP
Joined: 08 Jul 2010
Posts: 1920
Location: India
GMAT: INSIGHT
WE: Education (Education)
Re: At a certain fruit stand, the price of each apple is 40 cents and the [#permalink]

### Show Tags

20 Oct 2015, 03:15
14
KUDOS
Expert's post
6
This post was
BOOKMARKED
Bunuel wrote:
At a certain fruit stand, the price of each apple is 40 cents and the price of each orange is 60 cents. Mary selects a total of 10 apples and oranges from the fruit stand, and the average (arithmetic mean) price of the 10 pieces of fruit is 56 cents. How many oranges must Mary put back so that the average price of the pieces of fruit that she keeps is 52 cents?

(A) 1
(B) 2
(C) 3
(D) 4
(E) 5

Kudos for a correct solution.

Apple (A) = 40 cemts
Orange (B) = 60 cents
Average of 10 fruits = 56 cents
u.e. Total Price of 10 Fruits = 56*10 = 560 cents

i.e. 40A + 60 B = 560
and A + B = 10

i.e. 40A + 60 (10-A) = 560
i.e. -20A + 600 = 560
i.e. A = 2
i.e. B = 8

Average to be brought at = 52 cents
let oranges to be put back = C
i.e. Total Fruits = 10-C
where total Oranges left = 8-C
i.e. Total Price of New lot of fruits = 52*(10-C)

i.e. 40*2 + 60*(8-C) = 52*(10-C)
i.e. 80 + 480 - 60C = 520 - 52C
i.e. 8 C = 40
i.e. C = 5

_________________

Prosper!!!
GMATinsight
Bhoopendra Singh and Dr.Sushma Jha
e-mail: info@GMATinsight.com I Call us : +91-9999687183 / 9891333772
Online One-on-One Skype based classes and Classroom Coaching in South and West Delhi
http://www.GMATinsight.com/testimonials.html

22 ONLINE FREE (FULL LENGTH) GMAT CAT (PRACTICE TESTS) LINK COLLECTION

Intern
Status: Out of my Mind , will be back in 2 minutes
Joined: 27 Aug 2015
Posts: 13
Location: India
GMAT 1: 610 Q49 V25
WE: Other (Other)
Re: At a certain fruit stand, the price of each apple is 40 cents and the [#permalink]

### Show Tags

20 Oct 2015, 03:31
3
KUDOS
Ans E

Sum of Apples and Oranges is 10

A + O = 10

Apple cost 40 cent and Orange cost 60 cent and there mean is 56 , therefore

(40*A + 60*O)/10 = 56 , which gives us

4A + 6O = 56

Solving the above 2 equation we get , Apples = 2 , Oranges = 8.

Now as she has remove some oranges ( x ) such that the new mean of the remaining fruits become 52

note that the number of Apples remain the same , therefore new equation will become

( 2*40 + (8-x)60 ) / 10 -x = 52

As the remaining fruits will be 10 - x

On solving for x we will get our ans 5
Verbal Forum Moderator
Status: Greatness begins beyond your comfort zone
Joined: 08 Dec 2013
Posts: 1892
Location: India
Concentration: General Management, Strategy
Schools: Kelley '20, ISB '19
GPA: 3.2
WE: Information Technology (Consulting)
Re: At a certain fruit stand, the price of each apple is 40 cents and the [#permalink]

### Show Tags

20 Oct 2015, 04:39
3
KUDOS
4
This post was
BOOKMARKED
Let number of Apples = A
number of oranges = B
A+B=10 --- 1
.56 =(.4A + .6 B)/10
=> 56 = 4A + 6B ----2
Solving 1 and 2, we get
A= 2
B= 8

Let the number of oranges put back = C
52*(10-c) = 40*2 + 60(8-C)
=> C= 5

Alternatively , we can use Scale method
Since average is .56 , distance of the average from price of apple =.56-.4=.16
and distance of the average from price of orange = .6 - .56 = .04
Ratio of distances is .16:.04 = 4:1

Therefore , number of apples and oranges will be in inverse proportion =1:4
Number of apples = 2
Number of oranges = 8

After removing a certain number of oranges C , the new average will be .52
Ratio of distances is .08:.12 = 2:3

Number of oranges will be 3
Therefore Mary must put 5 oranges back .

_________________

When everything seems to be going against you, remember that the airplane takes off against the wind, not with it. - Henry Ford
The Moment You Think About Giving Up, Think Of The Reason Why You Held On So Long
+1 Kudos if you find this post helpful

Current Student
Joined: 10 Aug 2015
Posts: 54
Concentration: General Management, Entrepreneurship
GMAT 1: 730 Q48 V42
Re: At a certain fruit stand, the price of each apple is 40 cents and the [#permalink]

### Show Tags

20 Oct 2015, 05:34
6
KUDOS
3
This post was
BOOKMARKED
Step 1: We start with the first average to find the total price of the apples and oranges.

Using the formula : Sum = Average * Number of terms
Sum = 56 * 10 = 560

Step 2: Set up the new average based on the first one.
x : number of oranges we need to take away.
We will have the previous sum (i.e. 560) minus the price of all oranges we will take away (i.e. 60x) and the number of elements will be 10 minus x.

So :
(560-60x) / (10-x) = 52
560 - 60x = (10-x) * 52
560 - 520 = -52x + 60x
40 = 8x
x=5

Veritas Prep GMAT Instructor
Joined: 16 Oct 2010
Posts: 7875
Location: Pune, India
Re: At a certain fruit stand, the price of each apple is 40 cents and the [#permalink]

### Show Tags

20 Oct 2015, 20:37
1
KUDOS
Expert's post
3
This post was
BOOKMARKED
Manager
Joined: 01 Mar 2015
Posts: 50
Re: At a certain fruit stand, the price of each apple is 40 cents and the [#permalink]

### Show Tags

20 Oct 2015, 21:25
4
KUDOS
4
This post was
BOOKMARKED
Bunuel wrote:
At a certain fruit stand, the price of each apple is 40 cents and the price of each orange is 60 cents. Mary selects a total of 10 apples and oranges from the fruit stand, and the average (arithmetic mean) price of the 10 pieces of fruit is 56 cents. How many oranges must Mary put back so that the average price of the pieces of fruit that she keeps is 52 cents?

(A) 1
(B) 2
(C) 3
(D) 4
(E) 5

Kudos for a correct solution.

here price of apple = 40 cents and price of orange = 60 cents

average price = 56 cents

so, the apples and oranges are in ratio

apple : orange = 60 - 56 : 56 - 40
=> apple : orange = 4 : 16
=> apple : orange = 1 : 4

total no =10, therefore apples = 2 nos. and oranges = 8 nos.

now we have to make average price = 52 cents
so, the apples and oranges will be in ratio

apple : orange = 60 - 52 : 52 - 40
=> apple : orange = 8 : 12
=> apple : orange = 2 : 3

now we have apples = 2 nos. from above, therefore oranges must be 3 in number

oranges to be put back = 8 - 3 = 5 nos

kudos if you like the explanation
Intern
Joined: 23 Oct 2015
Posts: 4
Re: At a certain fruit stand, the price of each apple is 40 cents and the [#permalink]

### Show Tags

22 Mar 2016, 02:34
v12345 wrote:
Bunuel wrote:
At a certain fruit stand, the price of each apple is 40 cents and the price of each orange is 60 cents. Mary selects a total of 10 apples and oranges from the fruit stand, and the average (arithmetic mean) price of the 10 pieces of fruit is 56 cents. How many oranges must Mary put back so that the average price of the pieces of fruit that she keeps is 52 cents?

(A) 1
(B) 2
(C) 3
(D) 4
(E) 5

Kudos for a correct solution.

here price of apple = 40 cents and price of orange = 60 cents

average price = 56 cents

so, the apples and oranges are in ratio

apple : orange = 60 - 56 : 56 - 40
=> apple : orange = 4 : 16
=> apple : orange = 1 : 4

total no =10, therefore apples = 2 nos. and oranges = 8 nos.

now we have to make average price = 52 cents
so, the apples and oranges will be in ratio

apple : orange = 60 - 52 : 52 - 40
=> apple : orange = 8 : 12
=> apple : orange = 2 : 3

now we have apples = 2 nos. from above, therefore oranges must be 3 in number

oranges to be put back = 8 - 3 = 5 nos

kudos if you like the explanation

Hi!

I used the exact same way as you did in solving this question, but when reaching the last part 2:3 I interpereted it as 3/5 oranges and 2/5 apples? Seeing as we're still closer to 60 than 40. And then we should have 6 oranges and 4 apples? Please explain!
Intern
Joined: 23 Oct 2015
Posts: 4
At a certain fruit stand, the price of each apple is 40 cents and the [#permalink]

### Show Tags

22 Mar 2016, 02:37
My bad, I see now that we were not supposed to replace them with any apples but just remove them from the total. Didn't read carefully enough
Target Test Prep Representative
Status: Founder & CEO
Affiliations: Target Test Prep
Joined: 14 Oct 2015
Posts: 2069
Location: United States (CA)
At a certain fruit stand, the price of each apple is 40 cents and the [#permalink]

### Show Tags

04 May 2016, 08:50
3
KUDOS
Expert's post
1
This post was
BOOKMARKED
Bunuel wrote:
At a certain fruit stand, the price of each apple is 40 cents and the price of each orange is 60 cents. Mary selects a total of 10 apples and oranges from the fruit stand, and the average (arithmetic mean) price of the 10 pieces of fruit is 56 cents. How many oranges must Mary put back so that the average price of the pieces of fruit that she keeps is 52 cents?

(A) 1
(B) 2
(C) 3
(D) 4
(E) 5

Kudos for a correct solution.

Solution:

We can let the number of apples = x and the number of oranges = y. Using these variables we can create the following two equations:

1) x + y = 10

Using the formula average = sum/quantity, we have:

2) (40x + 60y)/10 = 56

Let’s first simplify equation 2:

40x + 60y = 560

4x + 6y = 56

2x + 3y = 28

Isolating for y in equation one gives us: y = 10 – x.

Since y = 10 – x, we can substitute 10 – x for y in the equation 2x + 3y = 28. This gives us:

2x + 3(10 – x) = 28

2x + 30 – 3x = 28

-x = -2

x = 2

Since x + y = 10, then y = 8.

We thus know that Mary originally selected 2 apples and 8 oranges.

We must determine the number of oranges that Mary must put back so that the average price of the pieces of fruit that she keeps is 52¢. We can let n = the number of oranges Mary must put back.

Let’s use a weighted average equation to determine the value of n.

[40(2) + 60(8-n)]/(10 – n) = 52

(80 + 480 - 60n)/(10 – n) = 52

560 – 60n = 520 – 52n

40 = 8n

5 = n

Thus, Mary must put back 5 oranges so that the average cost of the fruit she has kept would be 52 cents.

_________________

Scott Woodbury-Stewart
Founder and CEO

GMAT Quant Self-Study Course
500+ lessons 3000+ practice problems 800+ HD solutions

Last edited by ScottTargetTestPrep on 04 Sep 2016, 05:29, edited 1 time in total.
Director
Joined: 07 Dec 2014
Posts: 885
Re: At a certain fruit stand, the price of each apple is 40 cents and the [#permalink]

### Show Tags

04 May 2016, 14:07
let a=#apples
r=#oranges
we know that .4a+.6r=(.56)(10)=5.6➡.4a=5.6-.6r
after mary returns x oranges, then
.4a+.6(r-x)=(.52)(10-x)
substituting for .4a,
5.6-.6r+.6r-.6x=5.2-.52x
.08x=.4
8x=40
x=5 oranges put back
Manager
Joined: 16 Mar 2016
Posts: 134
Location: France
GMAT 1: 660 Q47 V33
GPA: 3.25
At a certain fruit stand, the price of each apple is 40 cents and the [#permalink]

### Show Tags

04 May 2016, 14:19
4
KUDOS
2
This post was
BOOKMARKED
A = number of apples
B = number of oranges

We have :

$$\frac{40A + 60 B}{10}$$ = 56

and $$\frac{40A + 60 (B - x)}{10 - x}$$ = 52

$$\frac{40A + 60 B - 60 x}{10 - x}$$ = 52

$$\frac{560 - 60 x}{10 - x}$$ = 52

560 - 60 x = 520 - 52 x

40 = 8 x

x = 5

Last edited by Alex75PAris on 18 May 2016, 09:02, edited 1 time in total.
Senior Manager
Joined: 09 Feb 2015
Posts: 382
Location: India
Concentration: Social Entrepreneurship, General Management
GMAT 1: 690 Q49 V34
GMAT 2: 720 Q49 V39
GPA: 2.8
Re: At a certain fruit stand, the price of each apple is 40 cents and the [#permalink]

### Show Tags

14 May 2016, 10:28
Using Averages and Allegations

40 60
56
4 16

A:O =1: 4==>A=2 ,O=8(as total no of apples+ oranges =10)
now we know there are 2 Apples and 8 Oranges

Using Statistics

when Mean =52

52-40=12
12*2(bcos 2 apples)
60-52=8
x= no. of remaining oranges
24-(8*x)=0
==>x=3
Hence 5 oranges must be removed.
Current Student
Joined: 23 Mar 2016
Posts: 36
Schools: Tulane '18 (M)
Re: At a certain fruit stand, the price of each apple is 40 cents and the [#permalink]

### Show Tags

17 May 2016, 20:17
1
KUDOS
i did this one with a scale method

Apples : Price : Oranges
40 cents : 56 average : 60 cents
= 16 cents from average : average : 4 cents from average
= 1 apple for every 4 oranges
= 2 apples and 8 oranges = 10 fruits = 2*.4 + 8*.6 = 5.60 / 10 = .56

40 cents : 52 average : 60 cents
= 12 cents from average : average : 8 cents from average
= 2 apples for every 3 oranges

8 oranges - 3 oranges = 5 oranges must be put back

Hope this helps!
Manager
Joined: 23 Jan 2016
Posts: 220
Location: India
GPA: 3.2
Re: At a certain fruit stand, the price of each apple is 40 cents and the [#permalink]

### Show Tags

18 Jun 2016, 00:43
Although I got this right, it took me 10 minutes to solve it. Can anyone help me with a strategy to tackle this type of question on GMAT? There is no way im going to solve this question on the exam.
Manager
Joined: 29 Nov 2011
Posts: 114
Re: At a certain fruit stand, the price of each apple is 40 cents and the [#permalink]

### Show Tags

18 Jun 2016, 04:08
total amount = avg * number of items
old amount = 56 * 10 = 560

new amount will be 52 *10-x
10-x , you have same number of apples , only decrease in number of oranges
now new amount is equal to what
560 - 60 x = new amount
solve and x= 5
Senior Manager
Joined: 27 Mar 2016
Posts: 346
Location: United States (CO)
GMAT 1: 770 Q51 V44
GPA: 3.69
WE: Analyst (Consulting)
Re: At a certain fruit stand, the price of each apple is 40 cents and the [#permalink]

### Show Tags

19 Jun 2016, 01:14
4
KUDOS
The current total price is divisible by 10, and so is the price of each orange. The adjusted total price therefore will have to be divisible by 10, and at the same time divisible by 52. The only possible value for the adjusted total price is 260. Hence 300 cents' worth of oranges, or 5 oranges, will have to be removed.
Manager
Joined: 30 Dec 2015
Posts: 90
GPA: 3.92
WE: Engineering (Aerospace and Defense)
Re: At a certain fruit stand, the price of each apple is 40 cents and the [#permalink]

### Show Tags

09 Oct 2016, 19:13
3
KUDOS
Bunuel wrote:
At a certain fruit stand, the price of each apple is 40 cents and the price of each orange is 60 cents. Mary selects a total of 10 apples and oranges from the fruit stand, and the average (arithmetic mean) price of the 10 pieces of fruit is 56 cents. How many oranges must Mary put back so that the average price of the pieces of fruit that she keeps is 52 cents?

(A) 1
(B) 2
(C) 3
(D) 4
(E) 5

Kudos for a correct solution.

$$\frac{Wa}{Wo} = \frac{(60-56)}{(56-40}) = \frac{1}{4}$$
Apple = 2 & Orange = 8
New Avg
$$\frac{Wa}{Wo} = \frac{(60-52)}{(52-40)} = \frac{2}{3}$$
$$\frac{2}{Wo} = \frac{2}{3}$$
Orange = 3

Hence, Oranges have to reduce from 8 to 3 i.e. 5
_________________

If you analyze enough data, you can predict the future.....its calculating probability, nothing more!

Intern
Joined: 13 Dec 2015
Posts: 16
Re: At a certain fruit stand, the price of each apple is 40 cents and the [#permalink]

### Show Tags

15 Oct 2016, 02:01
Not convinced mate... I am able to get to fractions 1/4 and 2/3.... but given the total number of items is 10, why would make the ratio of 1/4 to 2/8 and keep the ratio 2/3 as it is ?

If someone can breakdown this using the same formula that would be helpful.

colorblind wrote:
Bunuel wrote:
At a certain fruit stand, the price of each apple is 40 cents and the price of each orange is 60 cents. Mary selects a total of 10 apples and oranges from the fruit stand, and the average (arithmetic mean) price of the 10 pieces of fruit is 56 cents. How many oranges must Mary put back so that the average price of the pieces of fruit that she keeps is 52 cents?

(A) 1
(B) 2
(C) 3
(D) 4
(E) 5

Kudos for a correct solution.

$$\frac{Wa}{Wo} = \frac{(60-56)}{(56-40}) = \frac{1}{4}$$
Apple = 2 & Orange = 8
New Avg
$$\frac{Wa}{Wo} = \frac{(60-52)}{(52-40)} = \frac{2}{3}$$
$$\frac{2}{Wo} = \frac{2}{3}$$
Orange = 3

Hence, Oranges have to reduce from 8 to 3 i.e. 5
SVP
Joined: 08 Jul 2010
Posts: 1920
Location: India
GMAT: INSIGHT
WE: Education (Education)
Re: At a certain fruit stand, the price of each apple is 40 cents and the [#permalink]

### Show Tags

15 Oct 2016, 02:16
2
KUDOS
Expert's post
2
This post was
BOOKMARKED
Dev1212 wrote:
Not convinced mate... I am able to get to fractions 1/4 and 2/3.... but given the total number of items is 10, why would make the ratio of 1/4 to 2/8 and keep the ratio 2/3 as it is ?

If someone can breakdown this using the same formula that would be helpful.

Bunuel wrote:
At a certain fruit stand, the price of each apple is 40 cents and the price of each orange is 60 cents. Mary selects a total of 10 apples and oranges from the fruit stand, and the average (arithmetic mean) price of the 10 pieces of fruit is 56 cents. How many oranges must Mary put back so that the average price of the pieces of fruit that she keeps is 52 cents?

(A) 1
(B) 2
(C) 3
(D) 4
(E) 5

Kudos for a correct solution.

Please find the solution as attached.

I hope this helps!!!
Attachments

File comment: www.GMATinsight.com

Ans.jpg [ 194.7 KiB | Viewed 12916 times ]

_________________

Prosper!!!
GMATinsight
Bhoopendra Singh and Dr.Sushma Jha
e-mail: info@GMATinsight.com I Call us : +91-9999687183 / 9891333772
Online One-on-One Skype based classes and Classroom Coaching in South and West Delhi
http://www.GMATinsight.com/testimonials.html

22 ONLINE FREE (FULL LENGTH) GMAT CAT (PRACTICE TESTS) LINK COLLECTION

Re: At a certain fruit stand, the price of each apple is 40 cents and the   [#permalink] 15 Oct 2016, 02:16

Go to page    1   2    Next  [ 35 posts ]

Display posts from previous: Sort by

format: plain


text:
# Category: Software

We like to describe the Crazyflie as a versatile open source flying development platform. It is something that enables you to do cool stuff. It is not a finished, polished end product in its own.

The platform offers hardware extensions in form of decks, that you make your self or buy from Bitcraze. And the platform offers software extension, either by altering the firmware on the device or by writing programs that communicate with the platform.

This approach makes determining the expectations and requirements for the platform and the surrounding ecosystem a bit tricky. It is dependent on what you as a user plan to create using our products. And since the ecosystem is growing we need a, scalable, way to handle these fuzzy expectations during development and maintenance.

We think testing is big part of solving this, testing in a systematic, scalable and reproducible way. This is the reason for setting up our first physical test lab, aimed at providing stability while moving forward with new products and features.

## Testing today

### Continuous integration

On each change proposal to our software we run tests. For the firmware in the device we build multiple different configuration and run unit-tests. For the Crazyflie client and the Python library we make sure we can build for Linux and Windows and that the code passes our style guidelines. If any test fail we go back and update the proposed changed and re-run the tests. This is our first level of defense against defects.

### Release testing

For each release we follow a checklist of procedures and tests to make sure that quality does not degrade. We make sure all the examples in the Python library are working and that the Crazyflie can fly around as expected in our flight arena, using various positioning systems.

### Limitations

The way we test today makes it very difficult to determine if we regress in, for example, flight capability or in radio communication quality. We either test different software packages in isolation, without hardware in the loop, or we test by having a human trying to estimate if any degradation has happened since the last release.

We run into scalability issues as our ecosystem grows, it is near impossible to test all the different combinations of products. And it is very hard for us to detect stability or quality regressions without having a more systematic approach to testing the software on relevant hardware.

## Introducing the test lab

What we have done so far are two things:

1. Created an infrastructure for setting up a site for testing our software on real devices
2. Prepared a test lab in our printer room at our office in Malmö

### Infrastructure: crazyflie-testing

This new Git repository contains the building blocks we need to setup our new test lab. You can check out the repository README.md file for information on how to run it.

It contains a beginning of an automated QA test suite and along with that a start of a set of requirements for those tests. The requirements are specified in TOML files which are parsed and accessed from the tests. They are also rendered to markdown, to be easier for human consumption.

The repository contains a way to specify a test site, which is a collection of devices to run the test suite against. You specify your site in a TOML file which contain information about each device, such as which decks are connected and the radio:// URI. This site specification is then used by the test framework when running the tests, making sure each test is run against all devices compatible with that test.

The infrastructure also has management scripts to perform tasks like flashing all devices in a site, or recovering them if they go into boot loader mode by accident. All aimed at being able to handle testing with the least amount of human intervention possible.

The most recent addition to the infrastructure is the ability to test swarms using the Crazyswarm project!

### Crazylab Malmö

We define the site crazylab-malmö.toml which is the test lab we have setup in our printer room in Malmö, Sweden, it is currently defined as:

version = 1

[device.cf2_flow2_lighthouse]
decks = ["bcFlow2", "bcLighthouse4"]

[device.cf2_flow2]
decks = ["bcFlow2"]

[device.cf2_flow2_multiranger]
decks = ["bcFlow2", "bcMultiranger"]

[device.cf2_usddeck]
decks = ["bcUSD"]

[device.cf2_lighthouse]
decks = ["bcLighthouse4"]

[device.cf2_stock]
bootloader_radio = "radio://0/0/2M/B177790F3A?safelink=0"

There are, for now, six devices with different combination of decks attached. Each night, after midnight, different GitHub actions starts working for us. One job builds the latest versions of the firmwares for the devices another job will upgrade all the devices in the lab and run the test suite, and a selection of the Python library examples. We will be notified if any of these jobs fail.

This acts as a safety net for us. We will quickly know if the communication performance degrades, or if we have messed up with our parameter or logging frameworks. And we can catch silly firmware bugs as early as possible.

### Future

We want to keep adding test cases and other infrastructure to our testing framework. Going forward it would be really nice to be able to test positioning systems in some way. And of course, some type of test of flight, be it free flying tests or using some kind of harness.

It might be interesting to look into adding simulations (hardware in loop or not) to our testing setup. It is all a question of bandwidth, there are a lot of cool things to work on, and a limit on time and bodies.

You can help! You might even be able to help yourself while helping us! If you contribute tests that correspond to your use-case, then you can relax knowing that those tests will run each night, and that Bitcraze engineers will be notified the minute they fail.

Or you can define your own site and run the test-suite against all your devices to make sure nothing strange is going on.

Hopefully this infrastructure and lab will help all of us to do more cool stuff using the Bitcraze ecosystem!

This week we have a guest blog post from Bart Duisterhof and Prof. Guido de Croon from the MAVlab, Faculty of Aerospace Engineering from the Delft University of Technology. Enjoy!

Tiny drones are ideal candidates for fully autonomous jobs that are too dangerous or time-consuming for humans. A commonly shared dream would be to have swarms of such drones help in search-and-rescue scenarios, for instance to localize gas leaks without endangering human lives. Drones like the CrazyFlie are ideal for such tasks, since they are small enough to navigate in narrow spaces, safe, agile, and very inexpensive. However, their small footprint also makes the design of an autonomous swarm extremely challenging, both from a software and hardware perspective.

From a software perspective, it is really challenging to come up with an algorithm capable of autonomous and collaborative navigation within such tight resource constraints. State-of-the-art solutions like SLAM require too much memory and processing power. A promising line of work is to use bug algorithms [1], which can be implemented as computationally efficient finite state machines (FSMs), and can navigate around obstacles without requiring a map.

A downside of using FSMs is that the resulting behavior can be very sensitive to their hyperparameters, and therefore may not generalize outside of the tested environments. This is especially true for the problem of gas source localization (GSL), as wind conditions and obstacle configurations drastically change the problem. In this blog post, we show how we tackled the complex problem of swarm GSL in cluttered environments by using a simple bug algorithm with evolved parameters, and then tested it onboard a fully autonomous swarm of CrazyFlies. We will focus on the problems that were encountered along the way, and the design choices we made as a result. At the end of this post, we will also add a short discussion about the future of nano drones.

Why gas source localization?

Overall we are interested in finding novel ways to enable autonomy on constrained devices, like CrazyFlies. Two years ago, we showed that a swarm of CrazyFlie drones was able to explore unknown, cluttered environments and come back to the base station. Since then, we have been working on an even more complex task: using such a swarm for Gas Source Localization (GSL).

There has been a lot of research focussing on autonomous GSL in robotics, since it is an important but very hard problem. The difficulty of the task comes from the complexity of how odor can spread in an environment. In an empty room without wind, a gas will slowly diffuse from the source. This can allow a robot to find it by moving up gradient, just like small bacteria like E. Coli do. However, if the environment becomes larger with many obstacles and walls, and wind comes into play, the spreading of gas is much less regular. Large parts of the environment may have no gas or wind at all, while at the same time there may be pockets of gas away from the source. Moreover, chemical sensors for robots are much less capable than the smelling organs of animals. Available chemical sensors for robots are typically less sensitive, noisier, and much slower.

Due to these difficulties, most work in the GSL field has focused on a single robot that has to find a gas source in environments that are relatively small and without obstacles. Relatively recently, there have been studies in which groups of robots solve this task in a collaborative fashion, for example with Particle Swarm Optimization (PSO). This allows robots to find the source and escape local maxima when present. Until now this concept has been shown in simulation [2] and on large outdoor drones equipped with LiDAR and GPS [3], but never before on tiny drones in complex, GPS-denied, indoor environments.

Required Infrastructure

In our project, we introduce a new bug algorithm, Sniffy Bug, which uses PSO for gas source localization. In order to tune the FSM of Sniffy Bug, we used an artificial evolution. For time reasons, evolution typically takes place in simulation. However, early in the project, we realized that this would be a challenge, as no end-to-end gas modeling pipeline existed yet. It is important to have an easy-to-use pipeline that does not require any aerodynamics domain knowledge, such that as many researchers as possible can generate environments to test their algorithms. It would also make it easier to compare contributions and to better understand in which conditions certain algorithms work or don’t work. The GADEN ROS package [4] is a great open-source tool for modeling gas distribution when you have an environment and flow field, but for our objective, we needed a fully automated tool that could generate a great variety of random environments on-demand with just a few parameters. Below is an overview of our simulation pipeline: AutoGDM.

First, we use a procedural environment generator proposed in [5] to generate random walls and obstacles inside of the environment. An important next step is to generate a 3D flowfield by means of computational fluid dynamics (CFD). A hard requirement for us was that AutoGDM needed to be free to use, so we chose to use the open-source CFD tool OpenFOAM. It’s used for cutting-edge aerodynamics research, and also the tool suggested by the authors of GADEN. Usually, using OpenFOAM isn’t trivial, as a large number of parameters need to be selected that require field expertise, resulting in a complicated process. Next, we integrate GADEN into our pipeline, to go from environment definition (CAD files) and a flow field to a gas concentration field. Other parts that needed to be automated were the random selection of boundary conditions, which has a large impact on the actual flow field, and source placement, which has an equally large impact on the concentration field.

After we built this pipeline, we started looking for a robot simulator to couple it to. Since we weren’t planning on using a camera, our main requirement was for the simulator to be efficient (preferably in 2D) so that evolutions would take relatively little time. We decided to use Swarmulator [6], a lightweight C++ robot simulator designed for swarming and we plugged in our gas data.

Algorithm Design

Roughly speaking, we considered two categories of algorithms for controlling the drones: 1) a neural network, and 2) an FSM that included PSO, with evolved parameters. Since we used a tiny neural network for light seeking with a CrazyFlie in our previous work, we first evolved neural networks in simulation. One of the first experiments is shown below.

While it worked pretty well in simple environments with few obstacles, it seemed challenging to make this work in real life with complex obstacles and multiple agents that need to collaborate. Given the time constraints of the project, we have opted for evolving the FSM. This also facilitated crossing the reality gap, as the simulated evolution could build on basic behaviors that we developed and validated on the real platform, including obstacle avoidance with four tiny laser rangers, while communicating with and avoiding other drones. An additional advantage of PSO with respect to the reality gap is that it only needs gas concentration and no gradient of the gas concentration or wind direction (which many algorithms in literature use). On a real robot at this scale, estimating the gas concentration gradient or the direction of a light breeze is hard if not impossible.

Hardware

Our CrazyFlie needs to be able to avoid obstacles, execute velocity commands, sense gas, and estimate the other agent’s position in its own frame. For navigation, we added the flow deck and laser rangers, whereas for gas sensing we used a TGS8100 gas sensor that was used on a CrazyFlie before in previous work [7]. The sensor is lightweight and inexpensive, but accurately estimating gas concentrations can be difficult because of its size. It tends to drift and needs time to recover after a spike in concentration is observed. Another thing we noticed is that it is possible to break them, a crash can definitely destroy the sensor.

To estimate the relative position between agents, we use a Decawave Ultra-Wideband (UWB) module and communicate states, as proposed in [8]. We also use the UWB module to communicate gas information between agents and collaboratively seek the source. The complete configuration is visible below.

Evaluation in Simulation

After we optimized the parameters of our model using Swarmulator and AutoGDM, and of course trying many different versions of our algorithm, we ended up with the final Sniffy Bug algorithm. Below is a video that shows evolved Sniffy Bug evaluated in six different environments. The red dots are an agent’s personal target waypoint, whereas the yellow dot is the best-known position for the swarm.

Simulation showed that Sniffy Bug is effective at locating the gas source in randomly generated environments. The drones successfully collaborate by means of PSO.

Real Flight Testing

After observing Sniffy Bug in simulation we were optimistic, but unsure about performance in real life. First, inspired by previous works, we disperse alcohol through the air by placing liquid alcohol into a can which is then dispersed using a computer fan.

We test Sniffy Bug in our flight arena of size 10 x 10 meters with large obstacles that are shaped like walls and orange poles. The image below shows four flight tests of Sniffy Bug in cluttered environments, flying fully autonomously, i.e., without the help from any external infrastructure.

In the total of 24 runs we executed, we compared Sniffy Bug with manually selected and evolved parameters. The figure below shows that the evolved parameters are more efficient in locating the source as compared to the manual parameters.

This does not only show that our system can successfully locate a gas source in challenging environments, but it also demonstrates the usefulness of the simulation pipeline. The parameters that were learned in simulation yield a high-performance model, validating the environment generation, randomization, and gas modeling parts of our pipeline.

Conclusion and Discussion

With this work, we believe we have made an important step towards swarms of gas-seeking drones. The proposed solution is shown to work in real flight tests with obstacles, and without any external systems to help in localization or communication. We believe this methodology can be extended to larger environments or even to 3 dimensions, since PSO is a robust, multi-dimensional heuristic search method. Moreover, we hope that AutoGDM will help the community to better compare gas seeking algorithms, and to more easily learn parameters or models in simulation, and deploy them in the real world.

To improve Sniffy Bug’s performance, adding more laser rangers will definitely help. When working with only four laser rangers you realize how little information it actually provides. If one of the rangers senses a low value it is unclear if a slim pole or a massive wall is detected, adding inefficiency to the algorithm. Adding more laser rangers or using other sensor modalities like vision will help to avoid also more complex obstacles than walls and poles in a reliable manner.

Another interesting discussion can be held on the hardware required for real deployment. When working with 40 grams of maximum take-off weight, the sensors and actuators that can be selected are limited. For example, the low-power and lightweight flow deck works great but fails in low-light scenarios or with smoke. Future work exploring novel sensors for highly constrained nano robots could really help increase the Technological Readiness Level (TRL) of these systems.

Finally, this has been a really fun project to work on for us and we can’t wait to hear your thoughts on Sniffy Bug!

References

Video:

Please reach out if you have any questions or ideas, you can reach us at: b.p.duisterhof@gmail.com or g.c.h.e.decroon@tudelft.nl

We are happy to announce the availability of the 2021.06 release of the Crazyflie firmware and client! This release includes bugfixes related to flashing the Crazyflie and the Lighthouse deck and also the new concept of core parameters and logging variables, that we talked about in the blog post: Crazyflie logging and parameters interface.

There are new binaries for the Crazyflie (2021.06), the Crazyflie client (2021.6) as well as a new release of the Crazyflie python library (0.1.16). The firmware package can be downloaded from the Crazyflie release repository (2021.06) or can be flashed directly using the Crazyflie client.

## Noteworthy features and fixes

### Crazyflie STM firmware

* Added an app layer application of the wall following demo
* Fixed a bug where the initial position of the Kalman estimator was set to (1.5, 0, 0)
* Enable an estimator to be added by out of tree build
* Add and document core parameters and log variables
* Fix deck info mem implementation can return uninitialized buffer
- Caused: Flashing errors with Flowdeck
* Rechecked INDI controller for mistakes/consistency

### Crazyflie NRF firmware

* pm: Increase delay before powering system
- Caused: Issues flashing Lighthouse deck

### Crazyflie Python library (0.1.16)

* Add support for crazyflie-link-cpp
* Add get_value to parameter class
* Make tutorial more user friendly
* Improve reset_to[firmware|bootloader]

### Crazyflie Client

* Do not allow upgrading firmware when connected to USB
* Console tab: new messages should always appear at the bottom
* Update install doc

### Documentation

* Core logging groups and variables
* Core parameter groups and variables
* Improved motion commander tutorial

## Help us out!

We always strive to release quality software and firmware, but we are not perfect! Please help us out by installing the new library, client and firmware and make sure that your applications, tools and algorithms still work as you expect! And if not please file an issue with us or contact us via the forum.

Happy hacking!

This week we have a guest blog post from Dr Feng Shan at School of Computer Science and Engineering
Southeast University, China. Enjoy!

It is possible to utilize tens and thousands of Crazyflies to form a swarm to complete complicated cooperative tasks, such as searching and mapping. These Crazyflies are in short distance to each other and may move dynamically, so we study the dynamic and dense swarms. The ultra-wideband (UWB) technology is proposed to serve as the fundamental technique for both networking and localization, because UWB is so time sensitive that an accurate distance can be calculated using the transmission and receive timestamps of data packets. We have therefore designed a UWB Swarm Ranging Protocol with key features: simple yet efficient, adaptive and robust, scalable and supportive. It is implemented on Crazyflie 2.1 with onboard UWB wireless transceiver chips DW1000.

## The Basic Idea

The basic idea of the swarm ranging protocol was inspired by Double Sided-Two Way Ranging (DS-TWR), as shown below.

There are four types of message in DS-TWR, i.e., poll, response, final and report message, exchanging between the two sides, A and B. We define their transmission and receive timestamps are Tp, Rp, Tr, Rr, Tf, and Rf, respectively. We define the reply and round time duration for the two sides as follows.

Let tp be the time of flight (ToF), namely radio signal propagation time. ToF can be calculated as Eq. (2).

Then, the distance can be estimated by the ToF.

In our proposed Swarm Ranging Protocol, instead of four types of messages, we use only one type of message, which we call the ranging message.

Three sides A, B and C take turns to transmit six messages, namely A1, B1, C1, A2, B2, and C2. Each message can be received by the other two sides because of the broadcast nature of wireless communication. Then every message generates three timestamps, i.e., one transmission and two receive timestamps, as shown in Fig.3(a). We can see that each pair has two rounds of message exchange as shown in Fig.3(b). Hence, there are sufficient timestamps to calculate the ToF for each pair, that means all three pairs can be ranged with each side transmitting only two messages. This observation inspires us to design our ranging protocol.

## Protocol Design

The formal definition of the i-th ranging message that broadcasted by Crazyflie X is as follows.

Xi is the message identification, e.g., sender and sequence number; Txi-1 is the transmission timestamp of Xi-1, i.e., the last sent message; RxM is the set of receive timestamps and their message identification, e.g., RxM = {(A2, RA2), (B2, RB2)}; v is the velocity of X when it generates message Xi.

As mentioned above, six timestamps (Tp, Rp, Tr, Rr, Tf, Rf,) are needed to calculate the ToF. Therefore, for each neighbor, an additional data structure is designed to store these timestamps which we named it the ranging table, as shown in Fig.4. Each device maintains one ranging table for each known neighbor to store the timestamps required for ranging.

Let’s focus on a simple scenario where there are a number of Crazyflies, A, B, C, etc, in a short distance. Each one of them transmit a message that can be heard by all others, and they broadcast ranging messages at the same pace. As a result, between any two consecutive message transmission, a Crazyflie can hear messages from all others. The message exchange between A and Y is as follows.

The following steps show how the ranging messages are generated and the ranging tables are updated to correctly compute the distance between A and Y.

The message exchange between A and Y could be also A and B, A and C, etc, because they are equal, that’s means A could perform the ranging process above with all of it’s neighbors at the same time.

To handle dense and dynamic swarm, we improved the data structure of ranging table.

There are three new notations P, tn, ts, denoting the newest ranging period, the next (expected) delivery time and the expiration time, respectively.

For any Crazyflie, we allow it to have different ranging period for different neighbors, instead of setting a constant period for all neighbors. So, not all neighbors’ timestamps are required to be carried in every ranging message, e.g., the receive timestamp to a far apart and motionless neighbor is required less often. tn is used to measure the priority of neighbors. Also, when a neighbor is not heard for a certain duration, we set it as expired and will remove its ranging table.

If you are interested in our protocol, you can find much more details in our paper, that has just been published on IEEE International Conference on Computer Communications (INFOCOM) 2021. Please refer the links at the bottom of this article for our paper.

## Implementation

We have implemented our swarm ranging protocol for Crazyflie and it is now open-source. Note that we have also implemented the Optimized Link State Routing (OLSR) protocol, and the ranging messages are one of the OLSR messages type. So the “Timestamp Message” in the source file is the ranging message introduced in this article.

The procedure that handles the ranging messages is triggered by the hardware interruption of DW1000. During such procedure, timestamps in ranging tables are updated accordingly. Once a neighbor’s ranging table is complete, the distance is calculated and then the ranging table is rearranged.

All our codes are stored in the folder crazyflie-firmware/src/deck/drivers/src/swarming.

The following figure is a ranging performance comparison between our ranging protocol and token-ring based TWR protocol. It’s clear that our protocol handles the large number of drones smoothly.

We also conduct a collision avoidance experiment to test the real time ranging accuracy. In this experiment, 8 Crazyflie drones hover at the height 70cm in a compact area less than 3m by 3m. While a ninth Crazyflie drone is manually controlled to fly into this area. Thanks to the swarm ranging protocol, a drone detects the coming drone by ranging distance, and lower its height to avoid collision once the distance is small than a threshold, 30cm.

## Build & Run

Clone our repository

git clone --recursive https://github.com/SEU-NetSI/crazyflie-firmware.git

Go to the swarming folder.

cd crazyflie-firmware/src/deck/drivers/src/swarming

Then build the firmware.

make clean
make

Flash the cf2.bin.

cfloader flash path/to/cf2.bin stm32-fw

Open the client, connect to one of the drones and add log variables. (We use radio channel as the address of the drone) Our swarm ranging protocol allows the drones to ranging with multiple targets at the same time. The following shows that our swarm ranging protocol works very efficiently.

## Summary

We designed a ranging protocol specially for dense and dynamic swarms. Only a single type of message is used in our protocol which is broadcasted periodically. Timestamps are carried by this message so that the distance can be calculated. Also, we implemented our proposed ranging protocol on Crazyflie drones. Experiment shows that our protocol works very efficiently.

Our research group websitehttps://seu-netsi.net

Feng Shan, Jiaxin Zeng, Zengbao Li, Junzhou Luo and Weiwei Wu, “Ultra-Wideband Swarm Ranging,” IEEE INFOCOM 2021, Virtual Conference, May 10-13, 2021.

For quite a while now, I have been very interested in the Rust programming language and since Jonas joined us we are two rust-enthusiast at Bitcraze. Rust is a relatively recent programming language that aims at being safe, performant and productive. It is a system programming language in the sense that it compiles to machine code with minimal runtime. It prevents a lot of bugs at compile time and it provides great mechanisms for abstraction that makes it sometime feels as high level as languages like Python.

I have been interested in applying my love for Rust at Bitcraze, mostly during fun Fridays. There is two area that I have mainly explored so far: Putting Rust in embedded systems to replace pieces of C, having such a high-level-looking language in embedded is refreshing, and re-writing the Crazyflie lib on PC in rust to make it more performant and more portable. In this blog post I will talk about the later, I keep embedded rust for a future blog post :).

## Re-implementing Crazyflie lib

To re-implement the Crazyflie lib, the easiest it to follow the way the communication stack is currently setup, more information can be found on Crtp in a pevious blog post about the Crazyflie radio communication and the communication reliability.

Since I am currently focusing on implementing communication using the Crazyradio dongle, I have separated the implementation in the following modules (A crate is the Rust version of a library):

This organization is very similar to the layering that we have in the python crazyflie-lib, the difference being that in the Crazyflie lib all the layers are distributed in the same Python package.

At the time this blog post is written, the Crazyradio crate is full featured. The link is in a good shape and even has a python binding. The Crazyflie lib however is still very much work in progress. I started by implementing the ‘hard’ parts like log and param but more directly useful part like set-points (what is needed to actually fly the Crazyflie) are not implemented yet.

## Compiling to the web: Wasm

One of the nice property of Rust is that compiling to different platform is generally easy and seemless. For instance, all the crates talked about previously will compile and run on Windows/Mac/Linux without any modification including the Python binding using only the standard Rust install. One of the Rust supported platform is a bit more special and interesting compared to the other though: WebAssembly.

WebAssembly is a virtual machine that is designed to be targeted by system programming language like C/C++ and Rust. It can be used in standalone (a bit like the Java VM) as well as in a web browses. All modern web browser supports and can run WebAssembly code. WebAssembly can be called from JavaScript.

The WebAssembly in the web is unfortunately not as easy to target as the native Windows/Mac/Linux: WebAssembly does not support threading yet, USB access needs to be handled via WebUSB and since we run in a web browser from JavaScript we have to follow some rules inherited from it. The most important being that the program can never block (ie. std::sync::Mutex shall not be used, I have tried ….).

I made two major modification to my existing code in order to make it possible to run in a web browser:

• crazyflie-link and crazyflie-lib have been re-implemented using Rust async/await. This means that there is no thread needed and Rust async/await interfaces almost seamlessly with Javascript’s promises. The link and lib still compile and work well on native platforms.
• I have created a new crate named crazyradio-webusb (not uploaded yet at the release of this post) that exposes the same API as the crazyradio crates but using WebUSB to communicate with the Crazyradio.

To support the web, the relationship between the crates becomes as follow:

The main goal is to keep the crazyflie-lib and crazyflie-link unmodified. Support for the Crazyradio in native and on the web is handled by two crates that exposes the same async API. The crate used is chosen by a compile flag (called Features in the rust world). This architecture could easily be expanded to other platform like Android or iOS.

## Status, demo and future work

I have started getting something working end-to-end in the browser. The lib currently only implements Crazyflie Param and the Log TOC so the current demo scans for Crazyflie, connects the first found Crazyflie and prints the list of parameters with the parameters type and values. It can be found on Crazyflie web client test server. This doesn’t do anything useful now, but I am going to update this server when I make progress, so feel free to visit it in the future :).

Note that WebUSB is currently only implemented by Chromium-based browser so Chrome, Chromium and recent Edge. On Windows you need to install the WinUSB driver for the Crazyradio using Zadig. On Linux/Mac/Android it should work out of the box.

The source code for the Web Client is not pushed on Github yet, once it is, it will be named crazyflie-client-web. It is currently mostly implemented in Rust and it will likely mostly be Rust since it is much easier to stick with one (great!) language. One of the plan is to make a javascript API and to push it on NPM, this will then become a Crazyflie lib usable by anyone on the web from JavaScript (or a bit better, TypeScript …).

My goal for now is to implement a clone of the Crazyflie Client flight control tab on the web. This would provide a nice way to get started with the Crazyflie without having to install anything.

This week we have a guest blog post from Wenda Zhao, Ph.D. candidate at the Dynamic System Lab (with Prof. Angela Schoellig), University of Toronto Institute for Aerospace Studies (UTIAS). Enjoy!

Accurate indoor localization is a crucial enabling capability for indoor robotics. Small and computationally-constrained indoor mobile robots have led researchers to pursue localization methods leveraging low-power and lightweight sensors. Ultra-wideband (UWB) technology, in particular, has been shown to provide sub-meter accurate, high-frequency, obstacle-penetrating ranging measurements that are robust to radio-frequency interference, using tiny integrated circuits. UWB chips have already been included in the latest generations of smartphones (iPhone 12, Samsung Galaxy S21, etc.) with the expectation that they will support faster data transfer and accurate indoor positioning, even in cluttered environments.

In our lab, we show that a Crazyflie nano-quadcopter can stably fly through a cardboard tunnel with only an IMU and UWB tag, from Bitcraze’s Loco Positioning System (LPS), for state estimation. However, it is challenging to achieve a reliable localization performance as we show above. Many factors can reduce the accuracy and reliability of UWB localization, for either two-way ranging (TWR) or time-difference-of-arrival (TDOA) measurements. Non-line-of-sight (NLOS) and multi-path radio propagation can lead to erroneous, spurious measurements (so-called outliers). Even line-of-sight (LOS) UWB measurements exhibit error patterns (i.e., bias), which are typically caused by the UWB antenna’s radiation characteristics. In our recent work, we present an M-estimation-based robust Kalman filter to reduce the influence of outliers and achieve robust UWB localization. We contributed an implementation of the robust Kalman filter for both TWR and TDOA (PR #707 and #745) to Bitcraze’s crazyflie-firmware open-source project.

## Methodology

The conventional Kalman filter, a primary sensor fusion mechanism, is sensitive to measurement outliers due to its minimum mean-square-error (MMSE) criterion. To achieve robust estimation, it is critical to properly handle measurement outliers. We implement a robust M-estimation method to address this problem. Instead of using a least-squares, maximum-likelihood cost function, we use a robust cost function to downweigh the influence of outlier measurements [1]. Compared to Random Sample Consensus (RANSAC) approaches, our method can handle sparse UWB measurements, which are often a challenge for RANSAC.

From the Bayesian maximum-a-posteriori perspective, the Kalman filter state estimation framework can be derived by solving the following minimization problem:

Therein, xk and yk are the system state and measurements at timestep k. Pk and Rk denote the prior covariance and measurement covariance, respectively.  The prior and posteriori estimates are denoted as xk check and xk hat and the measurement function without noise is indicated as g(xk,0). Through Cholesky factorization of Pk and Rk, the original optimization problem is equivalent to

where ex,k,i and ey,k,j are the elements of ex,k and ey,k. To reduce the influence of outliers, we incorporate a robust cost function into the Kalman filter framework as follows:

where rho() could be any robust function (G-M, SC-DCS, Huber, Cauchy, etc.[2]).

By introducing a weight function for the process and measurement uncertainties—with e as input—we can translate the optimization problem into an Iteratively Reweighted Least Squares (IRLS) problem. Then, the optimal posteriori estimate can be computed through iteratively solving the least-squares problem using the robust weights computed from the previous solution. In our implementation, we use the G-M robust cost function and the maximum iteration is set to be two for computational reasons. For further details about the robust Kalman filter, readers are referred to our ICRA/RA-L paper and the onboard firmware (mm_tdoa_robust.c and mm_distance_robust.c).

## Performance

We demonstrate the effectiveness of the robust Kalman filter on-board a Crazyflie 2.1. The Crazyflie is equipped with an IMU and an LPS UWB tag (in TDOA2 mode). With the conventional onboard extended Kalman filter, the drone is affected by measurement outliers and jumps around significantly while trying to hover. In contrast, with the robust Kalman filter, the drone shows a more reliable localization performance.

The robust Kalman filter implementations for UWB TWR and TDOA localization have been included in the crazyflie-firmware master branch as of March 2021 (2021.03 release). This functionality can be turned on by setting a parameter (robustTwr or robustTdoa) in estimator_kalman.c. We encourage LPS users to check out this new functionality.

As we mentioned above, off-the-shelf, low-cost UWB modules also exhibit distinctive and reproducible bias patterns. In our recent work, we devised experiments using the LPS UWB modules and showed that the systematic biases have a strong relationship with the pose of the tag and the anchors as they result from the UWB radio doughnut-shaped antenna pattern. A pre-trained neural network is used to approximate the systematic biases. By combining bias compensation with the robust Kalman filter, we obtain a lightweight, learning-enhanced localization framework that achieves accurate and reliable UWB indoor positioning. We show that our approach runs in real-time and in closed-loop on-board a Crazyflie nano-quadcopter yielding enhanced localization performance for autonomous trajectory tracking. The dataset for the systematic biases in UWB TDOA measurements is available on our Open-source Code & Dataset webpage. We are also currently working on a more comprehensive dataset with IMU, UWB, and optical flow measurements and again based on the Crazyflie platform. So stay tuned!

## Reference

[1] L. Chang, K. Li, and B. Hu, “Huber’s M-estimation-based process uncertainty robust filter for integrated INS/GPS,” IEEE Sensors Journal, 2015, vol. 15, no. 6, pp. 3367–3374.

[2] K. MacTavish and T. D. Barfoot, “At all costs: A comparison of robust cost functions for camera correspondence outliers,” in IEEE Conference on Computer and Robot Vision (CRV). 2015, pp. 62–69.

The authors are with the Dynamic Systems Lab, Institute for Aerospace Studies, University of Toronto, Canada, and affiliated with the Vector Institute for Artificial intelligence in Toronto.

Feel free to contact us if you have any questions or suggestions: wenda.zhao@robotics.utias.utoronto.ca.

<code>@ARTICLE{Zhao2021Learningbased,
author={W. {Zhao} and J. {Panerati} and A. P. {Schoellig}},
title={Learning-based Bias Correction for Time Difference of Arrival Ultra-wideband Localization of Resource-constrained Mobile Robots},
journal={IEEE Robotics and Automation Letters},
volume={6},
number={2},
pages={3639-3646},
year={2021},
publisher={IEEE}
doi={10.1109/LRA.2021.3064199}}
</code>

## Background

In the past couple of weeks we have been busy trying to improve the development interface of the Crazyflie. We want to make developing with and for the platform a more pleasant experience.

We have started looking at the logging- and parameter framework and how to improve it for our users. The aim of this framework is to easily be able to log data from the Crazyflie and to set variables during runtime. Your application can use them to control the behavior of the platform or to receive data about what it is currently up to. As of today, in the firmware there are 227 parameters and 467 logging variables defined.

These logging variables and parameters have been added to the Crazyflie firmware over the course of years. Some are critical infrastructure, needed to be able to write proper applications that interface with the platform. Some are duplicates or were added as debug years ago. Others have in some way outlived their usefulness as the firmware and functionality has moved on. The problem is that we have no way of conveying this information to our users and this is what we are trying to rectify.

## An attempt of stability

We are currently reviewing all of our logging variables and parameters in an attempt to make the situation clearer for our users … and ourselves. We are adding documentation to make the purpose of each individual parameters and logging variables more clear. And we are also dividing them up into two categories: core and non-core.

If a parameter or logging variable is marked as core in the firmware that constitutes a promise that we will try very hard to not remove, rename or in any other way change the behavior of it. The idea is that this variable or parameter can be used in applications without any fear or doubt about it going away.

If a variable or parameter is non-core it does not mean that it is marked for removal. But, it could mean that we need more time to make sure that it is the proper interface for the platform. It means that it could change in some way or in some cases be removed in later firmware releases.

The reason for doing this is twofold: we want to make the Crazyflie interface clearer for our users and we want something that we feel we can maintain and keep an up-to-date documentation of.

## What is the result?

We have introduced a pair of new macros to the firmware, LOG_ADD_CORE and PARAM_ADD_CORE which can be used to mark a parameter or variable as core. When using these we also mandate that there should be a Doxygen comment attached to the macro.

Below is an example from the barometer log group, showing the style of documentation expected and how to mark a logging variable as core. Parameters gets treated in the same way.

/**
* Log group for the barometer
*/
LOG_GROUP_START(baro)

/**
* @brief Altitude above Sea Level [m]
*/

/**
* @brief Temperature [degrees Celsius]
*/

/**
* @brief Air pressure [mbar]
*/

LOG_GROUP_STOP(baro)

We have also added a script In the firmware repository: elf_sanity.py. The script will return data about parameters and logging variables that it is included in a firmware elf. This can be used to count the number of core parameters. If we point it to a newly built Crazyflie elf, after we’ve done our initial review pass of the parameters and variables, we get the result below.

\$ python3 tools/build/elf_sanity.py --core cf2.elf
101 parameters and 78 log vars in elf

To produce a list of the parameters and variables you can add the --list-params and --list-logs options to the script.

## What is the next step?

Once we have finished our review of the parameters and logging variables we will explore different ways of making the documentation of them available in a clear and accessible way. And we will come up with a scheme for making changes to the set of parameters and variables. Once this is all finished you can expect an update from us.

The end goal of our efforts is making developing for the Crazyflie a smoother process, and we would love to hear from you. What is confusing? What are your pain points? Let us know! So we can do better.

As you have noticed, we talk about the lighthouse positioning a lot these last couple of months ever since we got it out of early release. However, it is good to realize that it is not the only option out there for positioning your Crazyflie! That is why in this blog-post we will lay out possible options and explain how they are different/similar to one another.

## Absolute Positioning / Off-board Pose Estimation

The first we will handle are the use of motion capture systems (MoCap), which resolves around the use of InfraRed cameras and Markers. We use the Qualysis camera ourselves but there are also labs out there that use Vicon or Optitrack. The general idea is that the cameras have an IR-light-emitting LED ring, which are bounced back by reflective markers that are supposed to be on the Crazyflie. These markers can therefore be detected by the same cameras, which pass through the marker positions to an external computer. This computer will have a MoCap program running which will turn these detected markers into a Pose estimate, which will in turn be communicated to the Crazyflie by a Crazyradio PA.

Since that the positioning is estimated by an external computer instead of onboard of the crazyflie, a MoCap positioning system is categorized as an off-board pose estimation using an absolute positioning system. For more information, please check the Motion Capture positioning documentation.

## Absolute Positioning / On-board Pose Estimation

The next category is a bit different and it consists of both the Loco positioning system and the Lighthouse positioning system. Even though these both use beacons/sensors that are placed externally of the Crazyflie, the pose estimation is done all on-board in the firmware of the Crazyflie. So there is no computer that is necessary to communicate the position back to the Crazyflie. Remember that you do need to communicate the reference set-points or high level commands if you are not using the App layer.

Of course there are clear differences in the measurement type. A Crazyflie with the Locodeck attached takes the distance to the externally placed nodes as measured by ultra wide band (UWB) and the Lighthouse deck detects the light plane angles emitted by the Lighthouse Base Stations. However the principle is the same that those raw measurements are used as input to the Extended Kalman filter onboard of the Crazyflie, and outputs the estimated pose after fusing with the IMU measurements.

Therefore these systems can be classified as absolute positioning systems with on-board pose estimation. To learn more please read the Loco and Lighthouse positioning system documentation!

## Relative Positioning / On-board Pose Estimation

It is not necessary to have to setup an external positioning system in your room in order to achieve a form of positioning on the Crazyflie. With the Flowdeck attached, the Crazyflie can measure flows per frame with an optical flow sensor and the height in millimetres with a time of flight sensor. These measurements are then fused together with the IMU within the Extended Kalman filter (see the Flow deck measurement model), which results in a on-board pose estimation.

The most important difference here to note is that positioning estimated by only the Flowdeck, will not result in a absolute positioning estimate but a relative one. Instead of using an external placed system (like MoCap, Lighthouse and Loco) which dictate where the zero position is in XYZ, the start-up position the Crazyflie determines where the origin of the coordinate system is. That is why the Flowdeck is classified as a Relative Positioning System with On-board Pose Estimation.

## IMU-only On-board Pose Estimation ?

Oh boy… that is a different story. Theoretically it could be possible by using the onboard accelerometers of the crazyflie and fusing those in some short of estimator, however practice has shown that the Crazyflie’s accelerometers are too noisy to result in any good pose estimation… We haven’t seen any work that has been successfully to achieve any stable hover on only the IMU of the Crazyflie, but if you have done/see research that has, please let us know!

And if you would like to give a go yourself and build an estimator that is able to do this, please check out the new out of tree build functionality for estimators. This is still work in progress so it might have some bugs, but it should enable you to plugin in your own estimator separate from the Crazyflie firmware ;)

## Documentation

We try to keep keep all the information of all our positioning systems on our website. So check out the positioning system overview page to be referred to more details if you would be interested in a particular system that fits your requirements!

A little while ago we made a blog post talking about the communication reliability, one part of this work did include an alternative CRTP link implementation for the Crazyflie lib. This week we will make one of the native CRTP link implementations, the Crazyflie-link-Cpp, the default link for the Crazyflie python lib.

In the Crazyflie communication stack, the CRTP link is the piece of software that handles reliable packet communication between a computer and the Crazyflie. In the Crazyflie it is mainly implemented in the nRF51 radio chip (for the radio link), in the computer it is part of the Crazyflie python lib + Crazyflie client and for Ros and Crazyswarm it is implemented in crazyflie-cpp. Other clients like Lamouchefolle also have re-implemented their own versions of the CRTP link.

The CRTP link is the most critical part in the communication with Crazyflie, if it is not working properly, nothing can work properly, all communication with the Crazyflie passes though the CRTP link. This code duplication in multiple projects means that we have many places for diverging behaviour and creative bugs which makes it hard to develop new clients for the Crazyflie.

One way we are trying to solve this problem is to unify the links: let’s try to use the same link in all the clients. In order to do so we need a link that can act as a minimum common denominator: it needs to work with Python in order to accommodate the Crazyflie Python lib, work with C++ for Crazyswarm and LaMoucheFolle and be high-performance to be able to handle swarms of Crazyflies. The C++ link implementation can full-fill all these requirements using a python binding, and it will give higher performance to the Python lib.

Switching to the native C++ link will give us a lot of benefits:

• It is higher performance, it has about 20% higher packet throughput than the pure python implementation
• It will unify the Python lib and Crazyswarm a bit more. Crazyswarm will be able to use the same link as soon as broadcast packet support is added.

The biggest drawback so far is that the CPP link needs to be compiled for each platform. We are compiling a python Wheel for it in Github actions for Windows/Mac/Linux on X86_64, any other architecture (including raspberry pi) will use the existing python CRTP link for the time being.

We are in the process of enabling the new link as the default in the lib. There are still some outstanding bugs related to boot loading that needs to be ironed out, but we expect this change to be included in the next release.

When I was started my Robotics Master back in 2012, I remembered how frustrated I was at the time to setup my development environment in Windows for the C++ beginners course. My memory is a bit fuzzy of course but I remembered it took me days to get all the right drivers, g++ libraries right, and to setup all in the path environmental in Eclipse at the time. Once I started working on Ubuntu for my Master thesis, forced to due to ROS, I was hooked and swore I will never go back to Windows for robotics development again… until now!

I always used Windows on my personal machine on the side for gaming and have a dual-boot on the work computer for some occasional video editing, but especially I had begun to learn game development for Fun Fridays, I started to be drawn to the windows side of the dual boot more and more. But if I needed to try something out on the Crazyflie or needed to debug a problem on the forum, I needed to restart the computer to switch operating systems and that was starting to become a pain! Slowly but steadily I tried out several aspects of the crazyflie ecosystem for development on Windows 10 and actually…. it is not so traumatic as it was almost 10 years ago.

## Python Library and Client

It went quite smooth when I first try to install python on windows again. Adding it to the PATH environment variable is still very important but luckily the new install manager provides that as an option. Moreover, Visual Studio Code also provides the possibility to switch between python environments so that you try different versions of python, but for now version 3.8 was plenty for me.

With the newest versions of the Windows install of Python, pip is by definition already installed, but I experienced that it would still be necessary to upgrade pip by typing the following in either a Command Prompt or (my favorite) Powershell:

python -m pip install --upgrade pip

After this, install the cflib from release was quite an ease (‘pip install cflib’) but even installing it from source with Git configured on Windows was no problem at all and very similar to a native Ubuntu install.

Until recently the cfclient was a bit more challenging to install through pip from due the SDL2 windows library had to be downloaded separately, so the only options would have been installing from source or the .exe application release. The later has not been updated since the 2020.09 release due to building errors. Luckily, with the latest release, this has now been fixed as a SLD2 python library was found. Now the cfclient can be installed with a simple ‘pip install cfclient’.

## Firmware Building with WSL

The firmware development was the next thing that I tried to get up and running, which managed to be slightly trickier. About a year ago I tried to get Cygwin to work on Windows, but my bad memories of the past came back due to the clunkiness of it all and I abandoned it again. Also there are some reported issues with the out-of-tree build (aka the App layer). Some colleagues at Bitcraze already mentioned the Windows Subsystem for Linux (WSL) but I never really looked at it until the need came to move back to Windows for development. And I must say, I wish I had tried it out a while ago.

With some repositories downloaded already on my Windows system with Git, I installed Ubuntu 20.04 WSL, got the appropriate gcc libraries and accessed the crazyflie-firmware by ‘cd /mnt/c/my/repos‘. Building the firmware with ‘make all’ went pretty okay… although it took about a minute which is a little long compared to the 20 secs on the native Ubuntu install. The big problem was that I could not use Docker and the handy bitcraze toolbelt due to the WSL version still being 1. These functionalities were only available for version 2 so I went ahead and upgraded the WSL and linked it to docker desktop. But after upgrading, building the firmware from that same repository on the C:/ drive took insanely long (almost 10 minutes). So I switched back the WSL ubuntu 20.04 to version 1, installed a second WSL (this time Ubuntu 18.04), updated that one to WSL2 and used solely for docker and toolbelt purposes. Not ideal quite yet… but luckily with visual studio code it is very easy to switch the WSL .

But there is more though! Recently I timed how long it took to build the crazyflie-firmware with ‘make all -j8’ from both WSL version in a repository that is on the C:/ drive on Windows (accessible by /mnt/c from the WLS), or from a repository on the local file system:

• WSL 2 (ubuntu 18.04)
• C:/ = 11m06s
• WSL local = 00m19s
• WSL 1 (ubuntu 20.04)
• C:/ = 01m04s
• WSL local = 00m59s

This is done on an Windows laptop with an i7-6700HQ with 32 Gb RAM. The differences with WLS2 between build firmware on the windows file system or the local WSL file system is huge! So that means that the right way is to have WSL2 with the repo on the WSL file system, which is similar to build time as a native install of Ubuntu.

## Flashing the Crazyflie

The main issue still with WSL is that it does not allow USB access… So even if the crazyradio driver is installed on windows with Zadig, you will not be able to see if you type ‘lsusb‘ in WSL for both version 1 and 2. So when I still had the repository on the C:/ drive and build the crazyflie-firmware from there I could flash the Crazyflie through the Cfclient or Cflib (with cfloader) through Powershell, but building it from the local subsystem, which is way faster for WSL2, would require to first copy the cf2.bin file to my C drive before doing that.

Another option, although still in Alpha phase, is to use the experimental Crazyradio server for WSL made by Arnaud, for which the user instructions can be found in an issue thread only for now. The important thing is that the Zadig installed driver has to be switched to WinUSB and switched back again to LibUSB if you want to use the Cfclient on windows. It would still needs some work to improve the user experience but gives promise of better integration of WSL development for the Crazyflie.

## To Conclude

Soon I’m planning to soon reinstall the Windows part on the dual boot laptop but there are already some things that I will integrate on my freshly installed Windows based on what I experienced so far:

• Keep using Python on windows and install the Cfclient and Cflib by pip only.
• Only use Ubunu 20.04 as WSL2 and install the Crazyflie-firmware on the WSL local file system.
• Use Visual Studio Code as the editor for both C:/ based and WSL based repos.
• Use the Crazyradio server or copy the bin file to C:/ whenever I need to flash the crazyflie with development firmware.

For any AIdeck development, I would still need to use the native Ubuntu part or the bitcraze-VM since there is not a USB access or server yet for the programmer. However, if Windows would support USB devices and a graphical interface for WSL, that will make all our Windows-based Crazyflie development dreams come true!


text:
0
Research Papers: Gas Turbines: Combustion, Fuels, and Emissions

# Gas Turbine Engine Emissions—Part I: Volatile Organic Compounds and Nitrogen Oxides

[+] Author and Article Information
Michael T. Timko

Aerodyne Research Inc., 45 Manning Road, Billerica, MA 01821-3976timko@aerodyne.com

Scott C. Herndon, Ezra C. Wood, Timothy B. Onasch, Megan J. Northway, John T. Jayne, Manjula R. Canagaratna, Richard C. Miake-Lye

Aerodyne Research Inc., 45 Manning Road, Billerica, MA 01821-3976

W. Berk Knighton

Department of Chemistry, Montana State University, P.O. Box 173400, Bozeman, MT 59717-3400

J. Eng. Gas Turbines Power 132(6), 061504 (Mar 19, 2010) (14 pages) doi:10.1115/1.4000131 History: Received April 13, 2009; Revised July 07, 2009; Published March 19, 2010

## Abstract

The potential human health and environmental impacts of aircraft gas turbine engine emissions during normal airport operation are issues of growing concern. During the JETS/Aircraft Particle Emissions eXperiment(APEX)-2 and APEX-3 field campaigns, we performed an extensive series of gas phase and particulate emissions measurements of on-wing gas turbine engines. In all, nine different CFM56 style engines (including both CFM56-3B1 and -7B22 models) and seven additional engines (two RB211-535E4-B engines, three AE3007 engines, one PW4158, and one CJ6108A) were studied to evaluate engine-to-engine variability. Specific gas-phase measurements include $NO2$, NO, and total $NOx$, HCHO, $C2H4$, CO, and a range of volatile organic compounds (e.g., benzene, styrene, toluene, naphthalene). A number of broad conclusions can be made based on the gas-phase data set: (1) field measurements of gas-phase emission indices (EIs) are generally consistent with ICAO certification values; (2) speciation of gas phase $NOx$ between NO and $NO2$ is reproducible for different engine types and favors $NO2$ at low power (and low fuel flow rate) and NO at high power (high fuel flow rate); (3) emission indices of gas-phase organic compounds and CO decrease rapidly with increasing fuel flow rate; (4) plotting EI-CO or volatile organic compound EIs against fuel flow rate collapses much of the variability between the different engines, with one exception (AE3007); (5) HCHO, ethylene, acetaldehyde, and propene are the most abundant volatile organic compounds present in the exhaust gases that we can detect, independent of engine technology differences. Empirical correlations accurate to within 30% and based on the publicly available engine parameters are presented for estimating EI-$NOx$ and EI-$NO2$. Engine-to-engine variability, unavailability of combustor input conditions, changing ambient temperatures, and complex reaction dynamics limit the accuracy of global correlations for CO or volatile organic compound EIs.

<>

## Figures

Figure 1

Comparison of 1 m and >15 m EI-NO2 data for an engine, which showed a large discrepancy (CJ6108A/N616NA), and one that did not (RB211-535E4-B/N74856)

Figure 2

NOx speciation for (a) RB211-535E4-B and (b) CJ6108A engines. ICAO data points (▶◀) are shown for reference.

Figure 3

Emission indices of several representative volatile organic compounds measured during the engine tests (a) EIs for formaldehyde, benzene, and naphthalene plotted as functions of engine power for a CFM56–3B1 engine (N353SW). (b) Relative ratios of important volatile organic compound emissions for several representative engines operating at idle for the measurement suite available to us.

Figure 4

Emission indices of gaseous pollutants plotted as functions of fuel flow rate for APEX-2/3 engines: (a) NO; (b) the NO2/NOx emission index ratio; (c) acetaldehyde, a representative volatile organic compound. Lines are shown to guide the eye and are not intended to convey physical significance.

Figure 5

EIm-NOx data for the CFM56 engines: (a) EIm-NOx plotted against power condition; (b) EIm-NOx plotted against fuel flow rate to remove engine-to-engine variability for CFM56 type engines

Figure 7

Comparison of (a) CO and (b) HCHO measurements with the correlations of Eqs. 7,8, respectively. Each data point is the average of all available replicate measurements at a given set of conditions (i.e., sample rake, power, etc.). Error bars are defined in the text. The CJ6108A (△) is an outlier in both regressions, as is the first plane in APEX-3 (▲, N14324). Values of best-fit parameters are listed in the figure and in Table 6.

Figure 6

Comparison of nitrogen oxide measurements to the Eq. 6 fit: (a) NOx; (b) NO2. Each data point is the average of all available replicate measurements at a given set of conditions (i.e., sample rake, power, etc.). Error bars are defined in the text. EI-NO2 was divided into two regimes based on power, ≤45% and >45%. Values of best-fit parameters are listed in Table 6. CJ6108A (not shown) is an outlier in the NO2 analysis.

## Related

Some tools below are only available to our subscribers or users with an online account.

### Related Content

Customize your page view by dragging and repositioning the boxes below.

Related Journal Articles
Related Proceedings Articles
Related eBook Content
Topic Collections


text:
This is a complete (I believe) data set on Correlates of War states and Gleditsch-Ward states, a byproduct of a full_join() between gw_states and cow_states that leans largely on the state abbreviation variable.

Usage

cow_gw_years

Format

A data frame with 16936 observations on the following 6 variables.

gwcode

a Gleditsch-Ward state code

stateabb

the state abbreviation, which was the greatest source of agreement between both data sets

gw_statename

the state name as it appears in the Gleditsch-Ward data

ccode

a Correlates of War state code

cow_statename

the state name as it appears in the Correlates of War data

year

a numeric vector for the year

Details

The data-raw directory on the project's Github contains more information about how these data were created. I'm going to use it for internal stuff. The workflow is going to treat the Correlates of War state system membership codes as more of the "master" codes, for which the user can add Gleditsch-Ward identifiers as they see fit. Data are extended to 2020, assuming no changes to state system membership for either data set.


text:
2-cocycle on LSU(2)

$SU(2)$ is a Lie group, with a Lie algebra $\mathfrak{su}(2)$. I now consider the loop group $LSU(2) = \{ \gamma: S^1 \to SU(2); \gamma \mathrm{ smooth} \}$. It is well-known that there exists non-trivial 2-cocycles on it, obtained from the invariant bilinear form on $\mathfrak{su}(2)$ (see Pressley and Segal for example).

The 2-cocycle on the Lie-algebra is very simple to write. However, the 2-cocycles on the group are rarely written explicitly. I know that it may be quite difficult for general groups but what about a group as "simple" as SU(2) ?

Does anybody an "explicit" expression of 2-cocycles on $LSU(2)$ such that, if I have an explicit expression of two loops $\gamma_1$ and $\gamma_2$ on SU(2), I can put it directly on Maple or Mathematica (or evaluate by hand) ?

EDIT: I precise my question. Consider paths in SU(2) parametrized for example by $$\gamma( \theta) = \begin{pmatrix} cos \phi(\theta) e^{i\alpha(\theta)} & -\sin \phi(\theta) e^{-i\beta(\theta)} \\\\ \sin \phi(\theta) e^{i\beta(\theta)} & cos \phi(\theta) e^{-i\alpha(\theta)} \end{pmatrix}$$ where $\alpha$, $\beta(\theta)$ and $\phi(\theta)$ are smooth $2\pi$-periodic functions. Could someone write a non-trivial 2-cocycle using integral formulas over these functions. It should be simple but I do not manage to write it down. Maybe this parametrization is not the best one; in this case, what is the most useful one ?

-
Could you please clarify what you mean by 2-cocycles on a loop group? Do you mean a smooth map $LG \times LG \to A$ satisfying the cocycle condition? What is $A$? – Konrad Waldorf Mar 7 '12 at 10:14
I mean a (smooth) map $\omega: LG\times LG \to \mathbb{C}^\times$ that satisfies the 2-co-cycle property. The Lie algebra $L\mathfrak{g}$ has an easy non-trivial 2-cocycle given by $$\kappa(\gamma_1,\gamma_2) = \int \langle \gamma_1(\theta), \gamma'_2(\theta)\rangle d\theta$$ where $\langle \cdot,\cdot\rangle$ is left-action invariant bilinear form on $L\mathfrak{g}$. The question is: is there a similar and --more important-- explicit (as much as possible) formula for the 2-co-cycle on $LG$. – Damien S. Mar 7 '12 at 16:26
The map $\omega:LG\times LG\to \mathbb S^1$ cannot be chosen continuous. There are two ways of dealing with that situation: either you take it to be (piecewise smooth) discontinuous, or you take it to be smooth but multivalued. The second definition of cocycle is somewhat more technical, but I think more powerful. – André Henriques Mar 7 '12 at 16:38

-
Thank you for your comment. I think there may be a link between the two questions but I come from analysis and not algebra: I do not understand what "tame symbol" means at all. Could you help me translate in the present case in terms of integrals, please ? Damien. – Damien S. Mar 6 '12 at 16:35
Dear André, could please consider my edit and clarify the link ? – Damien S. Mar 7 '12 at 8:37
@Damien : i think that your answer is in the question posed by André, who asks for an algebraic version of the central extension that he explicitly describes for the smooth case in the body of the question. – BS. Mar 7 '12 at 11:13
That is correct. The answer is in the question. – André Henriques Mar 7 '12 at 13:43
Damien: The stuff that MacNamara wrote is not what you should be looking at. The answer is the big expression with the two integrals. – André Henriques Mar 7 '12 at 16:35

I second André's comment that one cannot expect interesting, smooth 2-cocycles $\omega: LG \times LG \to S^1$. The situation for Lie groups is simply different to the one for Lie algebras: central Lie algebra extensions $$0 \to \mathfrak{a} \to \widehat{\mathfrak{g}} \to \mathfrak{g} \to 0$$ can be classified by cocycles $\kappa: \mathfrak{g} \times \mathfrak{g} \to \mathfrak{a}$ forming the Lie algebra cohomology $H^2(\mathfrak{g},\mathfrak{a})$. Lie group extensions $$1 \to A \to \widehat{G} \to G \to 1$$ that are classified by smooth cocycles $\omega:G \times G \to A$ are precisely those that are trivializable as principal $A$-bundles over $G$.

General central Lie group extensions are classified by Segal-Mitchison-Brylinski group cohomology $H^2_{SMB}(G,A)$. The 2-cocycles there involve open covers $\mathcal{U}^k$ of $G^k=G \times ...\times G$, compatible with the face maps of the simplicial manifold $G^*$, and smooth maps $$g_{\alpha\beta}: U_{\alpha}^1 \cap U_{\beta}^1 \to A \quad\text{and}\quad h_{\alpha}: U_\alpha^2 \to A$$ satisfying various conditions. ($g_{\alpha\beta}$ are the transition functions for $\widehat{G}$ as an $A$-bundle, and $h_{\alpha}$ remembers the multiplication of the Lie group $\widehat G$).

All this is true for Lie groups $G$ just like for loop groups like $LG$. Thus, a smooth 2-cocycle $\omega: LG \times LG \to S^1$ classifies a central extension of $LG$ by the circle that is trivial as a circle bundle over $LG$. For compact, simple, simply-connected Lie groups $G$ it is well-known that such extensions are totally trivial, i.e. $\omega$ must be the coboundary of a smooth map $LG \to S^1$.

-
Thank you for your answers. I understand now my mistakes. I was looking for a 2-cocycle to build the central extension of the loop group, which -- I understand it only today -- cannot be build so easily, due to topological reasons. My question changes now a little bit. How do I describe easily (i.e. in a way understandable by Maple or Mathematica) the group structure of the central extension of $\widetilde{LG}$ and the morphism $\widetilde{LG} \to LG$ ? If I want to be understandable by a machine, I cannot use the existence of homotopies between paths easily for example... – Damien S. Mar 9 '12 at 12:42


text:
## Knowledge Distillation from Few Samples

Sep 27, 2018 Blind Submission readers: everyone Show Bibtex
• Abstract: Current knowledge distillation methods require full training data to distill knowledge from a large "teacher" network to a compact "student" network by matching certain statistics between "teacher" and "student" such as softmax outputs and feature responses. This is not only time-consuming but also inconsistent with human cognition in which children can learn knowledge from adults with few examples. This paper proposes a novel and simple method for knowledge distillation from few samples. Taking the assumption that both "teacher" and "student" have the same feature map sizes at each corresponding block, we add a $1\times 1$ conv-layer at the end of each block in the student-net, and align the block-level outputs between "teacher" and "student" by estimating the parameters of the added layer with limited samples. We prove that the added layer can be absorbed/merged into the previous conv-layer \hl{to formulate a new conv-layer with the same size of parameters and computation cost as previous one. Experiments verifies that the proposed method is very efficient and effective to distill knowledge from teacher-net to student-net constructing in different ways on various datasets.
• Keywords: knowledge distillation, few-sample learning, network compression
• TL;DR: This paper proposes a novel and simple method for knowledge distillation from few samples.
0 Replies