The PX4FMU is a powerful little flight control board based on the STM32F4 chip. The PX4 development environment currently uses the NuttX embedded RTOS. In order to build and run apps in the PX4 environment, a developer must rebuild the entire nuttxOS, which has obvious drawbacks.
NuttX does include a simple shell, nsh, which supports a basic scripting language. However, if you wish to develop complex app logic, nsh is probably not the right tool.
One idea I had was to port a high-level interpreted language to nuttx, to allow developers to script and modify flight control behaviors at runtime, without the need to rebuild nuttx. So I took the compact Lua interpreter code and ported it to the PX4 environment.
You can find this under my PX4Firmware repository on github. I have a sample app “pizzahat” that provides a script to the lua interpreter. The current version is a proof-of-concept that causes Lua to run one of the built-in apps. This demonstrates that Lua can be used to script all the nuttx builtin applications.
Note that I needed to hack Lua itself significantly to get it running under nuttx: you can find the hacked version (lua-nutt) here.
This is very early-stage, but shows potential.
Edit: I’ve had a couple people ask how big the Lua binary is. A quick test shows that the px4default .px4 file is 115kB larger with lua-nutt (and the pizzahat test module).
I know some people find it handy to have a small reference doc they can look at for boards such as the PX4IO. I took the original Eagle board files for PX4IO and generated top and bottom views:
Hope you find these useful.
I’ve been using dump1090 to pick up local Hilo (ITO) air traffic using a cheap USB software-controlled radio dongle. Basically dump1090 decodes ADS-B broadcasts that aircraft send out.
Here’s a sample of what Hilo air traffic looks like:
Hex Flight Altitude Speed Lat Lon Track Messages Seen .
ac9ca4 0 0 0.000 0.000 0 140 875 sec
a17371 0 0 0.000 0.000 0 305 192 sec
aafd2b 0 0 0.000 0.000 0 113 2916 sec
a02b4b 4525 0 0.000 0.000 0 734 418 sec
a5f825 13500 0 0.000 0.000 0 723 293 sec
a79130 0 0 0.000 0.000 0 533 1636 sec
a02b4f 0 0 0.000 0.000 0 410 1851 sec
adb2b3 25 0 0.000 0.000 0 557 295 sec
a1824d 0 0 0.000 0.000 0 419 420 sec
aa3f28 -100 0 0.000 0.000 0 317 0 sec
a5e949 1525 0 0.000 0.000 0 25 0 sec
a5df82 0 0 0.000 0.000 0 364 1165 sec
aa341c 0 0 0.000 0.000 0 1 532 sec
ab8752 0 0 0.000 0.000 0 103 4495 sec
a7901c 0 0 0.000 0.000 0 370 6448 sec
7c4836 0 545 0.000 0.000 50 1 21807 sec
a91d39 0 442 0.000 0.000 58 2 22865 sec
ac90b0 17900 0 0.000 0.000 0 3 23607 sec
ab4730 14350 0 0.000 0.000 0 224 23683 sec
a3c847 -125 0 0.000 0.000 0 846 18545 sec
a4b5a7 0 0 0.000 0.000 0 177 310 sec
a17728 0 0 0.000 0.000 0 177 105 sec
a5f46e 0 0 0.000 0.000 0 748 4 sec
a2d1b2 0 0 0.000 0.000 0 201 2760 sec
a61836 717 10750 0 0.000 0.000 0 2523 5299 sec
a61bed 717 10250 0 0.000 0.000 0 1509 8413 sec
a5ff93 11000 0 0.000 0.000 0 686 3908 sec
ac9b28 0 0 0.000 0.000 0 149 8414 sec
a7046f 0 0 0.000 0.000 0 2870 23 sec
a60701 10225 0 0.000 0.000 0 657 10346 sec
a6147f 717 9950 0 0.000 0.000 0 1130 12495 sec
If you lookup the ICAO hex identifiers, you’ll see that a good chunk of them are tour helicopters (for example: a17728)
It appears that currently dump1090 is misinterpreting some of the ADS-B data that the aircraft are broadcast. For example, ICAO hex a6147f is a Boeing 717 operated by Hawaiian Airlines; however, dump1090 lists “717” in the “Flight” field.
We’ll keep playing with this.
Ok, I was trying to setup my PX4IO board with the latest firmware. This took way longer than it should, possibly because the instructions spread out on the various pixhawk/diydrones sites are outdated and rambling. Here are the steps that worked for me.
- Disconnect the PX4IO from the PX4FMU, if it’s already connected. I was never able to get this to work smoothly with the two already attached.
- Flash the standalone PX4FMU with the latest APM firmware. I used the qupgrade tool with the PX4FMU board connected via USB.
- Place the latest “px4io.bin” file onto a microSD card, in the root directory.
- Insert the microSD card into the PX4FMU. Remove the PX4FMU from any source of power (e.g. USB)
- Attach the safety switch to the PX4IO.
- While holding down the safety switch, attach external power to the PX4IO. In my case I used an old NiMH battery pack attached to the power input directly.
- The PX4IO should power up into bootloader mode. The red/amber LED will be pulsing rapidly, the green light will be solid, and the blue light will be off as detailed here. IF the LEDs aren’t lit properly to indicate bootloader mode, remove power and try again.
- Release the safety switch.
- With the PX4IO board still powered, insert the expansion bus pins from the PX4IO board into the PX4FMU. The good news here is that you don’t need to hold down the safety switch anymore, once you get the PX4IO into bootloader mode.
- Since you’ve already flashed the PX4FMU with the APM firmware, the APM startup script will notice the px4io.bin file on the microSD card and install that on the PX4IO.
- To verify that the PX4IO updated properly, you can look for /APM/px4io_update.log on the microSD card. It should say something like “Loaded /fs/microsd/px4io.bin OK” at the end.
- Note that you may need to reboot after this. You can either use the reset button on the PX4FMU board, or use eg UART1 to issue the “reboot” command in nsh.
That’s it…good luck!
It’s what drones are missing.
Today I tried a simple test with the Redpark iOS serial cable for iPhone, trying to connect from a simple iOS test app through the cable to a 3DR telemetry radio in order to send mavlink commands to a receiving radio mounted on a drone.
Unfortunately it looks like Redpark cable only puts out a 3.3V logic level signal. This doesn’t work with the 3DR radio, which apparently needs 5V signals. Sure enough, plugging the radio into the cable results in some flaky behavior.
My next step will be to try a logic-level shifter between the 3dr radio and the Redpark cable. I may also introduce a 5V power supply to power the radio separately from the iPhone supply.
It’s amazing to me that many of the proposals I’m hearing for drone ATC are based on the current human pilot and human air traffic controller-based system. You know, the system that can only handle very limited air traffic, and breaks down every time there are budget problems.
There is no reason to adopt this system for drones. We now have a chance to invent a decentralized, automatic, and scalable system for drone ATC. If drones are produced in the vast fleets I imagine they will be, then this will become the de facto ATC system and the old control tower system will just be background noise.
I have not designed a complete drone ATC system. However, here are a few attributes I think it should have:
– Distributed and Local. There’s no reason a slow flying drone should worry about traffic hundreds of miles away. The air traffic the drone monitors should be self-limited in range depending on the drone’s characteristics. The ATC system need not be centralized: local drones can figure out how to share airspace themselves.
– Cooperative. The drone behavior model should be: I’ll head directly to my destination but will make small adjustments to avoid hazards and collisions.
– Anonymous. Much bandwidth in the current ATC system is dedicated to identifying aircraft, their class, their size, their cargo, and so forth. The purpose of this is to aid a human in a centralized ATC system to prioritize and manage air traffic. With swarms of drones flying, none of them cares about the others’ name or ICAO registry number. All they should care about is how to get to their destination safely by sharing airspace, without centralized controller assistance.
– Negotiated. Much like a communications bus protocol, drones could negotiate for the use of the limited resource (airspace). A drone can reserve a slot in space and time (their trajectory) and make small concessions to allow other drones to pass. Drones that are unable to maneuver quickly could “insist” on the trajectory they need to use.
I isolated and slowed down the few flyby frames from the Hawaiian hawk (‘io) swooping by our quadcopter.
Here’s a link to the short slow-mo segment.
A Hawaiian ‘io hawk decided to check out the quadcopter drone today as it was flying around, testing out some automated takeoff and landing.
The ‘io first circled the rising drone a couple times and then came in close enough for the cheap camera on the drone to capture a closeup image. I then turned the drone’s camera to face the gulch trees as the ‘io landed in them.
It was a short, exciting encounter — I wasn’t sure what to expect from the ‘io. Would the hawk attack the drone or just inspect it? In the end the ‘io landed in the trees and preened, apparently satisfied that the drone was harmless.
Automated flight using 12 circular waypoints in a rough circle. Also experimented with altitude and yaw adjustments along the way (these were preprogrammed into the waypoints). You’ll notice that the drone pauses at some waypoints and not others– I wanted to look at some views I hadn’t been able to see before because the camera is fixed the the front of the drone.