-
Notifications
You must be signed in to change notification settings - Fork 14.6k
ESP32 Support Sponsored by AutonoSky #24887
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
eb00f4b
to
be8f8c5
Compare
Wifi should be working now: Should be able to see the hotspot: px4-esp32 and the password is: "px4-esp32" on the nsh-console you should be able to see the network device by the command: start the dhcpd server by:
|
Something which I would like to get working is able to connect to the hotspot and login into the nsh-console via mavlink. |
Does this impact the docs at all? https://docs.px4.io/main/en/telemetry/esp32_wifi_module.html#esp32-wifi-module |
Hi Hamish, This doesn't affect ESP-based boards used solely for Mavlink telemetry over WiFi (e.g., DroneBridge ESP). If the PR is merged, we could add a note to clarify for new developers that flashing PX4 on an ESP32 dev board isn't meant to replace DroneBridge, but provide more functionality like controlling a subsystems on a drone. (make use of GPIOs, PWM, ect) The intent of this PR is to enable PX4 on an ESP32 acting as a controller for a subsystem on a drone, where you would like to make use of the wireless connectivity to connect to an another device(phone). Or using the ESP32 as a microcontroller for testing equipment, where you can enable "PX4 testing modules" over Wifi which enable you to be far away from possible dangerous testing equipment. I hope this provide some clarity. |
bcdcd4d
to
f9ed910
Compare
@davids5 is the CI broken? |
ping @mrpollo |
Thanks @acassis for bringing attention to the PR. I think the CI is broken due to not having the xtensa compilers in its path -> I think the docker image needs to be updated with the xtensa compilers to build it successfully.. I have added it to However, I will need to make another PR on the nuttx side for it to compile succesfully -> will do this once the CI starts compiling esp related code. |
Thanks @henrykotze When this goes in create a doc anywhere you like and apply the Documentation label and I'll look at it and find a home. |
platforms/nuttx/src/px4/espressif/esp32/version/board_mcu_version.c
Outdated
Show resolved
Hide resolved
FMUv5X
FMUv6X
|
Hey @henrykotze we love this contribution and want to help you get this merged as soon as possible, the only thing we gotta be careful with is the build tooling, we should make sure it's platform specific and doesn't leak into the build tooling for the overall system otherwise its going to become a maintenance burden on everyone. @dagar can you please comment on the proposed build changes in this PR? |
This pull request has been mentioned on Discussion Forum for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink. There might be relevant details there: https://discuss.px4.io/t/px4-dev-call-june-11-2025-team-sync-and-community-q-a/45976/1 |
Thanks @mrpollo, I have capacity to work on any feedback as needed. 👍 I totally agree that the build process should remain unaffected for other architectures. I will start inspecting the bloaty report and getting zero changes. |
@mrpollo I assume i will need to add the Xtensa Compilers to PX4-Containers (https://github.com/PX4/PX4-containers/tree/master) for the Workflow's to start compiling the esp32 board. Can you point me in the right direction to start adding it in? |
Hey @henrykotze, the container image we're using for building is now hosted in this repository. It's the px4-dev image, which can be built on demand. It picks up dependencies from ubuntu.sh (so you are already covered). The issue here is that this becomes a chicken-and-egg problem, where we need to have the container updated so that the target is built in CI. Here's my proposal:
What do you think? |
@mrpollo The one blocking issue I see, is that I will need to create a PR to PX4 Nuttx. I will then start getting that PR ready, alongside your first bullet point. Once these are ready I will ping you again. |
That sounds great; just let me know when you're ready, and I'll help you cross the finish line. |
112aacb
to
e98fea6
Compare
@mrpollo ready to take this further.
|
5a93cb3
to
7958676
Compare
@mrpollo Now it compiles without any changes on PX4 Nuttx. |
4e62139
to
1a7ad11
Compare
nsh console running on USB param module running working with i2c and common drivers provided implementation for drv_pwm_output.h i2cdetect working as expected with no device mavlink started succesfully mounts sd card and logger runs logger to file succesfully pwm_servo implemented without using Nuttx lib pwm_out outputs expected waveforms - however currently if the frequency is higher than what the pwm_out driver runs, there will be aliasing, based on how the registers gets resets wifi softap working - Seeing wifi hotspot - cant connect due to wrong password - problems with adjusting ssid and password wifi ssid and password being set accordinglu connected to wifi hotspot with dhpcd - made some changes to nuttx to only build for SoftAP mode, however this was effectivelyy removing the ifdef for STATION mode. Should investigate the coexist option again added ifdef to not use timer 0 when wifi enabled - reverted esp32 rt_timer to make use of timer 0 by default fix setting incorrect bit in hrt timer register - hrt running as expected, but on startup the pwm_out driver starts up at about 200Hz and then rises over a minute or so 250Hz. Not sure if this was present previously, and could be due to Wifi running at time priority on timer 0 pull xtensa compilers in setup.ubuntu.sh revert logger stacksize and cmake argument esp32 chip revision and PX4 UUID implemented spi board reset implemented, formatting checked devkit acts on startup as a wifi bridge for comms - the most usefull setting for the general developer when buying a esp32 devkit - testing Mavlink shell using ./Tools/mavlink_shell.py - todo: Test mavlink messages being forward improve wifi telemetry by increasing prio - Remove power save mode on wifi - increased daemon thread schedule priority to 50 compiles without Nuttx changes - updated compiler settings to match those of nuttx on px4 side add espressif_esp32 to excluded boards ci: allow docker to find xtensa compilers
1a7ad11
to
78a7a0a
Compare
@henrykotze Congrats on getting this in. Reminder that docs would be great so that people can discover this feature and know how to use it. As I understand it, this is a way to run PX4 on ESP32. Therefore I think what is needed is a flight controller page like https://docs.px4.io/main/en/flight_controller/beaglebone_blue.html or https://docs.px4.io/main/en/flight_controller/holybro_pix32_v5.html , probably under "Experimental Autopilots". |
@hamishwillee |
Support for ESP32 Sponsored by AutonoSky
PWM Tested
I have tested the PWM outputs using Digital Logic Analyser. They perform as expected, if the Timer frequency is below 250Hz.
Logger Tested
I have hooked up a SPI based SD card, and have logged succesfullly
I2C
Tested airspeed sensors communicated over I2c
i2cdetect works as expected
UART
GPS driver works as well as mavlink communication
Parameters
Able to save and read parameters using SPIFlash
Wifi
Wifi is working in a minimal state. Able to see wifi hotspot, and able to connect, and send mavlink over Wifi, but there are some setup to get this working. This is on a different branch, currently being worked on. Will push this onto this branch as well.
Known bugs:
- the pinout defined in the menuconfig needs to match those being setup in the board directory. (This isn't really a bug, but more unnecessary setup which I haven't had time to clean up)fixed- nsh console over mavlink - the terminal hangs when logging in over wifi: fixed- A minimal nuttx patch required. Will attach here.: fixed- I had to adjust the stack size for multiple modules: for now i removed any modules from the board config which required stacksize increase, to minimize the intrusion of this PRUsing esptool v4.7.0
xtensa-esp-elf-gcc (crosstool-NG esp-13.2.0_20240530) 13.2.0
There might be additional bugs, which I can think of now, but just wanted to get this WIP out so long.
git apply the following patch in the nuttx directory:esp32-wifi-support.txt