No announcement yet.

Experience using Bridge.NET

  • Filter
  • Time
  • Show
Clear All
new posts

    Thank you for clafification


      So will there be emulated support for integers that are larger than the JavaScript numeric type can accurately represent? I would suggest that the default setting for overflow in emulated long types be an error rather than silently overflowing. The reason is that 64-bit types are only used when there is an expectation that there could be values that need to be represented larger than 2^32-1. Having a silent overflow can cause unpredictable results. Having an error would be a much more reliable way to handle the problem. Also, I think that the numeric type in JavaScript can handle numbers larger than 2^32 (+/- as appropriate). If my understanding is correct and JavaScript uses 64-bit double precision floating point numbers internally, according to IEEE_754-1985 there are 52 bits of "fraction", which represents the maximum precision available. This suggests that a 48-bit integer could be accurately represented without worrying about loss of precision. In most practical situations I can think of this should be sufficient.

      Also, do you have conversion between Int64/Uint64 types and byte representation as is available in DataView?


        We almost implemented support for Int64/UInt64 types. .Net behaviour will be mimic in Javascript. Overflow checking will be like .Net also. By default, no overflow checking but Bridge will check if value exceeds own valid range then the value will be clipped (int.MaxValue + 1 will be clipped to int.MinValue). You can use checked/unchecked statements to change behaviour (inside checked statement overflow will raise an exception). You can change overflow mode globally using project settings (like for any .Net application) or using bridge.json file (unchecked/checked/javascript modes). Javascript modes means that no overflow checking and no clipping. Default is unchecked (clipping if overflow and no exception).
        About conversion, you can use Convert class or just direct cast like in .Net
        The functionality will be merged to master soon


          Support for long/ulong has been merged into master branch and will be released with 1.12.

          checked/unchecked is also implemented, more implementation details here #1092
          Last edited by Leonid; 2016-03-24 @ 01:36 AM.


            Hi johnwason,

            Thanks to michaelcheers contribution (Pull Request #1358), we are adding Gamepad support (#781) into 1.14 release.


              Robot Raconteur Bridge is now available to Canadian residents as part of Robot Raconteur version 0.8! Robot Raconteur Bridge allows for the development of Bridge.NET clients running in any modern web browser. Due to US export restrictions it will not be available globally until next month. Documentation is available at . The software can be downloaded from . Registration is required but the download is free. The Bridge.NET example can be found at . The Bridge example allows the example robot to be driven using a gamepad, and shows a live view from the robot's webcam using an HTML5 canvas. Remarkably the update rate for the display is similar to a native C++ program, although the CPU usage is much higher.

              Let me know if you cannot access the website. I am not sure I have the entire Canadian IP range unblocked.

              Do you want me to include a Bride.NET logo on the Robot Raconteur homepage?

              Good news on the gamepad support. Currently the software is designed to use Bridge.NET 1.13. The next version will use 1.14.


                Hi johnwason,

                Robot Raconteur looks super cool. I was able to download the .zip package and correctly add the reference to the RobotRaconteur_Bridge_Examples project after cloning. The project compiled correctly.

                I don't have access to a robot, so wasn't able to fully test.
                Click image for larger version

Name:	Screenshot 2016-05-17 00.15.05.png
Views:	1
Size:	37.9 KB
ID:	2354

                Any chance you could provide a quick video or some kind of demo showing what's possible?

                Remarkably the update rate for the display is similar to a native C++ program, although the CPU usage is much higher.
                Interesting. How much higher is much higher?

                Any guess on where the higher CPU usage is coming from? Canvas, Gamepad or bridge.js?

                Do you want me to include a Bride.NET logo on the Robot Raconteur homepage?
                How about just linking (through Bridge.NET) to, for example (through Bridge.NET).
                Click image for larger version

Name:	Screenshot 2016-05-16 23.12.26.png
Views:	1
Size:	16.7 KB
ID:	2355

                Logo options are available at if you need something.


                  If you run from the Python examples ( you should be able to connect to a webcam from the browser. You will need to install Python and OpenCV ( , put "cv2.pyd" in your PYTHONPATH). The service is designed for stereo webcams, but if you only have one it should still work with the bridge example. The Python client example will show a live view similar to the browser example. The CPU usage for is slightly higher than C++ but still much lower than the browser. I think the high CPU usage in the browser is due to protocol decoding and rearranging the pixels for the canvas image format.

                  I would recommend looking through the "Introduction to Robot Raconteur using Python" as well. It is the primary document; the others just give specifics for the different languages.

                  I am also looking into Gazebo to create a virtual example robot.


                    Hi geoffrey.mcgill

                    Recently I have added a simple Python robot simulator that will allow you to run the web client and try out the Robot Raconteur bridge example against the simulation. The simulator and instructions can be found here: .You will need to enter the port numbers in the instructions for the connection URLs to access the simulation. Unfortunately my software is still using Bridge.NET 11. I will try to find some time to update to the latest version.