ELEC 424 Final Project Report

Indoor Assistant

Team members: Jie Liao, Zhenyu Guo, Jieting Yang

1. Problem statements

Our proposal is to build an indoor assistant depending on the crazyflie after some change

for the original proposal. As for indoor assistant, which may also be developed for outdoor

detection and alerting, our crazyflie is the prototype of emergency detecting devices such as

detecting the position smokes or potential fires caused by electronic wires indoor at some

locations where people may not usually pay attention to. These devices can also fly as crazyflie

does and carry not only range sensors but gas sensor or biological sensors as well. After previous labs, we have known basic concepts and knowledge of the micro

controllers with Cortex-M3 core, also we have known about the crazyflie firmware and how to

control crazyflie actions between crazyflie and pc client. For this project, we plan to place two

range sensors on the crazyflie, one is to measure its height from ground to keep it flying at certain

altitude and the other is to measure the distance to the obstacles in front of its moving direction so

that it can avoid them before heading and colliding them. In the original proposal, we’d also like

to ad RF sensors to send simple command to control the movement of the crazyflie, but finally we

found it’s hard to do so because of the weight, battery and IO problems. So we only implement

two range sensors which have already been heavy enough to consume a lot battery power in a

short time, but still it fit our original thoughts. There are several steps with several challenges for us to go through all this way. First we

need to connect the sensor with the crazyflie board and choose the right I/O ports as signal inputs.

The second thing is that we can read the sensors’ values in the firmware code so that we are able

to send whichever type of sensor values to pc client. Sending data to pc client form firmware

should be easy after doing lab4 and lab5. The last thing is to control the thrust according to the

sensed altitude and horizontal distance, as well as the battery power consumption. Hopefully the

final scenario would be the crazyflie hanging over indoor automatically and avoiding walls or

furniture ahead of it.

2. Physical Design

a. Sensors

We use two same sensors: Maxbotic Ultorasonic Rangefiner-HRLV-EZ0, the vendor’s

description can be found here: http://www.adafruit.com/products/983. This sensor has very high

precision whose higheset resolution is 1mm (however it turned out to that we don’t actually need

that high resolution, and as a bad result the processing time of such high resolution sensor is very

much longer than imagined.). It has seven ports, two power supplies and four kinds of output

ports. The power supply can consume voltage from 2.5 V to 5.5 V. We use the analog output as

our input to the micro controller, the analog output voltage represent the sensed ranges varying

from 30 cm to 500cm, the value of the ranges is proportional to the analog output voltage

according to what scale factors we use. The processing time of this kind of sensor should be 100

ms which is much longer than those sensor that don’t have such high precision or resolution. The

nominal current draw of the sensor it around 2 mA under our power supply which is 2.818V

taken from the board supporting ports. The processing time and the current dray caused us two

major problems which will be stated in following report.

b. Component connect

Because we use analog output from sensor as the input signal for the micro controller, we

need ADC in the MCU to convert the analog signal to digital signal so that the firmware can

read it. The figure below show how we connect the two range sensors:

Fig 1. Sensor connection to the IO pins of the quadcopter

STM32F103cbt6 chip has three ADCs, each of them share some channels with the other

two. Here we use ADC2 and its 6th and 7th channels corresponding to pin 14 and pin 12 which are

left unconnected on the crazyflie board for extra usage. We left the 4th pin of the sensors open to

keep the sensor continuously sensing. The pin 19 and pin 20 are the power VCC and GND for the

two sensors, as we verified when the sensors are working these two pins can provide very stable

2.181V voltages. Instead of connecting the analog outputs directly to IO PA6 and PA7, we add

two resisters between them. We will discuss details about the resisters below.

c. Repairing broken part

Doing project with quadrotor, we usually can’t avoid destroy some parts of the board or

motors. We did broke some motors which are easily to repair by soldering following instructions

on website. And we also broken one of the arms of the board several times, after two times of

repairing, we found that twining some light threads around the broken position and gluing them

together can make the arm as strong as before. The only shortness is that it would be inconvenient

to replace motors on that motor. The whole view of our crazyflie is as below:

Fig 2. The whole view of our crazyflie carrying two range sensors

3. Methods

a. Firmware implementation

As we discuss at the beginning, after connecting the sensors we need to read the analog

inputs and convert them to digital values. We did so by firstly add extra variable in the typedef

structure in adc.h file. We added two range variables in the structure and include them in adc.c

file. In adc.c file, we configured GPIO PA6 and PA7 as analog input and ADC read the analog

