blandry / crazyflie-tools Goto Github PK

not sure where these commits are coming from

I think the force of each motor proportional to the square speed of the motor? Similarly for the moment? (saying this after reading your thesis)
Would you please check lines 109 through 116 in estimation/models.py

Amazing work btw. Thanks for sharing.

Note: the plant uses w^2 as input. So take the sqrt of the utraj from the controller before forwarding it, and square the input sent to state estimator.

Hi benoit,
I'm trying to set the motor speed directly from laptop, without internal position control.
So, I have commented "#define POSITION_CONTROL" in the firmware config file, and flashed it.
This is the simpleclient.py incipit:

STARTUP_NANOKONTROL = False
USE_DRAKE_CONTROLLER = False

SE_LISTEN_TO_VICON = True
SE_VICON_CHANNEL = 'vicon_simulator'
SE_PUBLISH_TO_LCM = True
SE_USE_RPYDOT = False
SE_USE_EKF = False
SE_USE_UKF = False
SE_DELAY_COMP = False

CTRL_INPUT_TYPE = 'omegasqu'
CTRL_LISTEN_TO_LCM = True
CTRL_LISTEN_TO_EXTRA_INPUT = False
CTRL_PUBLISH_TO_LCM = False

CTRL_USE_POSITION_CONTROL = False

and this is my test python script:

import lcm
import time
from crazyflie_t import crazyflie_input_t

msg = crazyflie_input_t()
msg.timestamp = 0
msg.input = [10.0, 10.0, 10.0, 10.0]
msg.offset = 2.0
msg.type = "omegasqu"

lc = lcm.LCM()
while True:
lc.publish("crazyflie_input", msg.encode())
time.sleep(.01)

I can't address properly the four motor... for example with this last input configuration it turns only Motor4 of the cf, while other three motors slow down.
It seems that the four double input values are summed and applied to the 4th motor.
Using other configuration everything seems irrational... the second input field correspond to the third motor.

Any idea?

The client has a ways of having a mode switch implemented but it does not broadcast anything to the cf. Also this must start the lcm bridge (or shut it down depending).

Hi

Can't access the Vicon folder.
Can somebody help me?

Thanks

Mauricio

This is a major work item but we should try to rebase of Bitcraze latest firmware.

we need a model for crazyflie. This needs to be done with vicon sensors on and should include

• mass
• Ixx Iyy Izz
• Kf (F=Kf*w^2)
• Km (M=Km*w^2)

Working on this!

Hi @blandry ,
I am using a really simple tracker with kinect and was wondering if it would work if I used the coordinates obtained from kinect to publish on the SE_VICON_CHANNEL , using the firmware2. Thanks!

Would be nice to have a way to enable the vicon broadcasting from the cf client. There is already a checkbox but nothing implemented (will need some way of inputing the object name).

Hi guys,
as you know I flashed the CF2 with your firmware.
I'm trying to obtain imu data... but it seems that the copter doesn't communicate properly with the copter.
Using the console of your modified python client I don't get any CF's bootstrap information (DEBUG_PRINT in system.c).
Otherwise, I can see correctly those infos in the console of a standard python client.

Any idea?

The lcm channel that corresponds to a vicon object should not be named "vicon" but should be named what the object it is broadcasting about is called.

Make a task that listens to mode changes, shuts down what needs to be shut down and starts what needs to be started.

We need a better frame to hold the vicon sensors.

Hi Benoit,

Great work and thanks for sharing! I found your thesis after finding this repository and it is being a great read!

I was wondering which firmware for the CF2.0 you would advise to download and if you had done any tests comparing your firmware against the firmware by bitcraze? do you know if there is any major update they have done comparing to your latest firmware?

I was planning to use your estimator and the model you identified on my application. I am running the whoenig/crazyflie_ros and was interested to improve the controller to do some precise landing and was thinking of running an LQR with your model. In case you have any tips, they would be greatly appreciated!

Thanks a lot!

Best,
José

There is some code to use the nano kontrol as input that should be integrated in the client somehow.

We need to reproduce the logic for the usb driver found here:
https://raw.githubusercontent.com/bitcraze/crazyflie-clients-python/develop/lib/cflib/drivers/crazyradio.py

