flight is not working properly with LPS

[Rucy-kim]

Hi!

I am testing crazyswarm with lps.
but my flight is not working properly.

I got the coordinates of the base station by referring to this
and after modifying this file:
crazyswarm/crazyflie-firmware/src/deck/drivers/src/lighthouse.c

I compiled this firmware and flashed it on my cf and flashed the prebuilt nrf firmware.

And I modify this line to 'none'.

And start the server and I ran:
python figure8_csv.py

That seems to take off for a while, but soon loses control and crashes.
When I tested it with bitcraze's official firmware using the same coordinates, I was able to fly without any problems.

Is there something wrong with my setup?

This is my console message while rviz is running:

auto-starting new master
process[master]: started with pid [24453]
ROS_MASTER_URI=http://localhost:11311

setting /run_id to 10967510-8e22-11ea-97b3-080027acef63
process[rosout-1]: started with pid [24466]
started core service [/rosout]
process[crazyswarm_server-2]: started with pid [24483]
process[joy-3]: started with pid [24484]
process[crazyswarm_teleop-4]: started with pid [24485]
process[rviz-5]: started with pid [24487]
[ERROR] [1588608756.046831796]: Couldn't open joystick force feedback!
[ INFO] [1588608756.046935465]: Opened joystick: /dev/input/js0. deadzone_: 0.050000.
[ INFO] [1588608756.049030428]: Wait for services...
[ INFO] [1588608756.049653884]: waitForService: Service [/emergency] has not been advertised, waiting...
[ INFO] [1588608756.086099065]: waitForService: Service [/emergency] is now available.
[ INFO] [1588608756.091813902]: Manager ready.
ch: 1
[ INFO] [1588608756.292038864]: Adding CF: cf1 (radio://0/90/2M/E7E7E7E701, cf1)...
[ INFO] [1588608756.345696375]: CF ctor: 0.053499 s
[ INFO] [1588608756.349428597]: [cf1] Requesting parameters...
[ INFO] [1588608756.357585772]: Found variables in cache.
[ INFO] [1588608756.912387921]: [cf1] reqParamTOC: 0.566445 s (165 params)
[ INFO] [1588608756.912496313]: Requesting memories...
[ INFO] [1588608756.918179327]: Memories: 10
[ INFO] [1588608756.956716758]: [cf1] Ready. Elapsed: 0.610785 s
[ INFO] [1588608756.956843536]: CF run: 0.611165 s
update commander/enHighLevel to 1
update kalman/pNAcc_xy to 1
update kalman/pNAcc_z to 2
update locSrv/extPosStdDev to 0.001
update locSrv/extQuatStdDev to 0.05
update ring/effect to 16
update ring/headlightEnable to 0
update ring/solidBlue to 255
update ring/solidGreen to 0
update ring/solidRed to 0
update stabilizer/controller to 2
update stabilizer/estimator to 2
update ctrlMel/i_range_m_z to 1500
update ctrlMel/i_range_xy to 2
update ctrlMel/i_range_z to 0.4
update ctrlMel/kR_xy to 70000
update ctrlMel/kR_z to 60000
update ctrlMel/kd_omega_rp to 200
update ctrlMel/kd_xy to 0.2
update ctrlMel/kd_z to 0.4
update ctrlMel/ki_m_z to 500
update ctrlMel/ki_xy to 0.05
update ctrlMel/ki_z to 0.05
update ctrlMel/kp_xy to 0.4
update ctrlMel/kp_z to 1.25
update ctrlMel/kw_xy to 20000
update ctrlMel/kw_z to 12000
update ctrlMel/mass to 0.032
update ctrlMel/massThrust to 132000
[ INFO] [1588608757.037603270]: [cf1] Update parameters
[ INFO] [1588608757.218048860]: [cf1] CONTROLLER: Using Mellinger (2) controller
[ WARN] [1588608757.237692233]: [cf1] Link Quality low (0.310000)
[ INFO] [1588608757.272613656]: Update params: 0.315683 s
[ INFO] [1588608757.272803890]: Started 1 threads

If you know what I did wrong, please let me know.

Thanks in advance for the help.

[whoenig]

You can just use the latest Bitcraze firmware (which has probably more bug fixes than the one we provide). The latest Crazyswarm version does not require any special firmware. Does it work in that case (you should really only need to change the mocap to None)?

[Rucy-kim]

Hi!
Thank you for the answer.

If bitcraze's official firmware is enough, what is the role of crazyswarm repository's submodule, crazyflie-firmware?

I tried this script with reference to your answer with latest bitcraze's crazyflie-firmware repository and crazyflie2-nrf-firmware repository, crazyradio-firmware repository.

And this is my mocap setting:

      motion_capture_type: "none" # one of none,vicon,optitrack,qualisys,vrpn
      object_tracking_type: "libobjecttracker" # one of motionCapture,libobjecttracker
      send_position_only: False # set to False to send position+orientation; set to True to send position only
      vicon_host_name: "vicon"
      # optitrack_host_name: "optitrack"
      # qualisys_host_name: "10.0.5.219"
      # qualisys_base_port: 22222
      # vrpn_host_name: "vicon"

When I ran:
roslaunch crazyswarm hover_swarm.launch
the cf reboots and the status of the m1, m2, m3 looks normal, but does nothing.

I don't know why, turn the power on again, and trired this script of crazyflie-lib-python(runs without any problems)
and try again to connect normally.(cf's LED-ring is all red)

In this state, niceHover.py script had no problem until takeoff,
but moves the y-axis, it crashes.

I still don't know what is wrong.

And sorry, there is one more question.

When I run hover_swarm.launch, after cf reboots, kill the rviz process and run hover_swarm.launch again, the following error occurs.

[crazyswarm_server-2] process has died [pid 21156, exit code -6, cmd /home/drone/work/crazyswarm/ros_ws/devel/lib/crazyswarm/crazyswarm_server __name:=crazyswarm_server __log:=/home/drone/.ros/log/71b864ae-8f7e-11ea-97b3-080027acef63/crazyswarm_server-2.log].
log file: /home/drone/.ros/log/71b864ae-8f7e-11ea-97b3-080027acef63/crazyswarm_server-2*.log

there a conceivable cause?

[whoenig]

• Your settings and firmware choices are correct. What is worrisome are the reboots: this essentially means that something triggered a hardfault on the firmware. The cause of the hard fault should be shown on the terminal console - could you post that output?
• Check if you have safelink disabled (https://github.com/whoenig/crazyflie_cpp/blob/master/include/crazyflie_cpp/Crazyflie.h#L15 set to 0). This has caused quite some trouble in the past and was for a long time enabled by default. The issues related to safelink being enabled vary a lot, so it is hard to tell if what you are seeing might be caused by it.
• The crash/error you see is a segfault. To determine the exact cause, we'd need to reproduce & debug the issue. I think we first need to get rid of the CF rebooting on connection, since that might bring the whole system in an undefined state.