values from them. We configured three channels for both ADC1 and ADC2, and kept the original

ADC channels and only modify two extra channels, we set the sampling period as 13.5 cycles. In

adcTask function, we added the update function for sensor ADCs and use the pre-defined scale

factor (in adc.h file) to output the sensed value. As did in lab5, we use parameter to log these

values to pc client named adc.sensor_up and adc.sensor_down.

b. Pc client implementation

At pc side, we just need to use call back functions to call back adc.sensor_up and

adc.sensor_down every time when automatic running is launched. The range values are converted

to integers and 1 value represents 1 mm . We didn’t add complicated computation and evaluation

process for the sensed range to control the altitude end moving direction. Because our sensors

have very long processing time, which makes it unlikely to implement a lot of calculations for the

sensed ranges. So we did the simplest thing to set specific lower bound and upper bound of the

height, and if the crazyflie flies over the upper bound then the thrust will be decreased, on the

other hand if it flies below the lower bound the thrust will be increased. Firstly we also plan to

define a special state in which the height crazyflie is flying is below the minimum sensor range so

that it will land off and motors stop spinning. But this turn out to be not so helpful because each

time when the battery cannot support the board and the crazyflie drops down to below like 35 cm

it will not rise again, most likely because of the long processing time of sensors and much power

consumption of the whole system. As for the moving direction control, the following figure can

explain something:

Fig 3. Moving direction control

When the crazyflie is approaching the obstacles ahead of it, it will sense the distance

between them. We set the threshold for changing moving direction is 80 cm. We used a

temporary range variables to store the last time sensed distance, and if the former range is smaller

and 80 cm and the current one is smaller than 75, it indicate that the crazyflie is approaching

toward the obstacle, and the pitch value will be inversed proportionally and yawing will happen.

We cannot decide how much degrees the yawing will conduct though and it’s hard to do so, we

just need the crazyflie to turn around and avoid the obstacles. So that’s the problem of tuning the

yawing strength and the pitching speed. We also tried to add the pitch and roll rate errors to

evaluate the moving status, saying that if the pitch and roll rate errors are too high then maybe the

crazyflie is not so stable so we decrease the pitch value to make it move slower. But however this

method didn’t seem to work and can cause the crazyflie even more unstable. So finally we

decided to do the simple thing to just turn around when sensed distance is less than threshold.

4. Problems and Solutions

We did met a lot of hardware and software problems and we analyze the cause of them

and tried to fix them. We have fixed most of them and some are listed below:

a. Human interference may stop the motors and sensors from working

At first when we first configure the ADC and GPIOs in firmware, we downloaded the bin

file to the crazyflie and connect the sensors as described in Part 2. When we use the pc client to

test the sensors, we could connect the crazyflie but without seeing any sensor readings or motor

thrust in the client. We thought it might be the problem of the client so we change to the previous

lab and found that the previous labs cannot work either. This gave us a lot of shock, but how does

this happen? Then we thought that the range sensor use ultrasonic signals which may cause some

interference with the signal of radio dongle, but that should not make any sense since they are

different waves. Finally we happened to connect the crazyflie and make it work once by putting it

on the desk for a while, then we realized that this problem may have some relationship with

human factors. Because each time when there are some problems with the crazyflie, we’d always

like to hold it on hand to see what happens, we hardly know that if we let it go, the problem will

be solved. After some tests, we drew three conclusions: Putting the crazyflie alone somewhere

rather than holding them to connect it when this problem occurs usually makes it work; The

crazyflie need some time, usually five to ten seconds to “warm up” after connecting extra sensors

(at least for range sensors); If you connect the crazyflie when holding it on hand, put it

somewhere alone off hand it will go back to normal again after several seconds. The possible

cause of this problem is that every time when the system is connected to the pc client, the

connection between pc client and range sensors need some time to initialize the interval

functionality, in which period the system is sensitive to any obvious movement. So putting the

crazyflie on a stable surface can help the initialization and make the system work properly. As the

tests verified, if the initialization fails, the values of motors and gyroscope and accelerator are not

correctly sent to crazyflie.

b. Direct analog input to MCU may shut down the board

The second problem we met is that after we accidentally shortened the pin 19 and pin20

(power supply for sensors) for several seconds before we noticed that, the crazyflie board will be

shut down several seconds after power on when we connect the sensors to it. We first thought that

the short circuit of pin 19 and pin 20 may burn the interval components, making the battery

unable to support the board. But after we remove the sensors, the board will work again without

suddenly shutting down. Then we noticed that we directly connect the analog output from sensor

