new to px4. successfully installed environment (nuttx and snapdragon) native on ubuntu 16.04, and successfully ran first build and sim.
trying to upload px4 to crazyflie 2.0. success building and uploading bootloader - console reports success, and yellow led blinks when replugging to crazyflie usb.
success in building firmware - but cannot get it to upload. yellow led comes on, but after ~5 seconds, all leds blink , then board does its normal pos startup and is ready to fly. no upload effort made, console still waiting, urging me to unplug and replug until it works.
I have plugged and replugged the board many times. I have tried several cables, and several usb ports. I have rebuilt both bootloader, and firmware several times, trying both make clean, and simply removing and re cloning the repos.
No change in results.
Any ideas appreciated âŚ
seth
Follow up after original post: I tried simply âmake crazyflie_defaultâ without the upload argument. It REPORTS success, and the console output has no errors, BUT I cannot locate any kind of final file. The more I look, the less I am certain I know what to look for. Where and what would this file be named?
FYI - appears that the uploadable file is âsrc/Firmware/build_crazyflie_default/src/firmware/nuttx/nuttx-crazyflie-default.px4â. - an ascii file in xml or yaml format. Also in the same directory is firmware_nuttx.bin.
well - maybe i need another charm. QGC firmware upload reports success. BUT cf2 seems to remain in bootloader mode when I connect again. m1 flashing yellow, m2 steady blue, m4 flashes red every ~5 seconds.
cfbridge never connects to cf2. PA dongle red led is on after âmake runâ. console shows "waiting for messages âŚâ
Sounds like it may need a full power cycle, disconnecting battery too. I would try connecting straight to QGC via USB first as you will need to calibrate it anyway. If the Firmware is on right, M1 is the charge indicator. M2 is not effected by the Firmware and is solid indicating that the processor is running in regular mode.
If the firmware is on right, and it isnât charging any battery, then just M2 should be solid with M3 blanking.
If everything is right, cfbridge âmake runâ should trigger M4 is blink (the TX/RX indicators)
Very helpful thanks. I have a valid load in it now, and have set up sensors, taranis 9d as a joystick, etc. leds working properly as you described them. cfbridge still not connecting, though the hardware definitely works, and the dongle red led comes on. Suspect this is a problem in QGC comm setup. I can also connect with ios/bluetooth, which does blink m4 - but it wont fly. guessing that one is an arming problem.
my guess is i have somethings wrong between joystick switches and radio setup and arming sequence. too bad that intro to QGC doesnt have sound - i expect that would help.
This probably needs better documentation:
For the iOS app, change the settings to have controller mode 2. Connect via USB to QGC and calibrate the radio with the app connected. Set up a flight mode on channel 5 to a constant manual/stabilized one. Arm via app by holding left stick down and to the right for 5 seconds (M3 should go to solid blue indicating armed).
For the cfbridge, please confirm that the parameters for Syslink are set to channel: 80 and data rate: 2.
Successfully connected and flew (badly) using iOS client. Only issue was that it took several tries to get it to calibrate radio in this mode. Connection was unstable. Rebooted everything and that worked.
Then resetup with taranis 9d as simple joystick. Easy calibration, and worked when usb connected. Obviously cant fly with usb cable hanging off cf2, but armed and responded to control movements appropriately.
Still cant get cfbridge to connect. Yes, Syslink set channel 80, data rate 2. I connect in QGC comm to default udp (which has correct settings - also made a cfbridge one). Claims it is connected.
cfbridge âmake runâ behavior has not changed: red led on radio dongle comes on, console shows âWaiting for messages âŚâ.
Several questions:
will cfbridge connect to cf2 even if QGC not running? I assume so - but wanted to check.
is there any order dependency in what gets turned on when - cf2, cfbridge, dongle plug in? perhaps i am just ham fisting it somehow.
same ordering question for QGC and dongle, cfbridge, etc.
Finally - is there any good info on how to use QGC. I am just guessing even on what the basic modes do based on minor narratives on site - all the videos have no sound.
hacking away - wanna get this going so i can move on to new snapdragon based project!
do appreciate all your patience and help -
ALSO - i am pretty sure radio hardware works - i can fly a normal cf2 with it. i suppose the cf2 radio could be bad - but have no easy way to tell as no easy way to return this cf2 to bitcraze bootloader, etc
Yeah, it should be as simple as plugging in the radio, turning on the crazyflie and running the bridge. The order isnât particularly relevant so long as the radio is in before running the bridge. The connection should succeed without QGC open.
Can you try doing âsudo pip install cflibâ and run the â./scripts/cfbridge.pyâ code in the cfbridge repository? That should be an alternative functional, but incomplete version that is more verbose. Please let me know the output of running that on your computer.
This is interesting. Looks to me like either my px4 firmware has a problem or the cf2 i loaded it on has a broken radio. Going to try return it to a normal cf configuration and see if the radio still works.
With the px4âd cf2:
seth@chimp:~/dev/px4/src/cfbridge$ ./scripts/cfbridge.py
Scanning interfaces for CrazyfliesâŚ
DEBUG:cflib.crtp:Scanning: <cflib.crtp.radiodriver.RadioDriver instance at 0x7f0b8514cdd0>
INFO:cflib.crtp.radiodriver:v0.53 dongle with serial N/A found
DEBUG:cflib.crtp:Scanning: <cflib.crtp.serialdriver.SerialDriver instance at 0x7f0b8514ce18>
DEBUG:cflib.crtp:Scanning: <cflib.crtp.udpdriver.UdpDriver instance at 0x7f0b8514ce60>
DEBUG:cflib.crtp:Scanning: <cflib.crtp.usbdriver.UsbDriver instance at 0x7f0b8514cea8>
INFO:cflib.drivers.cfusb:Looking for devicesâŚ
Crazyflies found:
No Crazyflies found, cannot run example
Traceback (most recent call last):
File â./scripts/cfbridge.pyâ, line 161, in
while le.is_connected:
NameError: name âleâ is not defined
seth@chimp:~/dev/px4/src/cfbridge$
With an unmodified cf2:
seth@chimp:~/dev/px4/src/cfbridge$ ./scripts/cfbridge.py
Scanning interfaces for CrazyfliesâŚ
DEBUG:cflib.crtp:Scanning: <cflib.crtp.radiodriver.RadioDriver instance at 0x7f50d5ee4dd0>
INFO:cflib.crtp.radiodriver:v0.53 dongle with serial N/A found
DEBUG:cflib.crtp:Scanning: <cflib.crtp.serialdriver.SerialDriver instance at 0x7f50d5ee4e18>
DEBUG:cflib.crtp:Scanning: <cflib.crtp.udpdriver.UdpDriver instance at 0x7f50d5ee4e60>
DEBUG:cflib.crtp:Scanning: <cflib.crtp.usbdriver.UsbDriver instance at 0x7f50d5ee4ea8>
INFO:cflib.drivers.cfusb:Looking for devicesâŚ
Crazyflies found:
radio://0/80/250K
DEBUG:cflib.crazyflie:Adding callback on port [5] to [<bound method Log._new_packet_cb of <cflib.crazyflie.log.Log instance at 0x7f50d57df758>>]
DEBUG:cflib.crazyflie:Adding callback on port [0] to [<bound method Console.incoming of <cflib.crazyflie.console.Console instance at 0x7f50d57df830>>]
DEBUG:cflib.crazyflie:Adding callback on port [2] to [<bound method _ParamUpdater._new_packet_cb of <_ParamUpdater(Thread-2, initial daemon)>>]
DEBUG:cflib.crazyflie:Adding callback on port [4] to [<bound method Memory._new_packet_cb of <cflib.crazyflie.mem.Memory instance at 0x7f50d57dfc68>>]
Connecting to radio://0/80/2M
INFO:cflib.crazyflie:Callback->Connection initialized[radio://0/80/2M]
INFO:cflib.crazyflie:We are connected[radio://0/80/2M], request connection setup
DEBUG:cflib.crazyflie:Sending packet and expecting the (93, 5) pattern back
waiting to receive message
INFO:root:Has safelink: False
WARNING:cflib.crazyflie:Got link error callback [Too many packets lost] in state [1]
INFO:cflib.crazyflie:Resending for pattern (93, 5)
DEBUG:cflib.crazyflie:We want to resend and the pattern is there
INFO:cflib.crazyflie:Resending for pattern (93, 5)
INFO:cflib.crazyflie:Callback->Connected failed to [radio://0/80/2M]: Too many packets lost
Connection to radio://0/80/2M failed: Too many packets lost
The scanning process done by the radio should at least find the cf2 if the radio is at all working as the connection acknowledgements are processed by the NRF radio and should get sent regardless of the Firmwareâs functionality. So, it does look to be a faulty radio.
Looks like radio itself is fine. After reflashing as a normal cf2, it operates normally, including rf firmware flashing, and flying. ./scripts/cfbridge.py also finds it - though of course it does not respond. Just like my ânever reflashedâ cf2.
I did then reinstall px4 as per the instructions - same result.
Is there any possibility that recent changes to px4 have broken things? I am just building the vanilla stuff from the install.
I just reflashed back to the latest versions and the official firmwares and it seems like a recent change to the radio firmware is causing an issue. Looking into it now.
Dear dennisss and seth,
I have another question in terms of the crazyflie ground station with px4 firmware. As you may know, CF has its own ground station written by python. If px4 is integrated in CF2, it should, and could, be calibrated by QGC, but can it still be controlled by its original ground station, i.e. param set and data collection? Or, it can only communicated with QGC this time.
Thanks. @dennisss@seth
The original ground station wonât completely work right now. A minimal version of the crtp protocol was implemented just to work with the mobile app and limited support for the crazy radio Python libraries. Params and calibration have no support via the original gcs. Right now calibration is only supported via mavlink due to the amount of work it would require to support the original stuff.
