A few questions about nodes and placement

[arnaud]

Nothing seems obviously wrong with the launch file. One thing you could try is to use another Crazyradio for the 3rd copter by setting the uri to radio://1/....

For the address, as long as the format is right you can set them in sequence without any worry since the address field is part of the CRC checksum the radio is checking upon reception. I usually used e7e7e7e701, e7e7e7e702, ...

I still want to make sure it is not a problem with TDMA: is you are connected to 2 copter and switch ON the two other, the 2 connected copters should not have any problem. If it is the case then we have to look in ros for the problem

[Newk]

Hi guys!

Thank you for the info on byte adresses... after i changed them to like A9A9A9A9A0, D8D8D8D8D2 and so on, tracking went to workable stability.
We needed to make sure not to turn them on at the floorlevel but on a table or chair, otherwise it would probably dip under the bottom plain.
Putting the anchor positions into the firmware also helped indeed with localization start-up. Much more snappy.

I think after we went to 2 bits for more then 2 CrazyFlie in LPS a new issue popped up
After allot of testing and trying we noticed it has trouble tracking on the Z-axis... the drones most of times where staying on the ground and after changing hight of goals significantly they go up and then sometimes even hit the ceiling.. quite irratic...
The weird thing is that this behaviour is barely visible in RViz.. it acts like its just hovering around the goal.
Any ideas how this happens?

Also have a request if we can have Yaw control in ROS (Wolfgang/whoenig?).. pretty please (not sure if this is the right thread to ask this)

[arnaud]

Hi,

For Z, there is an assisted take-off in the controller that you certainly want to disable. It can be disabled in the launchfile using parameters: https://github.com/bitcraze/makerfaire- ... ch#L37-L41. If the assisted take-off is enabled, the setpoint will start at Z=0 and then slowly raise. If your Crazyflie does not start at Z=0 it could be an issue.

For the yaw, it should already work if you are sending yaw != 0 to the Crazyflie cmd_vel. This is done by the controllerBridge script: https://github.com/bitcraze/lps-ros/blo ... _bridge.py. Today it ignores the yaw part of the goal. If instead it would send it to sp.angular.z you would get control on the absolute yaw as well.

[Newk]

Hi!
Turning off the assisted take-off and landing doesn' t seem to have any noticable effect..
The tracking on the X and Y axis is good.. and when moving the drone by hand the Z works fine too.
When we start the CF to let it go to its goal.. it really goes to its position, in reality and in rviz.. but after a few seconds it starts to sag down in reality (sometimes over a meter or even to the ground) while in rviz it seems to hover merrily around the goal.
Really strange behaviour... like the thrust and tracking are somehow connected, and not giving sufficient thrust to get there.
Does this make sense to you?

--

I guess we figured out how to do yaw (its in degrees and not radial values).
we try more tomorrow about that

[arnaud]

We have seen this behavior when there is too much vibration. Can you try to balance your propeller? It should improve greatly the Z estimates.

[Newk]

Hi
(sorry for the late reply, we had allot of stuff to do to get prepared for this presentation on 16th here in Berlin )

We were pretty surprised that balancing the propellers actually made a huge difference in its height estimation.
With emphasis on "estimation", so there is actually a direct connection between thrust and the tracking in the positioning.. it anticipates to where it thinks where it will be next in the positioning?
Thank you for solving that problem!

--

We got at the point where we could do yaw on the drones.. but as soon as we did, flight went totally unstable, of course we figured this is because it steers the drone thinking it's facing X.. when we jinx that, steering is applied wrong
There is not enough time to get that working with magnetic compass lined up with ROS too in time for the presentation.. but of course would like to get it done after that

[Newk]

Ah another question i have about ROS is the "RobotModel" visualisation.
(Not sure if i'm at the right spot to ask this.)
Recently there was an update to ROS and someone made a nice effort and added a 3D model representation of CrazyFlie2 as it's model.
Before that the lime-green markers would represent their position.

Now because of the significant increase in poly-count it slows down this visualization on my older laptop
(not so good video-drivers in linux for it's ATI Radeon)
...and thus take away from cpu power needed for tracking/ROS.
Also i colour-coded the drones virtually to keep track which is which.. the cubes could be coloured individually, like the goals arrows which i use to
prepare their choreography.

If i can "switch it back" to the cubes (which are missing rotation orientation though, but not a focus at the moment) would allready be great.
Even better if i can exchange the models with a very low-poly representation i made (that could be colour-coded) would be absolutely perfect!

I hope i don't hurt the feelings of the one implementing this into ROS as i think it was an awesome contribution, but in my case a bit unfortunate.

[arnaud]

For the ROS visualisation you can disable the robot model and add something else like axes. I am not sure why the green block does not show anymore, this is a bug, but axes are better anyway since it will show the orientation as well:

(in my screenshot there is an error since I have no Crazyflie connected, but once the Crazflie is connected the axis is going to show its orientation). It is a bit odd to have it so big, but is has proven very useful for debugging. Maybe I should push it by default,

[Newk]

Great i will try switching out models with axes!

Hope you have good Yule-festivities btw

I decided to install a fresh and lightweight 32bit Ubuntu 16.04 on a small but powerfull computer i recently bought for Maartje.
I followed instructions on how to set up ROS with Bitcraze (allthough

Code: Select all

source /opt/ros/kinetic/setup.bash

was missing but crucial for setting up catkin workspace ..found that out myself again i should add this to the wiki page )
Everything seems to work fine now ..BUT.. for some reason the quads do not connect with ROS.. while on my crappy laptop it does show them connecting in terminal identifying themselves and "updating parameters" ..but on this new system with all software updated it does not
I was hoping to get more stability and more snappy tracking on this new computer but now its not usable.. i feel like there is only a little gap missing to bridge this.. but what could it be?

edit: i forgot to mention that it's not because of the CrazyradioPA not working or wrong adressing... as these work fine with cfclient
also joystick control of the goals is working fine in ROS

[Newk]

after quite some struggles in trying to compile the crazyflies with new firmware i found out you removed the "sensors" part in config.mk ..stuff is confusing when it changes while working on it i still gotta find my way in keeping overview in software development environments

This wasn't fixing the connection / tracking problem though