We’re delighted to announce OpenDroneID support in the latest ArduPilot 4.2.3 beta releases.
A presentation we gave to ArduPilot partners this morning is available here:
I’ve now released version 1.1 of ArduRemoteID firmware for ESP32-S3. This release adds support for Bluetooth 5 long range transmissions.
I should have some S3 and C3 here by Friday ready to test.
release 1.4 is now out with C3 support, plus many other improvements
these board will work correct?
yes, should be fine, main difference is form factor for getting at pins
I assume you flash both C3 and S3 with the ArduRemoteID-ESP32S3_DEV.bin? S3 flashed without any issues haven’t hooked them to bench FC yet.
I’m somewhat interested in this topic of RID and hence follow it somewhat, and it is really cool that you guys make these efforts, but I do have one question which I’d like to ask:
I have heard a couple of times and repeatedly from folks who I would think have some knowledge in the matter that FAA likely would NOT approve any approach which involves open source software or is open in some ways.
What is your insight into this matter? What makes you confident your approach can get FAA approval? How would that acctually work out, with ids etc pp?
I mean, the fact you make these open source efforts makes me think that you guys think there is a chance to get FAA approval, but to me - the totally naive bystander - it sounds contradictory to what one can hear.
I’ve made a separate C3 firmware. I will release binaries as part of version 1.5
Cool will mess with the S3 then tonight. I see the tx rx pin mapping on github can you also use the uart usb port?
yes, I’ve added mavlink on the USB uart in the latest releases
The presentation discussed this - the Remote ID firmware bits will be “locked down” (set as read only) by each manufacturer, to meet the MOC testing requirements.
that is complete nonsense. After Lorenz from Auterion tried to organise a scare campaign around this last year we directly asked the FAA and got a clear answer that there is nothing preventing an open source solution.
because we are meeting the requirements of the ASTM means of compliance which is already approved.
The particular wording that is relevant from the ASTM MOC is:
“89.310(d) The unmanned aircraft must be designed and produced in a way that reduces the ability of a person to tamper with the remote identification functionality.”
Then the only question is how much reduction in ability to tamper is needed.
We have implemented several levels of tamper resistance in the firmware and will be expanding the OpenDroneID docs on the wiki over the next couple of weeks to explain the methods. The vendor will be able to choose what level they want, from using board IDs and @READONLY parameters, to full firmware signing and locked down bootloaders. All of this is already implemented and tested.
The idea that it can’t be done in open source code is complete nonsense and is just pushed by people with an agenda against open source.
Just to preempt the usual comebacks, often people say it can’t be done with GPLv3, because of the “User Product” clause, but that is just because they haven’t bothered to actually read the clause.
Since this may not be the last time this question is asked, maybe a version of your reply could be added to the remote ID peripheral wiki page ?
I think most people here agree with you.
I doubt the FPV Freedom Coalition is against open source solutions but they sure seem to have the impression the FAA won’t allow an open source solution. I think most of the people who watched the above linked video now thinks the FAA is against open source solutions.
Bardwell does a weekly news show. I could message him and ask him to read this thread. Hopefully he could let his audience know (in the news show) that there’s an open source solution in the works.
I think a lot of people in Bardwell’s audience will be pleased to learn about OpenDroneID.
Thanks for letting us know about this. I’m really pleased to learn I’m probably wrong.
@tridge I am looking at the github page and it states this “Support for OpenDroneID is in ArduPilot master and is pending for addition to the 4.2.x stable releases. You need to enable it on a board by setting “define AP_OPENDRONEID_ENABLED 1” in the hwdef.dat for your board.”
So in order to test this on a cube yellow I would have to rebuild the firmware for that board with AP_OPENDRONEID_ENABLED 1.
Excellent discussion with @tridge here
yes, though we also now have a --enable-opendroneid option to configure to avoid editing hwdef.dat
The reason we don’t build it in as standard in the firmware is it would give users the false impression that you just need to turn it on and you are compliant. There is a lot more to being compliant than having this code, and if you aren’t able to build your own firmware then you have no chance of building a compliant vehicle.
Does the esp32 s3 or c3 firmware support receiving opendroneid transmissions? Or is there any other firmware or projects that would provide this capability? An opendroneid receiver with mavlink output could provide a lot of really interesting uses. Also the ability to display any information in the gcs could also prove useful.