Announcement

Collapse
No announcement yet.

Experience using Bridge.NET

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • johnwason
    started a topic Experience using Bridge.NET

    Experience using Bridge.NET

    I am going to share my experience using Bridge.Net in the hope that the feedback is helpful to the developers. Overall I have been impressed with the project. I develop a robotics communication software package that I wanted to port to run in web browsers alongside the standard application implementations. I have a large existing C# codebase so the best option was to use a C# to JavaScript compiler. I was able to use Bridge.Net to implement a proof of concept where I was able to drive a robot using the HTML5 gamepad support, which is pretty neat. Eventually I'd like to be able to have a single codebase that runs both in .NET and Bridge.Net with as much shared code as possible. I ran into a few issues that make this difficult:
    • The "lock" statement appears frequently in any multithreaded C# code. While it doesn't make sense in a browser it would be helpful if it came up as a warning instead of an error and was simply ignored.
    • TaskCompletionSource and CancellationToken are very important to async/await code.
    • Structures are not implemented properly for function parameters. For example,
      void f(CancellationToken cancel=default(CancellationToken)) {}
      is a standard usage.
    • Various contiguous arrays such as byte[], int[], etc currently use JavaScript arrays. It would be better for my project if they used Uint8Array, Int32Array, etc.
    • [DONE] Long types have no support and unpredictable behavior
    • The System.IO namespace appears to be unimplemented. At least some basic support should be available as an extension package. Especially the exceptions like System.IO.TimeoutException should be available. While they are in the System.IO namespace they get used elsewhere.
    • Some basic support for System.Net would be helpful along with System.Net.Websockets
    • A wrapper class for the Gamepad objects would be cleaner than using "dynamic".
    • A few general bugs that look like they have been fixed.

    These suggestions are not necessarily critical but would be nice if they were available.
    Last edited by geoffrey.mcgill; 2016-05-17 @ 07:29 PM.

  • johnwason
    replied
    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: https://github.com/johnwason/RobotRa...ython_Examples .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.

    Leave a comment:


  • johnwason
    replied
    If you run SimpleWebcamService.py from the Python examples (https://github.com/johnwason/RobotRa...ython_Examples) you should be able to connect to a webcam from the browser. You will need to install Python and OpenCV (http://opencv.org/downloads.html , 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 SimpleWebcamClient_streaming.py will show a live view similar to the browser example. The CPU usage for SimpleWebcamClient_streaming.py 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.

    Leave a comment:


  • geoffrey.mcgill
    replied
    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 http://bridge.net, 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 http://bridge.net/identity/ if you need something.

    Leave a comment:


  • johnwason
    replied
    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 https://preview.robotraconteur.com/documentation . The software can be downloaded from https://preview.robotraconteur.com/download . Registration is required but the download is free. The Bridge.NET example can be found at https://github.com/johnwason/RobotRa...ridge_Examples . 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.

    Leave a comment:


  • Leonid
    replied
    Hi johnwason,

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

    Leave a comment:


  • Leonid
    replied
    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 @ 12:36 AM.

    Leave a comment:


  • Vladimir
    replied
    Hi
    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

    Leave a comment:


  • johnwason
    replied
    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?

    Leave a comment:


  • kcudnik
    replied
    Thank you for clafification

    Leave a comment:


  • Vladimir
    replied
    Long values will be handled without any switch (if you use long in C# then it will be long in javascript)
    Daniil meant that will be config for handling overflow (like checked C# compiler option). By default, overflow will be unchecked and clipping is performed (int.MaxValue + 1 will be clipped to int.MinValue). You can set javascript mode (without overflow checking and without clipping) or checked mode (if overflow is detected then exception will be thrown)

    Long support is implemented, you can play with it if grab '64bit_support' branch (https://github.com/bridgedotnet/Brid.../64bit_support)

    UPD:
    The latest changes for long support are in branch Issue778_long
    Last edited by Leonid; 2016-03-17 @ 08:10 PM.

    Leave a comment:


  • Daniil
    replied
    Hi @kcudnik,

    Thank you for the feedback! Yes, there is going to be a config option to switch between JavaScript and .NET mode. The .NET mode is going to be by default.

    Leave a comment:


  • kcudnik
    replied
    As for long/Int64 and ulong/UInt64 i would propose to make a compiler switch, that will specify whether use long as actual values used in js, or long that supports +/-2^31-1 values as in C#. Since javascript don't support such values natively, on bridge.net side it will require additional code to support it which may have a hudge performance impact when doing simple math operations.

    Leave a comment:


  • Daniil
    replied
    Great! Thank you for the feedback.

    As for long/Int64 and ulong/UInt64 support, it is being under development to appear with the 1.12 release.

    Leave a comment:


  • johnwason
    replied
    Thanks for the update. I have finished the initial version of my library and will be releasing it in the next few weeks. I still require Int64 and Uint64 types to finish all the features but otherwise the library is working well.

    Leave a comment:

Working...
X