LPS System - Altitude Hold (z-position) Problem

All discussions related to the Loco Positioning system
Post Reply
tugayalperen
Beginner
Posts: 9
Joined: Mon May 14, 2018 8:33 am

LPS System - Altitude Hold (z-position) Problem

Post by tugayalperen » Wed Sep 05, 2018 6:35 pm

Hi all,

We have LPS system installed in a room, exactly like in the starting guide, coordinates entered correctly (the bottom position of node 0 choosen to be origin, its coordinates seems like (0.0,0.0,0.15). There are 8 nodes, uploaded with the LPS Node Firmware (2018.01). For the time being, they are working on TWR method. When the Crazyflie (2.0, firmware 2018.01 is uploaded) placed in the area, everything seems fine in cfclient (nothing surprising, position estimated with a decent level of error). Yet, when we try to use it in position hold flight mode with a joystick (Logitech Gamepad, all configuration is done correctly and tried with flow deck in a separate experiment, working perfectly, both the deck and crazyflie), crazyflie can not maintain its altitude. Although its performance in x-y wise seems okay, we need to give thrust with in short time periods to maintain its z-position in a certain level. A video showing that behaviour can be seen there: (https://youtu.be/M9DG-QwRv00).
In addition, we decided to try it crazyflie-lib-python, autonomousSequence.py. Yet, there is again a constant problem with altitude. In the link there, you can see the default script running, of course with the correct address adjustment. It is supposed to be drawing a square at the height of 1.2 meters but although x-y coordinates seems fine, altitude changes drastically. (https://youtu.be/PNd5IALyATc)
I suspect that we should use latest version of crazyflie firmware maybe, compiling it in our computer. At that point, I have the question that should we also use the latest firmware for LPS nodes at the same time? Because nodes 2,5 and 7 (placed exactly like in the tutorial) are turning red (as I know, it means it does not emitting TWR responds) are problematic when cf is uploaded with latest version of firmware but nodes are on the 2018.01 firmware. When they both in 2018.01, everything is fine. Is it possible that both firmwares should be at the latest version for a decent result?

Thank you in advance,

albussimba
Beginner
Posts: 3
Joined: Sat Sep 01, 2018 3:31 pm

Re: LPS System - Altitude Hold (z-position) Problem

Post by albussimba » Thu Sep 06, 2018 12:40 pm

I have the same issue too. But these are my thoughts and maybe you can try to recreate them not sure if it would help.

1) improper calibration of anchors and blind spots
Not sure if there is any available scripts to calibrate the anchors automatically. I also notice the x and y position is some what during flight using TWR but i think its due to the sensors calibration.
2) slow increments to get to the targeted position
I have tried this seems promising but my x and y position is really off for some reason, I have tried increments of 0.1, 0.5 and 1. seems like 0.1 gives less altitude drop.

mehmetyldz87
Beginner
Posts: 3
Joined: Wed Mar 14, 2018 6:19 pm

Re: LPS System - Altitude Hold (z-position) Problem

Post by mehmetyldz87 » Thu Sep 06, 2018 8:47 pm

In wiki page, Position hold is described like that " Keeps the Crazyflie at its current 3D position. Pitch/Roll/Thrust control becomes X/Y/Z velocity control". But it is not working properly with LPS ( with flowdeck works well). Also Altitude hold mode has same problem with LPS. We need support for this issue . Thanks

kristoffer
Bitcraze
Posts: 84
Joined: Tue Jun 30, 2015 7:47 am

Re: LPS System - Altitude Hold (z-position) Problem

Post by kristoffer » Mon Sep 10, 2018 9:17 am

The first step is to make sure the positioning system is working properly, without good positioning information the Crazyflie will not be able to do a good job.
You say "nodes 2,5 and 7 (placed exactly like in the tutorial) are turning red" - this is the first thing to address. Even though TWR is fairly forgiving it will work better with more anchors, since nodes 2,5 and 7 are all in the top layer, the Crazyflie gets very little Z-information. From your videos it looks like your system is fairly large and an initial test could be to move the anchors closer to see if you can get full anchor coverage. In TWR you can fly outside the convex hull of the anchors, so it will probably not limit the flying space.

It sounds (in the video) like the propellers on your Crazyflie is a bit unbalanced and fixing this would probably make a difference for the Z-position as well (see https://www.bitcraze.io/balancing-propellers/). Unbalanced propellers creates vibrations that creates noise in the accelerometers and this noise makes it harder for the kalman filter in the Crazyflie to estimate the position.

When you are flying with position hold I suspect that your gamepad either has an offset in Z (thrust) and is continuously feeding a small negative Z value or it is caused by vibrations from the propellers. As you mention it is actually velocity control and not tightly connected to the position.

Regarding versions of anchor firmware/Crazyflie firmware/client I suggest either going for an official release or the latest version from github through out the full system. We try to stay backwards compatible but in some cases it is not possible.

Please let me know the results

tugayalperen
Beginner
Posts: 9
Joined: Mon May 14, 2018 8:33 am

Re: LPS System - Altitude Hold (z-position) Problem

Post by tugayalperen » Thu Sep 13, 2018 9:15 pm

Hi kristoffer,

After some trials, I want to explain you the situation we are in now. First of all, I upgraded the crazyflies' and nodes' firmwares to the latest one, I compiled and uploaded them. There is no connectivity issue right now, everything is fine and green, both in TWR and TDoA modes. As a second test, aiming to test if there is any mechanical issue (like propeller unbalance) at crazyflies, we have tried it with [only] optic flow deck. Here in the video you can see the result, tested with same configuration : (https://www.youtube.com/watch?v=IXXAdimlw6E). Here it executing a script from crazyflie-lib-python, involving motion commander functionalities. As you can conclude also, there is no problem about propellers or crazyflie itself, in a mechanical manner. In addition to script, we try [only] optic flow configuration with position hold mode with client. It was also great. After, we have conducted a similar test to understand performance with LPS, tried the position hold mode, from client. As you can see in the video (https://www.youtube.com/watch?v=Rdm_cprTjas), it also seems okay to me. Yet, there is an issue about it. Its performance is not the same throughout the arena, its stability is changing drastically. In order to visualize it, I have recorded two videos, the first one (https://www.youtube.com/watch?v=IqsOVTUO2Ho), supposed to take-off, go on a straight line with no change on altitude, then land. The stability problem is more obvious here. In addition, I have modified the swarmSequence.py script, in order to use the system with TDoA mode, because eventually we have to use this mode since we will hopefully fly 4 cfs at the same time. With this modification, only one crazyflie, supposed to draw a square of 2 meters, at same altitude and land (https://www.youtube.com/watch?v=jcgA9qLuruo). Here, the stability issue again rises.

At that point, I wanted to turn my face to basics, can localization system gives accurate and precise outputs in TDoA mode? When it comes to precision, it is not that bad, at least while crazyflie is stationary. The values are ranging in a 15 cm span, at worst case. Although, I can not say the same thing for accuracy. For example, when I place a cf in the ground, x = 0.6m, y = 0.6m and z = 0.0 m (in my coordinate system), the values that I see is around x = 0.25 m, y = 1.2m and z = -0.15 m. The same deviation exists for 1m x 1m on the ground. When I reach the 2m x 2m, the values are getting logical, yet only in a small area in the whole arena. Let me say the worst, when I go near the node number 5 (imagine the configuration in tutorial), z value says it is -1.5 m, when it is on the ground, x and y deviations still occur. Not to be drowned in details, the sum is like that, positioning information is not accurate, its changing around the arena in a non-linear fashion (not a constant offset). Only in a small part, the positioning info might get a bit accurate.

Finally, I want to show you the installation of the system, in the pictures. The dimensions also can be seen.
--------------------------------------------
https://ibb.co/mb8WUp
https://ibb.co/f9zuh9
https://ibb.co/d2RJ9p
https://ibb.co/mBwUFU
https://ibb.co/ikvOaU
https://ibb.co/fobUFU
---------------------------------------------------
We tried to measure node to node distance as accurate as possible, but I wonder, what kind of correctness do we need? Couple of centimeter measurement error is okay, or do we really need a millimeter accuracy? There are pipes at the ceiling of our lab, and unfortunately they are covered with aluminum. Can this situation effect the system that much? If we change the node numeration to something different from tutorial, can it help? Do you have any suggestion, something different to try, to have a better positioning?

Thanks in advance,

kristoffer
Bitcraze
Posts: 84
Joined: Tue Jun 30, 2015 7:47 am

Re: LPS System - Altitude Hold (z-position) Problem

Post by kristoffer » Fri Sep 14, 2018 12:45 pm

Thanks for the extensive reply and a lot of useful information!
Unfortunately I do not have a quick answer to you problem so I think we will have to do some more testing to try to figure out the root cause.

First of all some answers to your questions and random thoughts:
aiming to test if there is any mechanical issue (like propeller unbalance) at crazyflies, we have tried it with [only] optic flow deck
The position estimator uses a kalman filter to fuse information from all available sensors in the Crayzflie and decks. All sensors have different noise levels and the estimator is designed to rely more on sensors with low noise than sensors with more noise. The noise level used in the kalman filter for each sensor is hard coded in the firmware. A sensor with a low noise level will be more dominant in the estimated position than a sensor that is more noisy. Unbalanced propellers increase the noise in the accelerometer data due to vibrations. The Flow deck sensor is very good and will be more dominant than the accelerometer data, while when flying with the LPS system the LPS data is much more noisy and in this case the accelerometer data becomes more important. For this reason testing with the Flow deck might not be conclusive and I think it might be worth taking a look at the propellers or trying with another Crazyflie if possible.

It looks like the gamepad is OK so I think we can rule this out :-)

In general terms, the better data that we feed into the kalman filter the better the estimated position will be (obviously). The kalman filter tries to find the most likely position from the available data, and even if data is contradicting it still tries to find a position. The more contradicting data (noise for instance) the harder it will be to find a reasonable solution.
We tried to measure node to node distance as accurate as possible, but I wonder, what kind of correctness do we need? Couple of centimeter measurement error is okay, or do we really need a millimeter accuracy?
A couple of centimeters is fine. If the anchors are too far off from the configured positions you get more contradicting data in the kalman filter and it becomes more sensitive to noise in other sensors (accelerometer for instance). For that reason it is
a good idea to keep them within a few cm, even though it usually (sort of) works with anchors that are completely off.
Finally, I want to show you the installation of the system, in the pictures. The dimensions also can be seen.
I think it looks good, should be OK.


I think a good next step would be to verify the distances measured by the LPS system from the Crayzfie to each anchor and check that it makes sense. Maybe this will give some new insights?

To get the distances to the anchors you need to:
1. Switch the system to TWR
2. Set up logging/plotting in the python client, see https://wiki.bitcraze.io/doc:crazyflie: ... ex#plotter for more information on how to do it. The data you want to plot is ranging.distance0, ranging.distance1 and so on. (Note: it is only possible to have 6 variable in one log block). The ranging.distanceX variables contains the measured distance in meters from the Crazyflie to each anchor.
3. Move the Crazyflie around and make sure you see the expected changes in distance to each anchor.

The data you get in the logs above is what is fed into the kalman filter.

ranges.jpeg
Example of ranges in the Bitcraze office

tugayalperen
Beginner
Posts: 9
Joined: Mon May 14, 2018 8:33 am

Re: LPS System - Altitude Hold (z-position) Problem

Post by tugayalperen » Fri Sep 21, 2018 1:51 pm

Hi again,

We have switched the system mode to TWR and conducted some tests. In the videos above, we placed crazyflie in the pre-measured points in the arena, and look for the overall estimated position of cf in addition to distance to every node. Firstly, here are the videos:

https://www.youtube.com/watch?v=brxzHZ2PWNk x = 0.5, y= 0.0
https://www.youtube.com/watch?v=La4jbVIXyjY x = 1.0, y= 0.0
https://www.youtube.com/watch?v=Eb1MWSbQgKk x = 2.0, y= 0.0
https://www.youtube.com/watch?v=9l4BLuXjWAM x = 2.19, y= 3.0
https://www.youtube.com/watch?v=D1F82UEZgvw x = 3.19, y= 1.0
https://www.youtube.com/watch?v=tGyQDprALbE x = 3.19, y= 2.0
https://www.youtube.com/watch?v=X-V-xvDYLvY x = 3.69, y= 0.0
https://www.youtube.com/watch?v=dEoyQD4I9hs x = 4.19, y= 1.0
https://www.youtube.com/watch?v=5O9vCq23Ye0 x = 4.19, y= 0.5
https://www.youtube.com/watch?v=0E13gCXlfXE x = 5.60, y= 0.51
----At all of them, z = 0 (ground level) ----
(Please look at them at 720p, otherwise numbers are not easily readable)

After, one of us picked the crazyflie and hold it around 1.2 meters, started from the center of the arena, and then walked to Node 0, Node 7, Node 2, Node 5 and finally to Node 0 again. The video of showing the distances to each node is here:

https://www.youtube.com/watch?v=OQNPLdQhHAE Approach to node 0-7-2-5-0

To comment, measurements are neither accurate, nor precise. For example, in video 1 where we placed the cf in (0.5;0.0;0.0), the estimated value is around (0.1;-0.4;0.3), also deviating as hell. This situation is not changing except the middle region of arena, yet, its performance and accuracy in the middle are still not satisfying. In the videos, you can see estimated values for each point.

For the "approach to nodes" trials, I can say the graphs reflect the general behavior, but again, I can't say they are accurate.

We have double checked the positions of the nodes and how we write this values to system. They are correct, as possible as we can.

We also checked the propellers for any imbalance, they all seem fine. Here you can see position hold with same gamepad, somehow its x-y performance is not bad but this time, its going up by itself, without any input.

https://youtu.be/vhKkwjxM92Q

Also here, we run the autonomousSequence.py, to make cf draw a square of 1.5 m, starting from (2.0;2.0;0.0).

https://youtu.be/e-qO2U8MxtI

Some interesting thing I realized while testing is that, the region you can see in the picture (saying "no battery here")(https://ibb.co/jbTZHK), is significantly effecting the performance. When battery take place in that region, performance is going bad and even it loses connection to some nodes (meaning they are turning red in cfclient), when its place is appropriate, we do not face this situation.

I have some doubts about the shape of our whole arena. As you can see from the values (https://ibb.co/j00gxK) (please do not regard the picture itself, I have just modified the original picture for sake of convenience), its not a perfect rectangle, rather it is like a generic polygon. Is it a problem, should nodes face each other perfectly? Can I ask you to look at the values by knowing that our origin is placed just below the Node 0, (its coordinates are written as (0.0;0.0;0.15), and tell me if this situation is problematic for either TWR or TDoA?

Post Reply