Apologies in advance if this is in the wrong category - ping me and I can move it to the correct place.
I’m currently in the process of making my vehicle compliant with Remote ID (FAA) and am using Cube ID CAN as my remote ID beacon. The ‘official’ releases of ArduCopter via Mission Planner do not contain the DID parameters required for setting up Remote ID correctly (to the best of my knowledge). I’ve followed the instructions to build the firmware and can successfully enable the DID parameters, however I believe doing this is likely beyond the average user. Additionally, it is very easy to have mis-matches in git submodule versions when checking out specific branches, meaning there is a good chance the firmware will be built not as intended. I have also tried the custom firmware builder but haven’t found an option for Remote ID.
I’m coming at this from both a hobbyist and a sUAS researcher point of view. In both cases, we need to be able to arm the vehicle without having a GPS lock (much of my flying is done in an indoor lab, we also do a lot of props-off testing indoors), so having the software ‘enforce’ remote ID be active is not great for our use cases (we’d of course have it enabled for outdoor operations). Would it be possible to include the DID parameters by default, or if flash space is an issue, have it as an option when uploading via Mission Planner (such as we have for the -bdshot versions of the code)? I understand getting a fix like this could take some time, so as the Remote ID deadline is coming up, is there a place to download a pre-built firmware version that we can upload via the ‘Custom Firmware’ option in Mission Planner?
The biggest problem is that stock bootloader and firmware aren’t RID compliant at all. You need to follow specific steps to make the board and the firmware compliant.
The issue is the tamper resistance requirement. The current guidelines are basically designed around having a system that vendors/manufacturers can adopt. We have had some thoughts and discussions about a pattern that is much easier (ie build all the remote ID pieces into the standard firmware, and activate them the first time a remote id device is detected), but haven’t made a decision about whether that would ultimately be better or worse. I’d be interested in hearing opinions on that.
@james_pattison Thanks for the reply - I understand there are many challenges and that the guidelines were not really designed around the hobbyist user. I know it’s preaching to the converted, but at some point however there is a limit to how tamper resistant you can make a system. Hobbyists have a choice what firmware is installed, which bootloader they’re using, it they even choose to use Remote ID (illegal, but not the point), etc., so you’re never going to be completely tamper proof without destroying the openness that makes ArduPilot so great.
The issue at the moment is that there doesn’t exist an easy option at a hobbyist level to even attempt to comply with the new rules using something like the Cube ID which is touted as being plug-and-play. I’m guessing most of the user base would not be able to compile their own firmware versions, so are either stuck with expensive standalone units, only flying in FRIAs, or not flying at all. This is going to hurt our userbase and drive them to another flight stack.
I like the idea building the remote ID pieces into the standard firmware - as it stands it may not be perfect, but it gives people a good start while the details are worked out. From there you could:
Let people make the choice as to enable Remote ID or not. Not completely complaint with the tamper-proof requirement, but will maximise uptake as much as possible which is the goal. It would also be a quick change allowing us in the US to get as close to compliant as possible as quickly as possible. Not perfect, but it’s a start.
Lock the Remote ID options the first time a Remote ID device is detected. Not great for us who fly our aircraft both outdoors and indoors (where we have no GPS), but if that’s what it takes, we could make it work.
You could go one step further here and detect the system is Remote ID’d, then the ‘Upgrade Bootloader’ Misson Planner button could upload an appropriate bootloader. This would help towards the requirement for tamper-proof.
Thanks again. I’m more than happy to help with testing firmware etc., just let me know.
Great: I share your concerns about the impacts of remote ID on innovation and hobbyists.
If we progress a simplified implementation there’ll be a post about it. Hopefully I’ll remember to link it back here.
For the hobbyist/home builder, an all-in-one module is likely a far easier solution. The complexities (and liabilities) involved with “tamper proofing” autopilot firmware make it difficult to provide ready-made, compliant binaries to the end user.
The FAA allows for standalone modules such as this one, which avoids the need for an additional release stream and the complexities therein.
Thanks for the link Yuri - I had really hoped to stay away from something like that as they’re often expensive (it adds up for larger fleets), add more weight than it needs to, and overall, I don’t think provide any more functional ‘tamper proofing’ than that from an autopilot implementation. I’ll admit I have read through everything, but those modules cannot ‘lockout’ flying the aircraft if the Drone ID requirements are not met (GPS lock for example), hence once of the reasons for advocating for something like the Cube ID + ArduPilot. The point about liabilities is a much more complex one way outside of my knowledge base…
My point is that the FAA allows (and seems to intend) for homebuilts to use exactly something like this. OEMs need to worry about all the tamper proofing bullshit. We can slap one of these on, be compliant, and go fly. Furthermore, it lets me update my autopilot firmware without hassle, just like before.