to the IO ports of MCU. Generally the GPIO which is set as input especially analog input should

be internally pulled to a very high impedance, but the output of the sensors can cause up to 5 mA

current which is too much for the MCU GPIOs. So we added two resisters respectively before the

analog output from sensors connecting to MCU IO. We tried different size of resisters and

measured the analog input voltage to the MCU GPIOs (current is nearly 0). Finally we used 15k

Ohm resisters, because it’s safer to use larger resisters but larger resisters will divide the output

voltage with the internal inputs of MCU. We tried 1M Ohm resister once and found that the input

is increase to 1/4 VCC on the resister, which means the internal impedance of MCU GPIOs is M

class. We cannot guarantee that the internal impedance if constant or is proportional to the input,

so it’s better not to use too large resisters to guarantee the measure precision. After adding

resisters, we never met the problem of sudden shutting down on the board.

c. ADC sample period

Because we use the high resolution sensors, the processing time of the sensor is a bit

longer than the normal one, which also caused a small problem for us. The sample period of

specific ADC and its channels can be configured separately. We first derived the sample period

used by existing ADC channels in the firmware (28Cycles5), but manually we can feel that the

output from pc client is not so fast reactivated. This causes our crazyflie crash several times

because the sense range is not available the thrust would be decrease greatly when we were

defining the state below 35 cm. Then to accelerate the processing process, we tried to use shorter

sample period, we tried both 7Cyles5 and 13Cyles5. The former cause the two ranges reading

from the pc client are always the same even we only connect one sensor and leave the other open.

We didn’t know exactly the detail about this, but we calculated ADC frequency before that, so

after we check the process time we found maybe it’s because the channels have to read and

process inputs sequentially, one channels cannot complete the whole processing in such a short

period, there may be some mixture. After applying 13Cycles5, we found it’s better than 28Cycles

and 13Cycles.

d. Thrust drops to zero suddenly

We set upper bound and lower bound for altitude control. When the crazyflie exceeds the

upper bound the thrust will be decreased, on the other hand if it’s lower than the lower bound the

thrust will be increased. At the same time to feed the power reduction which is due to constant

consumption, we increase the maxThrust each time we measure the sensors’ ranges. Tuning the

values of increase and decrease can make the crazyflie fly steadily in the air at some height. Our

problem is that we increasing the thrust below the lower bound, it works well, but above the

upper bound, the thrust will suddenly drop to zero when it’s supposed to descend slowly. We

think there may be two possible reasons. One is that we use the same increase and decrease deltas,

but considering the power consumption actually the descending process loses more thrust than the

ascending process gains. So we change the decrease delta of thrust much smaller than the increase

one, which make the case a bit better. Another reason we think is that we use advanced mode in

pc client to set the slew limit to 20, which means once there is no upcoming increase thrust, the

thrust will suddenly decrease to at most 20%. So we change this value more and alternatively we

use the normal mode which has slower slew.

e. The bug that shows 'Native Qt signal is not callabe'

We also met a serious code bug when we tried to change the pitch and yaw values to

change moving directions. The error shows ”Native Qt signal is not callable”. By searching on

the bitcraze, there are solutions: “Among the callbacks registered for self.rp_trim_updated there is

a PyQt4.QtCore.pyqtBoundSignal. This object is not callable”. We need to change the cb(*args)

in lib/cflib/utils/callbacks.py to use emit(), just as cb.emit(*args). It works after the modification.

f. Sensors need time to make reaction when encountering obstacles.

According to the data sheet of our Ultrasonic sensor, the sensor 'reports the latest range

every 100mS'. Therefore, even if the quadcopter goes within the 'turn around' region, it still has to

take some time to make reactions. Our solution to this delay is that we increased the range to 1

meter. Moreover, we made sure that the angle quadcopter turns each time is not too large in order

to give the sensor enough preparation time for the next sensing.

5. Testing Results

Below are some links, we choose some of the testing videos to show the progress we

made each step:

Manual control carrying one sensor:

http://www.youtube.com/watch?v=6W8Wggmgpio

Manual control carrying two sensors:

http://www.youtube.com/watch?v=JSRLMnD16Cc

Automatic control without moving direction：

http://www.youtube.com/watch?v=zrrhOkDvmWE Automatic control with moving direction:

http://www.youtube.com/watch?v=EnkCj2VM4g4

http://www.youtube.com/watch?v=OnrqQdrw9Xg

Final Demo video: http://www.youtube.com/watch?v=JS5xCXZqIP4&feature=youtu.be