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.
many thx!
1 Like
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
This is my understanding as well.
This is discussed the video below starting at 16:04.
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.
Cheers, Tridge
11 Likes
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.
1 Like
@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.
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.
4 Likes
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.
no, we have no implemented receive in the esp32 code yet. It wouldn’t be hard to do, just not a priority right now
1 Like
Hello, We trying to compile Ardupilot tag Copter-4.3.0 with opendroneid enabled for Pixhawk 4. We want to get the opendroneid mavlink message through UART without using an ESP32-S3, so we follow the video in the OpenDroneID — Dev documentation , but we was not able to get the opendroneid message through UART,
we always get this error ‘PreArm: OpenDroneID: ARM_STATUS not available’, do you have an idea how to fix this issue ?
Without information regarding this blog, I post an issue on aonther thread about ardupilot firmware building for remote ID as flollows.
The core Issue in this post is that the ardupilot bootloader with AP_OPENDRONEID_ENABLED 1 (for open hardware (such as pixhawk Cube Black) whose RAM size is 256KB) can’t be made.
Do you have idea on that?
Does it work with this board:
https://www.aliexpress.com/item/1005006170017637.html?spm=a2g0o.cart.0.0.f6da38daFXZzWF&mp=1
And can i use it with elrs?
Would anyone be interested in unprogrammed versions of the mRID from Phoenix UAS? It has a ESP-32-C3, an FCC ID and has obtained a DOC. http://www.phoenixuas.us
I understand that this use case does not need a DOC and the individuals would be looking to make a standard Remote ID module integrated into UAS and do not need a serialized RID module. For this case we would just build the module and leave it up programmed and unincripted. Depending on the quantity wanted we could produce a special batch to fill the Ardu-Remote ID needs.
1 Like