It created the problem that is discussed here (with a temporary fix):
#21 (comment)

Needs to be renamed, cleaned up of useless code and switched to a different port.

Hi guys,
I'm trying to use your examples script in the openloop directory as a first step, without any result.

Lcm is installed.
The crazyflie is flashed with the firmware in your crazyflie-firmware-2 directory.
simpleclient.py is running (green leds are blink both on the CrazyradioPA and on the Crazyflie).

When I ran the runRampFunction.m in matlab I was expecting some variation on the propeller speed, but nothing happens!

lcm-spy shows correctly a message stream published on the crazyflie_input channel and recognize message's type.

Any idea?

Roberto

The way the firmware gets a version when it compile requires us to do a hack in our distro. Under the firmware folder run

git tag 2014.01.0-11-gead7f60b5ce1
mkdir .git

This should be properly fixed and we should figure out the right convention for version naming.

We need to move the project to robot locomotion group and open source it. Before we do that we must seperate the vicon folder to a private repo (it has proprietary files).

Hi @blandry ,

I am thinking about implementing the differential flatness controller for crazyflie 2.0 based on Mellinger's paper. I used your code as reference, and had some questions about "crazyflie-tools/matlab/invertFlatOutputs.m". Can you give me some insights, so that I can speed up my learning curve?

1. You used [x,y,z,roll,pitch,yaw,xd,yd,zd,rolld,pitchd,yawd] as states, instead of [x,y,z,roll,pitch,yaw,xd,yd,zd,p,q,r] in Mellinger's paper. Why?
2. You get "u = omega_squared" for the controller using differential flatness. Then abandoned it, and used "u = [x(4:6);p,q,r;.25*u1/kF(1)]" instead. Why? And the dimension of u seems to be wrong, because u1 is a scaler.

Thanks,

Li

We need to setup better documentation for installation and usage.

CF2 firmware now finished compiling, with only the warnings as follows:

@blandry help?

modules/src/system.c: In function 'systemTask':

modules/src/system.c:139:3: warning: implicit declaration of function 'commanderInit' [-Wimplicit-function-declaration]
commanderInit();
^
modules/src/system.c:140:3: warning: implicit declaration of function 'stabilizerInit' [-Wimplicit-function-declaration]
stabilizerInit();
^
modules/src/system.c:148:3: warning: implicit declaration of function 'commanderTest' [-Wimplicit-function-declaration]
pass &= commanderTest();
^
modules/src/system.c:149:3: warning: implicit declaration of function 'stabilizerTest' [-Wimplicit-function-declaration]

Euler angles are different in Vicon than in Drake. Need to make sure we have a script to convert between the two.

I somehow lost the LCMBridge code and its not in the repo. It needs to be reimplemented...

@blandry , what are clean1.mat -> clean11.mat for?

Some are empty?

Some notes from Ani:

I recommended using a Luenberger observer. The way I implement it is as follows:

xhat[k+1] = xhat[k] + dt_f(xhat[k],u[k]) + L_(y[k+1] - xhat[k]).

Here, xhat[k] is the state estimate at the kth time step, dt is the time between samples (so the time between k and k+1), f is the dynamics (xdot = f(x,u)), y is the raw measurement (position estimates come from vicon and velocity estimates can be obtained by finite differencing). L is a scalar that you have to tune by hand (something in the range 0.1-0.2 range usually works well for me).

There are a couple of subtle things that I've found helpful in the past:

• It usually helps to use a fixed dt (1/120 for vicon) instead of using the lcm timestamps. The finite differenced velocity estimates are a lot smoother if you do this.
• I usually use the vicon position/angle measurements directly. I use the Luenberger observer only to estimate velocities. So basically I ignore the first six coordinates of xhat[k+1] and take only the last six. The only exception to this is when vicon loses the airplane. Then I use only the model to predict forwards (corresponding to a Luenberger gain of 0).
• You should not use the model at all when the quad is not flying (e.g. when it's on the ground or hit the net). The state estimates will go crazy if you use the model since the model is not valid in these cases.

Hi blandry,
is your vicon repository broken?
It's linked to anything. :/

Let me know.
formica