I recently purchased a Cube ID CAN module and am struggling to get it connected. I have the Cube ID CAN plugged into Orange Cube CAN 2. I am following the instructions in the Cube ID manual but am not able to locate the OpenDroneID firmware so I can load it using the Load custom firmware in MP. MP is the latest version and the ID module shows up setup/DroneCAN/UAVCAN/MAVLink-CAN2.
When I run the multirotor simulator, I am able to go to Full Parameter List and locate DID_ENABLE. It is set to “1”. When I plug in the Orange Cube, DID_ENABLE is not shown.
I located the Open Drone ID Github repository, but am not sure which of any of the files that I need to use. I know that this may seem simple to most of you, but I have having a hard time getting it to work.
I have updated firmware on MP and the Orange Cube. I am following the “normal user” guidance. I cannot locate the OpenDroneID firmware mention in step 1:
Connect the flight controller to computer via USB cable. Open Mission Planner（latest version）. Install the OpenDroneID firmware firmware by “Load custom firmware”.
When I select “Load custom firmware”, there are no files relating to OpenDroneID. Is the firmware embedded in the MP firmware already? Or does it need to be downloaded from another source?
When I use the multirotor simulator and open the parameter list, DID_ENABLE shows up.
I’m not sure there is a generic binary open drone ID firmware anywhere available. I think you have to compile it yourself for a couple of reasons that are loosely related to both why the docs are unclear and why not many people are responding to help you.
I think it boils down to FUD around how to really be compliant. The function of broadcasting the drones location is only part of it. Location of the operator is another. And then there are questions about it being tamper proof and all those aspects. I have successfully gotten the cube id can module to work with a cube orange plus and the herelink controller, and I can possibly help you get as far as I have gotten. I just caution you that I bricked a cube orange and had to do surgery on it to get it working again. It wasn’t pretty and involved a soldering iron. Those don’t have a way for regular users to put them into DFU mode, so if you swing and miss on the boot loader it is lights out.
I’ve gotten to the point now where I’m completely not going to jump through more hoops to be remote ID compliant and I will accept and deal with consequences if by some strange path I get caught. Not gonna happen. Ive at least got the equipment wired up and able to work, I’m just hoping that very soon there will be more clarity about how to properly implement things and better off the shelf tools in the firmware that will be more friendly as far as updates and maintenance. I do not want to have to recompile my own firmware and install it using a custom process I have to relearn every time I do it.
If you don’t really need the remote id, then you don’t use it. It requires ODID firmware, which requires you to customize the board ID, which will cause your flight controller to be unable to write or update the firmware from the ground station. The worst thing I think is that it requires GCS to have a GPS, you need to tell the law enforcement where you are, you’re here you catch me. This is extremely ridiculous.
It is only suitable for OED manufacturers, and these manufacturers often have the ability to modify the code. It’s not intended for general consumers, so you won’t find compiled firmware.
This - 100%. I made one single drone. I guess it’s a ghost drone. No serial number. No govt registration. So even if I wanted to be compliant I couldn’t be to the letter of the law. So I’m happy to wait until things shake out more.
The documentation gives the impression that a firmware exists. It is strange that the remote ID parameters will show up when using the simulator feature of MP. So it leads me to believe that you don’t have to use the OEM procedure for remote ID. I believe that you can assign a serial number for the aircraft through the Drone ID tab in MP. I have connected a GPS to MP and don’t have an issue with the module broadcasting the GCS location. If needed, I can slap a RID module on the uav and not have to worry about it. But we build our own aircraft using the cube for training students and it would be nice to have RID available.
Yep. You can do all of those things. It works just fine. But you have to use firmware compiled with the —enable-open drone-id switch at compile time. You also have to set the board id in order to make sure your GCS can’t upload generic firmware and defeat the requirement to have remote ID running to arm/launch. That of course requires you to compile a boot loader with whatever board ID you make it. The board ID is itself part of what makes it compliant. So you want to have control over what that is.
And if you stop to think about all of that it’s just plain silly. But I understand the desire to get it all working and to do things the right way.
Keep in mind that “standard” remote is “built into” the UAV and that a “broadcast module” is attached to the UAV.
According to the #opendroneid discord thread, the Cube ID is NOT a broadcast module, which means the “manufacturer” (you) are responsible for compiling the firmware and obtaining FAA approval for it:
I’m trying to use OpendroneID with the CubeID and MatekH743-bdshot to create a RemoteID compliant aircraft under the Broadcast Module definition. Under this definition, the RemoteID module only needs to transmit (apart from the obvious other data) takeoff location, instead of a live GNSS feed of the operator.
I didn’t have a problem setting up a custom Ardupilot fork and enabling OpendroneID. However, I am having issues setting the OpenDroneID operator_location_type to 0. This tells ODID to use takeoff location for operator location. Does anyone know how to manipulate the firmware to allow this?
If you are complying with broadcast remote ID then you must use an all-in-one module (with a built in GPS) and you can broadcast takeoff location. If you are trying to comply with standard ID (and integrate a module yourself) then you must broadcast live operator location. The CubeID module is meant for standard remote ID.
My aircraft has built in GPS that is forwarding all the necessary position data to the Cube ID. I’ve already been successful in broadcasting the aircraft location to Drone Scanner using this method. I’m interesting in using the Cube ID because its the lightest option and don’t want to fly a second GPS chip. Are you saying, to fall under the Broadcast Module definition, I have to fly an approved broadcast module with its own GPS chip and cannot combine aircraft GPS with a stand alone Remote ID?
Unfortunately. The regulations only allow certified devices (my wording). The all in one broadcast devices are certified. Anything with standard remote ID must go through a declaration of compliance process to become certified.
If you build it and don’t certify it with a DoC then it is not compliant. I believe this is to mitigate poor imimentations and broadcasting false locations. Now whether this will be enforced for one-off builds is another matter
Bottom line: I would ask for my $ back and complain LOUDLY to whoever sold it to you that they should not be selling products that are not compliant and which they know nothing about.
I hate to say that I would break the law, but the spec says that the GCS must have a GPS in order to broadcast its location. I don’t know about others, but I would think that 99% have their GCS very close to the launch point. And they don’t move from there. Wouldn’t it be easy to “cheat” by simply using the arming location as the location of the GCS? The distance between the two at launch is usually not more than the GPS location error. By using the arming location as the GCS location, the requirement for a GPS connected to the GCS would be elminated.
If you’re using a broadcast module you use the launch location. For the gcs location. That’s why those modules are okay to use. If it is standard remote ID compliant then it requires the gcs.
That distinction is important. My next effort to be compliant here will be the
Db121pcb Drone Beacon by microflight. It has its own gps chip, is lightweight, and doesn’t cost 200-300 bucks.
I never saw the BS. Honestly I saw a couple youtubes on the db121 line and when I saw they had the pcb version that I could wire into my PDB for so much less than the other options, I was pretty well sold on it and quit shopping.
I have 5 of the Db 120’s on order. Hopefully it will be shipping next week. Going on some older DJI aircraft needs a separate power supply. May integrate the Db 121 on our aircraft with the cube if we can’t get the Cube ID to work.
I got my db121pcb in the mail today, so shipping from Microflight was pretty fast through the US Mail. I’ll post my results here when I get it set up. I don’t think I would fool with the CubeID solution unless I was making drones and had some regulatory reason to not use the db121pcb solution (or similar). It’s super light so I hope it works out.
I should have a new canopy with a mount location on the printer when I get home tonight. Just a couple power lines to rig in and I should be able to test this week.
I got it up and running. Super easy, no issues. The downside of the pcb version is that you kinda install it on the drone and you can’t move it to another vehicle as easily as the strap on module with its own battery. Not really a concern I have. The upsides are that you don’t add as much weight to the frame… and no firmware or other changes needed.
Also you can set it to broadcast using WLAN beacon, and turn off the response to active scanning. That way people with cell phones can’t just see your beacon and location information. That’s pretty neat.