Binary releases of Examples

[LucidOne]

Is it possible to get binary releases that have just the compiled firmware?

usb_to_dxl.ino.bin
burger_turtlebot3_core.ino.bin
open_manipulator_turtlebot3_core.ino.bin
waffle_turtlebot3_core.ino.bin
p_Monitor.ino.bin
...
etc

[OpusK]

Hi, @LucidOne

There is no separate collection of these binary files.
But, you can export the binary file from the ino file through the following functions of the Arduino IDE.

• [Sketch] -> [Export compiled Binary]

[LucidOne]

I was hoping Robotis could make an official release for a project I am working on.

[OpusK]

I was hoping Robotis could make an official release for a project I am working on.

Do you want to include your project program using OpenCR as an official OpenCR example?

[LucidOne]

The project is for OEMs to integrate OpenCR into products. So, I was thinking the other way around and wanted to include the official OpenCR examples in my project.

I should have some code up in a few days.

[OpusK]

@LucidOne

The project is for OEMs to integrate OpenCR into products.

Maybe other things you posted are probably related to this. Is that right?

OpenCR is an open source board.
Therefore, we do not provide any options related to commercialization.
In my opinion, to manage firmware information, you will need to update your application's information, not the firmware information of our internal drivers.
However, in the case of the USB descriptor, because the driver is part of the driver, the user can not reflect the firmware version in the .ino file (the structure will be complicated even though it can be done).

I will leave a detailed answer to your other issues, but it is difficult to officially support all those issues by the nature of open source and the concept of OpenCR we think. So, I think that if you consider an OEM product, it would be much better to fork this repository and modify the json files and drivers for your product.

Of course, we can take your example. (We will not warrant this.)
However, as I said above, considering your various issues, it seems better to manage with a separate package through fork this repository.

[LucidOne]

@LucidOne

The project is for OEMs to integrate OpenCR into products.

Maybe other things you posted are probably related to this. Is that right?

I'm filing issues as I see things. We also have an OpenManipulator demo unit from Robotis that I am testing with.

OpenCR is an open source board.
Therefore, we do not provide any options related to commercialization.
In my opinion, to manage firmware information, you will need to update your application's information, not the firmware information of our internal drivers.

The code we are working on is open source and we believe will improve the setup process for everyone using the OpenCR board, but most importantly OEMs integrating OpenCR and Dynamixels into their robot arms need a more efficient setup process. I think it will be easier to understand with the code I will link to this issue in a few days.

However, in the case of the USB descriptor, because the driver is part of the driver, the user can not reflect the firmware version in the .ino file (the structure will be complicated even though it can be done).

It may be worth looking at the current pixhawk firmware loader which builds a wrapper around the firmware image to attach version information. Putting the version in the file name could also work.

# Serial firmware uploader for the PX4FMU bootloader
#
# The PX4 firmware file is a JSON-encoded Python object, containing
# metadata fields and a zlib-compressed base64-encoded firmware image.

I will leave a detailed answer to your other issues, but it is difficult to officially support all those issues by the nature of open source and the concept of OpenCR we think. So, I think that if you consider an OEM product, it would be much better to fork this repository and modify the json files and drivers for your product.

Of course, we can take your example. (We will not warrant this.)
However, as I said above, considering your various issues, it seems better to manage with a separate package through fork this repository.

I am trying to improve OpenCR as the OEM product uses OpenCR boards manufactured by Robotis.

[LucidOne]

@OpusK just to update you. I should have some code up by Monday for you to consider.
If you could leave my tickets open until then that would be great.

Thanks!

[LucidOne]

😪 🤖

@OpusK After a few more Mondays than planned, here is the initial version of dmxl. Our fork of usb_to_dxl.ino for OpenCM9.04 should be available in the near future.

We are still experimenting with how to determine the installed firmware version and which type of arm is attached.

[OpusK]

Hi, @LucidOne

Thank you for your sharing!
I will check what you shared with the people involved.

[OpusK]

It was decided that development/support would be difficult on this issue.