https://community.element14.com/products/manufacturers/xsens/ Xsens is the leading innovator in 3D motion sensing technology and products. Its sensor fusion technologies enable a seamless interaction between the physical and the digital world in applications such as industrial control and stabilization, health, sporen-USTelligent Community 12https://community.element14.com/products/manufacturers/xsens/f/forum/51841/specifying-mti-680-orientation-in-mt-manager/201551Tue, 25 Oct 2022 13:53:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:ef1154d3-4980-481c-958c-548a95dd138bxsenssupportHi, Definitely, thanks for the feedback! We have registered your suggestion to add tooltips to some of the settings in MT Manager in order to add clarity for the user and we hope to implement that in a future release of the MT Software Suite. To answer your question: Yes, the 3D view block is expected to still show the physical orientation of the device. However the Roll/Pitch/Yaw values shown in that view (and in the orientation plot) should be as expected after the RotSensor/RotLocal matrices have been applied.https://community.element14.com/products/manufacturers/xsens/f/forum/51841/specifying-mti-680-orientation-in-mt-manager/201473Fri, 21 Oct 2022 00:46:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:4fa3f276-de85-4fa0-b9e1-1e887c3b6101saadtiwana_intHi, Thanks for your response, and no worries for the delay. The reason I opted to post here instead of via email was so that the information stays available to anyone who maybe runs into the same issue and searches for it in future Btw, when the rotation is flipped like this, should I expect the visualization in 3D viewer to flip as well, or that is expected to follow the original orientation printed on the side of the device? On a related note, may I suggest adding some indication of what each component of the RotSensor and RotLocal is for in the manual or besides the values on the GUI? I understand it is something that people knowledgeable in the domain will already know, but for the rest of us noobs it might be helpful . Just a suggestion Best Regards, Saadhttps://community.element14.com/products/manufacturers/xsens/f/forum/51841/specifying-mti-680-orientation-in-mt-manager/201407Mon, 17 Oct 2022 09:49:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:4d6ab228-f095-4602-ae1c-e4134f7af96cxsenssupportHi saadtiwana_int , Apologies for the delayed response. This forum is not actively monitored by all of our product specialists, so if you require quick support in the near future then it is best to send us an email at support@xsens.com . Your solution should indeed solve the problem. The key here is that this RotSensor matrix flips the sensor frame (that is printed on the side label of your MTi) upside-down. It basically inverts the direction of the Y- and Z-axes of your device while the X-axis is left pointing "forward". The MT Manager User Manual has been updated to refer to our BASE article instead.https://community.element14.com/products/manufacturers/xsens/f/forum/51841/specifying-mti-680-orientation-in-mt-manager/201267Tue, 11 Oct 2022 16:23:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:2e5c761f-9e10-47f1-95e2-90132f6a28e3saadtiwana_intOk, I have found a way to accomplish this. I read in the MT Manager user manual: "RotSensor and RotLocal: These two rotation matrices are used to apply orientation resets or arbitrary alignments." This gave me an idea and so here is what I did: After connecting the MTi-680 to computer and opening MT Manager, placed the sensor upside down, set the "Orientation Reset Method" to "Inclination Reset" and clicked the "Reset orientation" button. Then I pressed the "Save current orientation reset" button to save it in the device. The reason for saving to device was so that next time I open the "Device Settings" view, I can see the stored rotation matrix. In this case, i found it as following: As I expected, only the RotSensor was updated. In an ideal case, the values should have been 0, +1 or -1 but since my reference surface wasn't ideal, I saw some values very close to 0, +1 and -1. I then manuall changed them to the nearest amongst 0 , +1, -1 as follows: I then hit "Apply". And that's it. The new orientation was set to be upside down, while maintaining the original calibrated tilt alignments.https://community.element14.com/products/manufacturers/xsens/f/forum/51841/specifying-mti-680-orientation-in-mt-manager/201230Mon, 10 Oct 2022 16:03:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:0ad51421-88db-41bc-a4a1-62d7c5ba9d9asaadtiwana_intxsenssupport Forgot to mention, I also searched the info in Base, but couldn't find it there either. Possible that I am not looking in the right places or not using the right keywords. Kindly guide me on this. Regards, Saadhttps://community.element14.com/products/manufacturers/xsens/f/forum/51841/specifying-mti-680-orientation-in-mt-managerMon, 10 Oct 2022 16:02:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:a88348bc-1ee5-477c-be22-38247ba8ad3csaadtiwana_intHi, When the MTi-680 is mounted/used in a non-default orientation (for example when mounted upside down such that the connector is on top), how do I tell the module what the mounting orientation is? I have tried to search through the documentation. In the Device Settings window (in MT Manager) I have seen the RotSensor and RotLocal vectors, and my guess is that one of those is used to specify the mounting orientation (RotSensor?). However, the MT manager user manual doesn't give more details about it and asks to refer to the MTi Family Reference Manual, which is a dead end because I couldn't find the information there. I also tried looking up the information in the MTi-600 series User Manual but no luck. I have seen the "orientation Reset" control in the MT manager but I do not want to reset the module to any orientation, but rather want to utilize the calibration values to determine the orientation with the up-side-down mounting. Regards, SaadxsensMTi-680-DKhttps://community.element14.com/products/manufacturers/xsens/b/blog/posts/xsens-conference-the-future-of-mobile-warehouse-robotsTue, 11 Jan 2022 16:15:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:43e9dc4c-b1e6-4ea4-ae30-6906c14757fcxsenssupportIf you think about automation in warehouses, what comes to mind? Maybe you think about Forklifts, Stackers, or Pallet Jacks? Well, we think about Mobile Warehouse Robots. Mobile Warehouse Robots are (semi-) autonomous wheeled ground vehicles that transport materials or do some other logistic tasks. Traditionally they are called 'Automated Guided Vehicle' (AGV), but the 'Autonomous Mobile Robot' (AMR) will enter the stage as the latest advanced generation — with more intelligent and flexible navigation, having many sensors inside, e.g., Simultaneous Localization And Mapping ("SLAM"). This technology is similar to how the human brain works, combining memorized pictures of a situation with what eyes see. Why Mobile Warehouse Robots will be crucial to a warehouse: Improve accuracy in material handling (picking, towing, conveying, moving) Reduce physical and mental strain on human workers Automate tedious tasks With the rapid change of technology, warehouse robots are changing every day. Are you wondering about the future of Mobile Warehouse Robots? Register for our online conference, and learn more about it. ✔ ️Conference detail: ⚫ The Future of Mobile Warehouse Robots January 25th 10:00 AM CET Online Join our conference for free via: https://bit.ly/TheFutureofMobileWarehouseRobotsindoorxsenslidarimuagvnavigationhttps://community.element14.com/products/manufacturers/xsens/b/blog/posts/jeeves-robot-navigates-fully-autonomously-thanks-to-data-from-accurate-mti-610-imuTue, 11 Jan 2022 15:38:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:81d890b8-962f-4b1d-bbbf-c93af3d05ea3xsenssupportSuppose you have ever been staying in a room on the upper floor of a hotel and felt like indulging in a late-night snack or drink, but resisted the urge because you could not face trailing all the way down to the vending machine in the lobby. In that case, you will appreciate the new JEEVES ® room service robot from Germany-based Robotise . The fully autonomous service robot, called JEEVES, is the world’s first to comply with the European Union’s safety regulations governing the operation of robots in public spaces. And to navigate its way around complex, crowded multi-storey buildings such as hotels and hospitals, it needs highly accurate, reliable 3D motion tracking data – a requirement met by the compact MTi-610 sensor from Movella. Totally automated room service The JEEVES service robot can move on-demand to any location in a building accessible by elevator. Its modular design is based on an efficient motor base, on which a custom combination of materials-handling containers is mounted. In a hotel scenario, the JEEVES platform can be stocked at its loading station with snacks, sweets, and drinks. In a hospital, it might carry medical consumables such as bandages, disinfectant wipes, and sterile gloves. In an office, the JEEVES robot can be loaded with items such as printer paper, pens, staples, and so on. The JEEVES robot platform can be adapted for use in many different types of public spaces Robotise’s smart and innovative technology enables fully autonomous delivery of service orders –JEEVES navigates from the loading station to any programmed location on any floor. Its capabilities include summoning an elevator via the Robotise Operations Center (ROC) , a cloud service that gives users the 24/7 remote monitoring capability of a fleet of JEEVES robots. Fully automated room service, courtesy of the JEEVES robot In the hospitality sector, automation with the JEEVES robot enables a hotel to provide 24/7 room service, even though night when a single member of staff might run the front desk. In a hospital, the JEEVES robot frees valuable medical staff from the time-consuming task of answering service, rather than medical, calls from the wards, allowing them to focus their time on direct patient care. All of this is possible because of Robotise innovations which ensure that the JEEVES robot can navigate through complex, unstructured environments and detect obstacles and avoid collisions with people in its immediate environment. Reliable navigation in 3D space The key to the reliability of the JEEVES robot’s fully autonomous navigation is a multi-mode sensor system, in which errors in one mode can be detected and corrected by another. The primary method of navigation is a 3D ‘depth map’ derived from detailed LiDAR (infrared laser) scans of the entire building. These scans are tagged with essential location data such as room numbers and elevator doors. The robot’s LiDAR sensors scan the environment as it moves around, matching the scene to the reference database of depth maps to establish the location and to plot a route to the destination. The LiDAR sensors also detect objects such as people so that they can be safely avoided. In a multi-storey building, the ROC system connects to the elevator control software, telling the robot which floor it is on. These systems, however, can on occasion provide faulty or no information – for instance, inside an elevator the robot might lose its Wi-Fi ® connection to the ROC cloud, and so miss the elevator’s signal telling it which floor it is on. In addition, some locations appear very similar – long, uniform hotel corridors are an example – which means the robot could potentially match its sensor data to the wrong map location on rare occasions. In crowded areas such as a hotel lobby, the LiDAR sensors’ view of the area can be so obstructed that the robot cannot match any known location on equally rare occasions. This is where the alternative navigation mode kicks in, using precise motion data from a Movella MTi-610 series i nertial measurement unit (IMU) . The IMU produces an accurate stream of acceleration and rate-of-turn data in real-time. Through a process of dead reckoning, the robot uses the MTi-610 sensor’s outputs to calculate its movement in three dimensions from a known starting point. By measuring vertical motion in this way, the JEEVES robot can accurately determine which floor it is on, even without a connection to the ROC cloud. And by measuring motion in the horizontal plane, the robot can track its approximate location continuously. This enables the robot to override an apparent LiDAR map match that is not consistent with the MTi-610 sensor’s data and move temporarily by dead reckoning until it can match to the LiDAR depth map with a high degree of confidence. A compact, low-power IMU Robotise selected the Movella MTi-610 series because its features are particularly well suited to fully autonomous operation on battery power. Compact – the unit has a footprint of just 28mm x 31.5mm and weighs less than 10g – the MTi-610 enables accurate dead reckoning calculations thanks to its low noise density and low drift. Typical power consumption of less than 500mW also helps the JEEVES robot to maintain day-long operation on battery power. Tobias Riphaus, the Robotic Engineer at Robotise, says that the MTi-610 is a fail-safe back-up to the sophisticated LiDAR system of indoor navigation. ‘I have total confidence that the location information derived from the MTi-610 IMU is always going to be available to the JEEVES robot, and is going to be accurate enough to perform error correction on the LiDAR sensor. Robotise has tested the JEEVES platform exhaustively, in many different types of environments, and the MTi-610 sensor has never once let us down.’mobile robotsxsensinertial sensorsimumti-600 serieshttps://community.element14.com/products/manufacturers/xsens/b/blog/posts/interfacing-mti-devices-with-the-nvidia-jetsonFri, 07 Jan 2022 14:56:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:3243eaff-970c-4853-a1dd-c3d19bc02df6xsenssupportThe NVIDIA Jetson edge AI platform is widely used for the development of autonomous machines and robotics. In this article we will explain how to connect your Xsens MTi device to the NVIDIA Jetson hardware, and how to easily communicate with it by using our MT Software Development Kit (MT SDK). NVIDIA Jetson Developer Kits run on ARM Cortex CPUs, which means that they are not compatible with the regular Xsens Device API. Fortunately, Xsens has made a large part of the API open source , allowing users to develop applications for ARM-based platforms as well. Xsens provides C++ example codes as well as a ROS driver that make use of this open source API. We have used the Jetson Nano Developer Kit for this article, but the guidelines can also be used for other Jetson hardware. Xsens has tested the following motion trackers with the Jetson Nano: MTi 1-series Development Kit (USB, UART) MTi 600-series Development Kit (USB, UART) MTi 10-series (USB) MTi 100-series (USB) Setup Start by downloading the latest MT Software Suite for Linux from our website and unpack the .tar.gz package at your desired location. Then, install the MT SDK: sudo ./mtsdk_linux-xxx_xxxx. x.x.sh This article will cover two hardware interfaces of the Jetson D eveloper Kit : USB and TTL UART. If possible, we recommend using USB as a starting point, to verify that your hardware and software can detect and communicate with external sensors. Simply connect your MTi to one of the USB ports of the Jetson D eveloper Kit using the USB cable included in your Development Kit. 1. C++ example codes Inside the MT SDK you will find an examples folder. Open it and navigate to the xda_public_cpp folder. You will find two example codes: example_mti_receive_data : Scans for, and connects with MTi devices, configures their outputs, and prints/logs the received data. example_mti_parse_logfile : Opens a .mtb log file and parses its contents. In this folder, open a terminal and build the example codes: sudo make Note: If you are using the MTi 10-series or MTi 100-series with a direct USB cable , make sure to have libusb installed, and build the examples using: sudo make HAVE_LIBUSB=1 You should end up with two executable files, one for each example code. Upon executing example_mti_receive_data your connected MTi should be detected automatically. We refer to the Troubleshooting section of this article if the MTi is not detected. 2. ROS driver Inside the MT SDK you will find the xsens_ros_mti_driver . Simply follow the README.txt file inside this folder or our guidelines at http://wiki.ros.org/xsens_mti_driver to install and launch the ROS driver. Your MTi should be detected automatically, and a variety of data topics are available to subscribe to. We refer to the Troubleshooting section at the end of this article if the MTi is not detected. Note: the ROS driver publishes data, but unlike the C++ example code, it does not actually configure the outputs of the MTi. Use the C++ example code or a PC with our GUI MT Manager to configure the MTi such that it outputs the data that are required for your application. Serial hardware interfaces Next to the plug-and-play USB interface, Jetson D eveloper Kit offer various other interfaces that allow you to communicate with MTi devices. In the case of the Jetson Nano, we used a UART interface that is accessible via the J41 header, pins 8 (TxD) and 10 (RxD). We also used the 3V3/5V and GND pins on that same header to power the MTi. Note: The UART interface of an MTi 1-series Development Board will be disabled when the board is powered at 5V. Use the 3.3V output of the Jetson D eveloper Kit instead. In Ubuntu, this UART port will show up as /dev/ttyTHS1. By default, the ROS driver and C++ example code do not scan this location. Fortunately, it is easy to modify the source code such that it scans for your specific location: Open example_mti_receive_data.cpp (in case of the C++ example code) or xsens_ros_mti_driver/src/xdainterface.cpp (in case of the ROS driver) and replace the following lines: XsPortInfoArray portInfoArray = XsScanner::scanPorts(); XsPortInfo mtPort; for (auto const &portInfo : portInfoArray) { if (portInfo.deviceId().isMti() || portInfo.deviceId().isMtig()) { mtPort = portInfo; break; } } with XsPortInfo mtPort = XsScanner::scanPort("/dev/ttyTHS1",XBR_230k4); ...where in this case we scan "/dev/ttyTHS1" for an MTi device that is configured at a baud rate of 230400 bps. Alternatively, the ROS driver also allows you to configure the desired port and baud rate manually without modifying the source code. To do so, uncomment and modify the following lines in the file xsens_mti_node.yaml , located at xsens_ros_mti_driver/param: # port: '/dev/ttyUSB0' # baudrate: 921600 You should now be able to detect and access the MTi via the UART interface. Troubleshooting “No MTi device found.” or “Could not open port.” Ensure that you have the rights to access the port of the MTi (e.g. /dev/ttyUSB0). If you are using the C++ example code, you can check this by executing the code with sudo. Possibly you are not in the right group to access the port of the MTi. See MTSDK.README , located in your MT SDK folder, for further guidelines on changing group access permissions. If you are using the MTi 10-series or MTi 100-series with a direct USB cable , make sure to have libusb installed, and build your code as: sudo make HAVE_LIBUSB=1 If you are using a robust MTi 600-series with a USB dongle , make sure to have the relevant drivers installed . If you are not using the USB port or if you are using a custom serial-to-USB converter, try specifying the exact port and baud rate at which your MTi is communicating. See paragraph Serial hardware interfaces of this article. My USB-connected MTi does not show up as /dev/ttyUSB#. If you are using the MTi 10-series or MTi 100-series with a direct USB cable , then it is not necessary for the MTi to show up as /dev/ttyUSB#. Make sure to have libusb installed, and build your code as: sudo make HAVE_LIBUSB=1 The MTi should now be recognized whenever you launch the ROS driver or C++ example code. If you do require the device to show up as /dev/ttyUSB#, recompiling the kernel module or reinstalling the USB driver can help. This is typically seen with AGX/TX1/TX2 platforms: https://github.com/xsens/xsens_mti_ros_node/issues/53 https://forums.developer.nvidia.com/t/tx2-and-xsens-imu-through-micro-usb-adapter/49583/5 https://forums.developer.nvidia.com/t/xavier-cannot-recognize-xsens-solved/66673/16 https://xsenstechnologies.force.com/knowledgebase/s/question/0D52o0000BI1JERCQ3/mti300-interfacing-with-nvidia-tx1-platform-kernel-31096 The data I am receiving never reaches the expected data output rate (e.g. 400 Hz). We have noticed that the ROS node can cause a high CPU load, leading to lower data output rates. This issue has been fixed in ROS nodes available in MTSS2019.3.2 and later. We recommend migrating to the latest version. If you have connected the MTi via the USB interface, we recommend enabling the low latency mode using setserial: Install setserial if not already installed Enable low latency mode: setserial [/path/to/xsens/port] low_latency Check the output rate of the published topics, e.g: rostopic hz imu/data Note that the low_latency mode is lost after rebooting, so you will probably need to create a udev rule for this. Error "Skipping incompatible xxx when searching for xxx" after catkin_make. Try inserting the following at the end of your CMakeLists.txt: add_custom_COMMAND(TARGET xsens_mti_node PRE_BUILD COMMAND $(MAKE) --always-make -j 1 -C ${CMAKE_CURRENT_SOURCE_DIR}/lib/xspublic ) Still facing challenges? Don’t hesitate to contact our Product Specialists for further support.insxsensinertial sensorsjetsonimumti-100nvidiamti 1-series modulemti-600 serieshttps://community.element14.com/products/manufacturers/xsens/b/blog/posts/interfacing-the-mti-680g-with-a-racelogic-vbox-ntrip-modemFri, 07 Jan 2022 14:41:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:8c47688f-be47-4960-94db-0792c1a2251axsenssupportThis article describes how to interface the MTi-680(G) with the Racelogic VBOX NTRIP modem in order to receive the RTK corrections from an NTRIP client. NTRIP (Networked Transport of RTCM via Internet Protocol) is a protocol that enables streaming of RTK correction data via the internet over common TCP/IP methods. These NTRIP services can be accessed via paid subscription or free-to-use broadcasters. Here you can find a list of NTRIP casters and providers in different parts of the word: https://ntrip-list.com/ The Racelogic VBOX NTRIP is part of the Racelogic VBOX Systems which are used by vehicle and tyre manufacturers for testing and validating a vehicle’s performance, handling and safety systems. This NTRIP modem is used to receive positional correction data via an internet connection. The NTRIP configuration is made via a Wi-Fi access point and the front screen will display status and connection information. Figure 1: Racelogic VBOX NTRIP modem Interfacing The circuit diagram in Figure 2 shows how to connect the RTCM connector of the MTi-680G to the Racelogic NTRIP modem. This setup can be realized by using the CA-MP4-MTi cable. The wire map for this cable can be found in the MTi-600-Series Development Kit User Manual . The pin description of the Racelogic NTRIP modem connector can be found in the Racelogic VBOX NTRIP modem User Guide . The Racelogic NTRIP modem is using the main connector to output the RTCM messages. This connector must be connected to the RTCM correction port of the MTi-680G. Figure 2: MTi-680G and Racelogic NTRIP modem connection Please note the following power supply remark for the Racelogic NTRIP modem: There are two ways for the Racelogic NTRIP modem to connect to an NTRIP server, namely via: Wi-Fi network: You can power the Racelogic NTRIP modem using a USB cable. This is applicable only if you want to use the Racelogic modem with a Wi-Fi network. 4G Modem (using SIM card): If you want to use the 4G Modem function then you will need to connect the Racelogic modem to an external 12V DC (7 – 30V) power supply. The 4G Modem is disabled if you are powering the device via USB. The RTCM connector of the MTi-680G does not offer a power supply; you will have to connect the Racelogic NTRIP Modem connector to an external power supply. Configuration Start by configuring the MTi-680(G) RTCM port baud-rate settings and output configuration. The easiest way to do this is by using our GUI, MT Manager, which is part of the MT Software Suite . In MT Manager, open the Device Settings window ( ). In the Device Settings Tab, set the RTCM port baudrate to 115200. Click Apply. In the Output Configuration tab, make sure the Status Word, Position and Velocity outputs are enabled, this will help us later check the RTK status fix. Choose a high-resolution output format, such as Fixed Point 16.32 or Float 64-bit. Click Apply. Once the MTi-680(G) is configured follow the instructions in the Racelogic NTRIP Modem Quick Guide to connect to an NTRIP client and start outputting RTK corrections. Once the configuration is complete, the Racelogic NTRIP modem should be connected to an NTRIP client and receive-output RTK corrections: Figure 3: RTK fix indication of Racelogic NTRIP modem Once that is implemented, the received RTCM messages are forwarded to MTi-680(G). After launching MT Manager, you should be able to confirm an RTK Float/Fix using the StatusWord message or the RTK Status flag: Status Word: Open the Device Data view ( ) to view Status Word message. The 5th bit from the left indicates RTK Float, the 4th and 5th bit from the left together indicate an RTK fix. More information regarding the contents of Status Word message can be found in the Low Level Communication Protocol Documentation . Figure 4: StatusWord message in the Device Data View RTK Status flag: Open the Status Data window ( ) to view the status of the RTK flag ra Figure 5: RTK high(fix) in Status Data window Interfacing the Racelogic NTRIP modem with the MTi-680 Development Kit The MTi-680-DK comes with an external RTK GNSS daughter card. In this case you can feed the Racelogic NTRIP modem RTCM corrections directly to the RTK GNSS daughter card. The Racelogic NTRIP modem RTCM outputs must be connected to the XBee socket of the external MTi-680 DK RTK GNSS daughter card. The XBee socket pinning can be found in the MTi-600-Series Development Kit User Manual . Troubleshooting I am connected to an NTRIP client but I can not get an RTK fix with the Racelogic NTRIP modem: If you are powering the NTRIP modem via USB make sure you are using a high quality USB cable If the problem persists power the NTRIP modem via an external power supply Make sure you have an active internet connection (via Wi-Fi or GSM) Make sure the antenna of the NTRIP modem has a clear view of the sky Ensure that the NTRIP server you are connected to is not using base stations which are far away (>25 km) from your location, try another mount point or another NTRIP server The Racelogic NTRIP modem reports an RTK fix but the MTi-680(G) RTK flag shows a float/low status Check the baudrate RTCM port settings of MTi-680(G); the baudrate should be set to 115200 The GNSS antenna of the MTi-680(G) should have a clear view of the sky and the MTi-680(G) should report a GNSS Fix (GNSS flag high)insxsensinertial sensorsrtkmtiimuracelogicgnssmti-600 serieshttps://community.element14.com/products/manufacturers/xsens/b/blog/posts/mikrobus-transceiver-compatibility-of-the-mti-1-series-development-boardFri, 07 Jan 2022 14:33:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:3ada227c-3ca9-49dd-b6aa-42db8c10b4d7xsenssupportWhen testing or evaluating the MTi 1-series we highly recommend purchasing a Development Kit, such as the MTi-3 Development Kit or the MTi-7 Development Kit . The Development Board included in this Kit features many different options to communicate with your MTi 1-series device, such as a micro-USB interface and Arduino-compatible headers for UART, SPI and I²C communication. In addition to this, the Development Board features two mikroBUS extension sockets , one for connecting an external GNSS receiver (MTi-7-DK only) and one for regular communication purposes. This latter communication port can be found on headers P202 and P203 as indicated in the figure below. For the exact pin descriptions, refer to the MTi 1-series DK User Manual . Figure 1: MTi 1-series Development Board. P202 and P203 (bordered in red) together follow the mikroBUS header standard. The mikroBUS communication extension socket allows users to further extend the communication capabilities of the MTi 1-series Development Board. Because of the mikroBUS standard there are various off-the-shelf "click boards" available that can be mounted here, including boards for serial and wireless communication. Refer to Mikro Elektronika's webshop for a large range of available click boards. The table below shows a list of transceiver click boards that have been tested with the MTi 1-series Development Board. For some click boards, additional configuration is necessary; see the configuration column. Board Vendor link Compatibility Configuration RS232 Click Mikro Elektronika Farnell Verified compatibility Full-duplex: Set PSEL0/PSEL1 to 0/0. RS232 2 Click Mikro Elektronika Farnell - Hardware flow control not supported; RTS/CTS pins reversed. RS485 Click 3.3V* Mikro Elektronika Verified compatibility Half-duplex: Set PSEL0/PSEL1 to 1/0. Bluetooth Click Mikro Elektronika Verified compatibility RST functionality needs to be disabled**. Can be configured to act as a serial bridge in Windows ("Standard Serial over Bluetooth Link (COM)"), making it fully compatible with the MT Software Suite. Notes: *The extension sockets of the MTi 1-series Development Board do not offer a 5V power supply! Click boards can only be supplied at 3.3V. **Pay attention to the RST pin functionality of mikroBUS click boards. The MTi 1-series Development Board has an active pull-down on this pin, which may conflict with click boards that feature an active-low ( n RST) pin. ***The extension socket of the MTi 1-series Development Board will be disabled if the Board is powered at 5V (e.g. through micro-USB)! In order to enable the extension socket you will need to power the board at max. 3.6V. Refer to this page for more information. If you have any questions regarding this list, please do not hesitate to contact our product specialists .insxsensinertial sensorsmikroeimumti 1-series modulehttps://community.element14.com/products/manufacturers/xsens/b/blog/posts/mikrobus-gnss-compatibility-of-the-mti-1-600-series-development-boardFri, 07 Jan 2022 13:58:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:6f9f2117-bbaa-40f5-81a1-7fea42bf3d10xsenssupportSome of Xsens' GNSS/INS devices, such as the MTi-7, MTi-670 and MTi-680, support the use of an external GNSS receiver. When testing or evaluating these products we highly recommend purchasing a Development Kit. The MTi-7-DK and MTi-670/680-DK include a Development Board, GNSS daughter card and GNSS antenna, which means that all required hardware is available to get started right away. For the MTi-7-DK and MTi-670-DK, the included GNSS daughter card features the u-blox MAX-M8Q GNSS receiver, which is a commonly used, standard precision GNSS receiver. The MTi-680-DK comes with a GNSS daughter card that features the u-blox ZED-F9P. However, it is easy to connect any other desired type or brand of GNSS receiver. The GNSS extension socket on the Development Boards follows Mikro Elektronika's mikroBUS standard . This means that a wide variety of GNSS daughter cards ( click boards ) is available that can be directly mounted onto the Development Board's GNSS extension socket. Figure 1: MTi 1-series (left) and MTi 600-series (right) Development Boards without their GNSS daughter card mounted. The GNSS extension socket at the top/middle of the board follows the mikroBUS header standard. The table below shows a list of GNSS click boards that have been tested with the MTi-7-DK, MTi-670-DK and MTi-680-DK. For some click boards, additional configuration is necessary; see the configuration column. Board Vendor link Farnell link Compatibility Configuration u-blox MAX-M8Q Included with MTi-7-DK and MTi-670-DK Verified compatibility and performance - u-blox ZED-F9P Included with MTi-680-DK Verified compatibility and performance - u-blox NEO-M8N Mikro Elektronika Farnell Verified compatibility - u-blox NEO-M9N Mikro Elektronika Verified compatibility Need to manually enable port UART1 at 115200 bps using u-center (UBX-CFG-PRT message). u-blox ZOE-M8Q Mikro Elektronika Farnell Verified compatibility - u-blox SAM-M8Q Mikro Elektronika Farnell Verified compatibility Compatible with MTi-670-DK revision 1.7 (introduced Nov 2021) and higher. Compatible with MTi-7/680-DK (all versions). If you have any questions regarding this list, please do not hesitate to contact our product specialists . It is also possible to connect GNSS receivers to the GNSS extension socket without following the mikroBUS standard. In that case it is recommended to connect the RX, TX, GND and PPS pins. TX (of the MTi) is only required when communicating with u-blox GNSS receives as the MTi will send out UBX configuration messages at power-up. The PPS signal is not required but recommended for proper time/clock synchronization. The GNSS extension socket also features a 3.3V pin that can supply power to the GNSS receiver (and its antenna), but depending on the type of GNSS receiver the provided current might not be sufficient. The GNSS extension socket of the MTi 1-series Development Board only supports communication at UART TTL levels. The MTi 600-series Development Board also uses UART TTL communication by default, but a jumper can be placed at GNSS_DIS in order to enable RS232 communication.insxsensinertial sensorsmikroeimugnssmti 1-series modulemti-600 serieshttps://community.element14.com/products/manufacturers/xsens/b/blog/posts/interfacing-an-mti-gnss-ins-device-with-a-hesai-lidarThu, 23 Dec 2021 16:49:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:8341db1f-eef1-4534-9377-63d180bd1d04xsenssupportDisclaimer: In line with our RMA Terms & Conditions, the warranty on hardware devices shall be null and void if the product has been subject to improper installation. It is advised to carefully read the latest version of the HESAI PandarXT manual as well as the MTi product's Datasheet and Hardware Integration Manual (available here ) before connecting your hardware. Note: This tutorial will configure the MTi-G-710 and MTi-670 to output its data in response to their own GNSS 1 PPS signal. This means that the MTi will not provide any data as long as there is no valid GNSS time/position fix (except when using the CAN interface, refer to the end of this article for more details). Depending on the amount of satellites in view it can take several minutes until the 1 PPS signal is obtained by the GNSS receiver. Introduction This article describes how to interface your GNSS/INS device with a HESAI Lidar. HESAI Lidars accept a GPS input which allows their data to be correlated with position. For this purpose a GPS 1PPS signal and a 1 Hz RS232 $GPRMC or $GPGGA message are required. Both the MTi-G-710 and the MTi-670 support these outputs. HESAI however does have some communication and timing constraints for external GNSS/INS devices, which can be found in the HESAI PandarXT User Manual . Most importantly the MTi needs to be configured such that it transmits the RS232 message shortly after transmitting the 1 PPS signal. This article describes how to configure your MTi in order to meet these requirements. The two setups presented in this article have been tested using a HESAI PandarXT32 Lidar. The HESAI Lidar comes with an Connection Box that includes a terminals with connections for power, GPS communication and Ethernet. In this article the connections GROUND, +5V, PPS and GPS Receive are used. Figure 1: HESAI Connection Box Setup 1: MTi-G-710 Configuration Start by configuring your MTi-G-710 to output the correct NMEA string and time data. The easiest way to do this is by using our GUI, MT Manager, which is part of the MT Software Suite . In MT Manager, open the Device Settings window ( ). In the Output Configuration tab, select "String report mode" and choose "GPGGA" and/or "GPRMC". Choose "400 Hz" from the drop-down menu. Click Apply. In the Device Settings tab, set the COM port baud rate to 9600 bps. Click Apply. In the Synchronization Options tab, the "GNSS Clock In" feature should already be present in the list of configured settings. Click Add, and select the 1PPS Time-pulse function. Leave the other fields as is. This will create a 1 PPS signal on the SyncOut line of the MTi. Click Add, and select the Send Latest (In) function. Leave the other fields as is. This will configure the MTi to transmit its most recent data sample when triggered on the SyncIn line. We will later connect the SyncIn and SyncOut. Click Apply. Interfacing The circuit diagram in Figure 2 shows how to connect your MTi-G-710 to the HESAI Connection Box. Please note the following: For testing purposes it is possible to power the MTi-G-710 directly using the 5V supply available in the Connection Box. We do however recommend powering the MTi-G-710 separately while meeting the requirements mentioned in the MTi User Manual . This setup can be realized by using the CA-MP2-MTi cable . The wire map for this cable can be found in the MTi User Manual. Figure 2: Interfacing the MTi-G-710 with the HESAI Connection Box. Setup 2: MTi-670 Configuration Start by configuring your MTi-670 to output the correct NMEA string and time data. The easiest way to do this is by using our GUI, MT Manager, which is part of the MT Software Suite . In MT Manager, open the Device Settings window ( ). In the Output Configuration tab, select "String report mode" and choose "GPGGA" and/or "GPRMC". Choose "400 Hz" from the drop-down menu. Click Apply. In the Device Settings tab, set the RS232 Protocol to "String Output" and the RS232 baud rate to 9600 bps. Click Apply. In the Synchronization Options tab, the "Clock Bias Estimation (In)" and the "1PPS Time-pulse" features should already be present in the list of configured settings, both on line In 2. Click Add, and select the Send Latest (In) function. Choose Line "In 2". Leave the other fields as is. This will configure the MTi to transmit its most recent data sample when triggered by the 1PPS signal on the SyncIn2 line. Click Apply. Interfacing The circuit diagram in Figure 3 shows how to connect your MTi-670 to the HESAI Connection Box. Please note the following: For testing purposes it is possible to power the MTi-670 directly using the 5V supply available in the Connection Box. We do however recommend powering the MTi-670 separately while meeting the requirements mentioned in the MTi 600-series Hardware Integration Manual . As mentioned in the MTi 600-series Hardware Integration Manual, the RS232 CTS line of the MTi-670 needs to be tied to a logical high (3-25V). Otherwise the MTi will not transmit data over the RS232 interface. This setup can be realized by using the MTi-670 Development Board. In that case the 1 PPS signal from the GNSS receiver daughter card is already connected to SyncIn2. Figure 3: Interfacing the MTi-670 with the HESAI Connection Box. Setup 3: MTi-670G/680G In contrast to the MTi-G-710, the MTi-670G/680G does not yet offer a “true” 1 PPS output that comes straight from the internal GNSS receiver. Instead, by using the Interval Transition Measurement synchronization feature, the MTi-670G/680G can be configured to generate its own 1 PPS signal that is synchronized with the 1 PPS signal of the internal receiver. This pulse will be synchronized with the internal GNSS 1 PPS pulse in terms of frequency, but not in terms of phase. This means that the 1 PPS output of the MTi-670G/680G does not appear at the exact start of each UTC second. The timing of the pulse depends on the moment you power up the MTi. The MTi-670G/680G does provide sub-second data in its NMEA messages, however some lidar brands do not copy the full UTC time information from the $GPGGA or $GPRMC packets: They often assume that the 1 PPS signal and its corresponding data packet c oincide with the start of a UTC second, and therefore the sub-seconds field is assumed to be zero. This can cause a data timing error of up to 1 second. Configuration Start by configuring your MTi-680G to output the correct NMEA string and time data. The easiest way to do this is by using our GUI, MT Manager, which is part of the MT Software Suite . In MT Manager, open the Device Settings window ( ). In the Output Configuration tab, select "String report mode" and choose "GPGGA" and/or "GPRMC". Choose "400 Hz" from the drop-down menu. Click Apply. In the Device Settings tab, set the RS232 port baud rate to 9600 bps and the Protocol to String Output. Click Apply. In the Synchronization Options tab, the "Clock Bias Estimation" and “1PPS Time-pulse” features should already be present in the list of configured settings. Click Add, and select the Interval Transition Measurement function. Set Skip Factor to 399. Leave the other fields as is. This will create a 1 PPS signal on the SyncOut line of the MTi. Click Add, and select the Send Latest (In) function. Leave the other fields as is. This will configure the MTi to transmit its most recent data sample when triggered on the SyncIn line. We will later connect the SyncIn and SyncOut lines. Click Apply. Interfacing The circuit diagram in Figure 4 shows how to connect your MTi-680G to the HESAI Connection Box. Please note the following: For testing purposes it is possible to power the MTi-680G directly using the 5V supply available in the Connection Box. We do however recommend powering the MTi-680G separately while meeting the requirements mentioned in the MTi 600-series Hardware Integration Manual . This setup can be realized by using the CA-MP-MTI-12 cable . The wire map for this cable can be found in the MTi 600-series Development Kit User Manual . Figure 4: Interfacing the MTi-680G with the HESAI Connection Box. HESAI Lidar Configuration Start by configuring your HESAI Lidar to recieve the MTi's sync signal and NMEA Data. For this example the Web Control Page (Pandar Console) was used. Configure the highlighted portions of HESAI Lidar's Settings as Shown below and click Save - Clock Source: GPS - NMEA Sentence: GPRMC or GPGGA Troubleshooting How can I check whether the 1 PPS signal and NMEA string messages are received properly? You can use the Ethernet connection to open the HESAI User Interface (see below screenshot). The User Interface will show a real-time display of the GPS UTC Time and PPS status. Why does my MTi-G-710 not output $GPRMC data? The $GPRMC message is only supported by firmware versions 1.10.0 and up. Check the firmware version of your device using MT Manager and if necessary, update to the latest firmware by using our Firmware Updater . The MTi-670 firmware has always supported the $GPRMC message. Can I configure the MTi to output other data next to the $GPRMC and/or $GPGGA strings? The MTi can be configured to also output other (NMEA) string outputs when triggered by the 1 PPS signal, as long as the 9600 bps baud rate allows for it. Additionally, the MTi 600-series allows for outputting data over the UART (IP51 modules only) and CAN interfaces as well, in parallel with the RS232 interface. Both the UART and RS232 interface will then only report data when triggered by the 1 PPS pulse. The CAN interface does not support the SendLatest functionality and therefore it will simply transmit its data at the configured data rate.mobile robotsinsxsensinertial sensorslidarimumti-100gnssmti-600 seriesnavigationhesaihttps://community.element14.com/products/manufacturers/xsens/b/blog/posts/interfacing-an-mti-gnss-ins-device-with-an-ouster-lidarThu, 23 Dec 2021 13:27:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:61b1a0a4-df2a-4653-9fbf-c60b5d9c6615xsenssupportDisclaimer: In line with our RMA Terms & Conditions, the warranty on hardware devices shall be null and void if the product has been subject to improper installation. It is advised to carefully read the latest versions of the Ouster Documentation as well as the MTi product's Datasheet and Hardware Integration Manual (available here ) before connecting your hardware. Introduction This article describes how to interface your GNSS/INS device with an Ouster Lidar. Ouster Lidars accept a GPS input which allows their data to be correlated with position. For this purpose a GPS 1PPS signal and a UART $GPRMC message are required. The MTi-670/680 support these outputs. This article describes how to configure your MTi in order to meet these requirements. The MTi-670G, MTi-680G and MTi-G-710 (encased versions with internal GNSS receiver) do not offer a 3.3V UART interface. An RS232-UART converter is required for these devices. For more information on Ouster's sensors, please visit Ouster's website at ouster.com or contact the Sales team at lidar@ouster.io . The setup presented in this article has been tested using an Ouster OS1 Lidar. Overview of Ouster digital lidar sensors The Ouster Lidar comes with an Interface Box that includes a terminal with connections for Power, Ethernet, Sync, Multi Purpose, and Ground. In this article, the connections GND, SYNC_PULSE_IN, and MULTIPURPOSE_IO are used to connect to the MTi. Figure 1: Ouster Interface Box Setup 1: MTi-670/680-DK Hardware Interface The circuit diagram in Figure 3 shows how to connect your MTi-670 (or MTi-680) to the Ouster Interface Box. Figure 2: Interfacing the MTi-670 (or MTi-680) with the Ouster Interface Box. On the external connector of the MTi-670/680 DK connect Pin 10 (SYNC_IN2) to the SYNC_PULSE_IN pin in the Ouster Interface Box. On the external connector of the MTi-670/680 DK connect Pin 14 (GND) to the GND pin in the Ouster Interface Box. On the external connector of the MTi-670/680 DK connect Pin 15 (UART_TX) to the MULTIPURPOSE_IO pin in the Ouster Interface Box. Please note the following: The MTi-670/680 will need to be powered separately from the Ouster Lidar, meeting the requirements mentioned in the MTi 600-series Hardware Integration Manual . The MTi-670/680-DK can be powered by using the USB connection connected to a PC. Ensure a good GNSS fix by testing in an area where the MTi-67/680-DK’s GNSS antenna has a clear view of the sky, so that the GNSS 1 PPS signal is available to be synced with the Ouster Lidar. MTi-670/680-DK Configuration Start by configuring your MTi-670/680 to output the correct NMEA string and time data. The easiest way to do this is by using our GUI, MT Manager, which is part of the MT Software Suite . In MT Manager, open the Device Settings window ( ). In the Device Settings tab, set the UART Protocol to "String Output" and the UART baud rate to 115200 or 9600 bps. Click Apply. In the Output Configuration tab, select the "String report mode" tab and enable "GPRMC". Select an output rate from the drop-down menu. Click Apply. You may need to lower the output rate if the baud rate cannot support the selected output rate. In MT Manager this will result in data overflow warning messages shown at the bottom of the screen. At a baud rate of 115200 bps, we recommend a maximum output rate of 100 Hz. The Ouster lidar only requires data at 1 Hz. In the Synchronization Options tab, the "Clock Bias Estimation (In)" and the "1PPS Time-pulse" features should already be present in the list of configured settings, both on line In 2. Setup 2: MTi-670G/680G Hardware Interface The circuit diagram in Figure 4 shows how to connect your MTi-670G/680G to the Ouster Interface Box. Figure 4: Interfacing the MTi-670G/680G with the Ouster Interface Box. Connect the SYNC_OUT line (blue/white) of the MTi to the SYNC_PULSE_IN pin in the Ouster Interface Box. The SYNC_OUT line can also be accessed by opening up the Xsens USB converter dongle. Connect one of the GND lines (black or blue) of the MTi to the GND pin in the Ouster Interface Box, with the RS232-UART converter in between . The GND line can also be accessed by opening up the Xsens USB converter dongle. Connect the RS232_TxD line (yellow) of the MTi to the MULTIPURPOSE_IO pin in the Ouster Interface Box, with the RS232-UART converter in between . Connect the RS232_CTS line (orange) of the MTi to a logical high (3V-25V), for instance to your MTi power supply line. The RS232_CTS line needs to be tied to a logical high in order to make the MTi transmit its data continuously. Please note the following: The MTi-670G/680G will need to be powered separately from the Ouster Lidar, meeting the requirements mentioned in the MTi 600-series Hardware Integration Manual . The MTi-670G/680G can be powered by using the USB dongle connected to a PC. Ensure a good GNSS fix by testing in an area where the MTi-670G/680G’s GNSS antenna has a clear view of the sky, so that the GNSS 1 PPS signal is available to the device. The MTi-670G/680G will synchronize its own clock with this trigger, and output a separate 1 PPS signal to be synced with the Ouster Lidar. MTi-670G/680G Configuration Start by configuring your MTi-670G/680G to output the correct NMEA string and time data. The easiest way to do this is by using our GUI, MT Manager, which is part of the MT Software Suite . In MT Manager, open the Device Settings window ( ). In the Device Settings tab, set the RS232 Protocol to "String Output" and the RS232 baud rate to 115200 or 9600 bps. Click Apply. In the Output Configuration tab, select the "String report mode" tab and enable "GPRMC". Select an output rate from the drop-down menu. Click Apply. You may need to lower the output rate if the baud rate cannot support the selected output rate. In MT Manager this will result in data overflow warning messages shown at the bottom of the screen. At a baud rate of 115200 bps, we recommend a maximum output rate of 100 Hz. The Ouster lidar only requires data at 1 Hz. In the Synchronization Options tab, the "Clock Bias Estimation (In)" and the "1PPS Time-pulse" features should already be present in the list of configured settings. Click "Add", and select the Interval Transition Measurement function. Set Skip Factor to 399. Leave the other fields as is. This will create a 1 PPS signal on the SYNC_OUT line of the MTi. Ouster Lidar Configuration Start by configuring your Ouster Lidar to receive the MTi’s sync signal and NMEA data. If using Ouster Studio, configure the highlighted portions of Ouster Lidar’s Advanced Config as shown below: If using TCP protocol, follow these step to configure the Ouster Lidar: Set the timestamp_mode to TIME_FROM_SYNC_PULSE_IN - TCP command: set_config_param timestamp_mode TIME_FROM_SYNC_PULSE_IN Set the multipurpose_io_mode to INPUT_NMEA_UART - TCP command: set_config_param multipurpose_io_mode INPUT_NMEA_UART Set the polarity of the sync_pulse_in pin to match the GPS PPS polarity - TCP command: set_config_param sync_pulse_in_polarity ACTIVE_HIGH Set the polarity of the multipurpose_io pin to match the GPS NMEA UART polarity - TCP command: set_config_param nmea_in_polarity ACTIVE_HIGH Set the nmea_baud_rate to match the GPS NMEA baud rate - TCP command: set_config_param nmea_baud_rate Set the nmea_leap_second to match the current leap seconds as defined by TIA at this website , at time of writing this the leap seconds are 37 - TCP command: set_config_param nmea_leap_seconds 37 Reinitialize and write the configuration a. TCP command: reinitialize b. TCP command: save_config_params Troubleshooting How can I check whether the 1 PPS signal and NMEA string messages are received properly? You can check the output from the TCP command: get_time_info Verify that the sensor is locked onto the PPS signal - ”sync_pulse_in": { "locked": 1 Verify that the sensor is locked on the NMEA signal - “nmea": { “locked”: 1 Verify that last_read_message looks like a valid GPRMC sentence - "decoding": {"last_read_message":"GPRMC,024041.00,A,5107.0017737,N,11402.3291611,W,0.080,323.3,020420,0.0,E,A*20" Verify that timestamp time has updated to a reasonable GPS time - "timestamp": { "time": 1585881641.96139565999999, "mode": "TIME_FROM_SYNC_PULSE_IN", "time_options": { "sync_pulse_in": 1585881641 Can I configure the MTi to output other data next to the $GPRMC strings? The MTi can be configured to also output other (NMEA) string outputs when triggered by the 1 PPS signal, as long as the 9600 bps or 115200 bps baud rate allows for it. Additionally, the MTi 600-series allows for outputting data over the UART and CAN interfaces in parallel with the RS232 interface. Ouster Sensor overview.pdfinsxsensinertial sensorslidarimumti-100gnssmti-600 seriesousterhttps://community.element14.com/products/manufacturers/xsens/b/blog/posts/interfacing-an-mti-gnss-ins-device-with-a-velodyne-lidarThu, 23 Dec 2021 12:52:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:2517b27d-0514-45ce-be0d-ae607262d97axsenssupportDisclaimer: In line with our RMA Terms & Conditions, the warranty on hardware devices shall be null and void if the product has been subject to improper installation. It is advised to carefully read the latest version of the Velodyne Interface Box Manual as well as the MTi product's Datasheet and Hardware Integration Manual (available here ) before connecting your hardware. Note: This tutorial will configure the MTi-G-710 and MTi-670/680 to output its data in response to their own GNSS 1 PPS signal. This means that the MTi will not provide any data as long as there is no valid GNSS time/position fix (except when using the CAN interface, refer to the end of this article for more details). Depending on the amount of satellites in view it can take several minutes until the 1 PPS signal is obtained by the GNSS receiver. Introduction This article describes how to interface your GNSS/INS device with a Velodyne Lidar. Velodyne Lidars accept a GPS input which allows their data to be correlated with position. For this purpose a GNSS 1PPS signal and a 1 Hz RS232 $GPRMC or $GPGGA message are required. Both the MTi-G-710 and the MTi-670/680 support these outputs. Velodyne however does have some communication and timing constraints for external GNSS/INS devices, which can be found in the Velodyne Interface Box Manual . Most importantly the MTi needs to be configured such that it transmits the RS232 message shortly after transmitting the 1 PPS signal. This article describes how to configure your MTi in order to meet these requirements. The MTi-670G/680G do not offer a true GNSS 1PPS, but a workaround is possible and will be discussed later in this article. The setups presented in this article have been tested using a Velodyne VLP-16 Lidar. The Velodyne Lidar comes with an Interface Box that includes a screw terminal with connections for power, GPS communication and Ethernet. In this article the connections GROUND, +12V, GPS PULSE and GPS RECEIVE are used. Figure 1: Velodyne Interface Box Setup 1: MTi-G-710 Configuration Start by configuring your MTi-G-710 to output the correct NMEA string and time data. The easiest way to do this is by using our GUI, MT Manager, which is part of the MT Software Suite . In MT Manager, open the Device Settings window ( ). In the Output Configuration tab, select "String report mode" and choose "GPGGA" and/or "GPRMC". Choose "400 Hz" from the drop-down menu. Click Apply. In the Device Settings tab, set the COM port baud rate to 9600 bps. Click Apply. In the Synchronization Options tab, the "GNSS Clock In" feature should already be present in the list of configured settings. Click Add, and select the 1PPS Time-pulse function. Leave the other fields as is. This will create a 1 PPS signal on the SyncOut line of the MTi. Click Add, and select the Send Latest (In) function. Leave the other fields as is. This will configure the MTi to transmit its most recent data sample when triggered on the SyncIn line. We will later connect the SyncIn and SyncOut lines. Click Apply. Interfacing The circuit diagram in Figure 2 shows how to connect your MTi-G-710 to the Velodyne Interface Box. Please note the following: For testing purposes it is possible to power the MTi-G-710 directly using the 12V supply available in the Interface Box. We do however recommend powering the MTi-G-710 separately while meeting the requirements mentioned in the MTi User Manual . This setup can be realized by using the CA-MP2-MTi cable . The wire map for this cable can be found in the MTi User Manual. Figure 2: Interfacing the MTi-G-710 with the Velodyne Interface Box. Setup 2: MTi-670/680 Configuration Start by configuring your MTi-6x0 to output the correct NMEA string and time data. The easiest way to do this is by using our GUI, MT Manager, which is part of the MT Software Suite . In MT Manager, open the Device Settings window ( ). In the Output Configuration tab, select "String report mode" and choose "GPGGA" and/or "GPRMC". Choose "400 Hz" from the drop-down menu. Click Apply. In the Device Settings tab, set the RS232 Protocol to "String Output" and the RS232 baud rate to 9600 bps. Click Apply. In the Synchronization Options tab, the "Clock Bias Estimation (In)" and the "1PPS Time-pulse" features should already be present in the list of configured settings, both on line In 2. Click Add, and select the Send Latest (In) function. Choose Line "In 2". Leave the other fields as is. This will configure the MTi to transmit its most recent data sample when triggered by the 1PPS signal on the SyncIn2 line. Click Apply. Interfacing The circuit diagram in Figure 3 shows how to connect your MTi-6x0 to the Velodyne Interface Box. Please note the following: For testing purposes it is possible to power the MTi-6x0 directly using the 12V supply available in the Interface Box. We do however recommend powering the MTi-6x0 separately while meeting the requirements mentioned in the MTi 600-series Hardware Integration Manual . As mentioned in the MTi 600-series Hardware Integration Manual, the RS232 CTS line of the MTi-6x0 needs to be tied to a logical high (3-25V). Otherwise the MTi will not transmit data over the RS232 interface. This setup can be realized by using the MTi-6x0 Development Board. In that case the 1 PPS signal from the GNSS receiver daughter card is already connected to SyncIn2. Figure 3: Interfacing the MTi-670/680 with the Velodyne Interface Box. Setup 3: MTi-670G/680G In contrast to the MTi-G-710, the MTi-6x0G does not yet offer a “true” 1 PPS output that comes straight from the internal GNSS receiver. Instead, by using the Interval Transition Measurement synchronization feature, the MTi-6x0G can be configured to generate its own 1 PPS signal that is synchronized with the 1 PPS signal of the internal receiver. This pulse will be synchronized with the internal GNSS 1 PPS pulse in terms of frequency, but not in terms of phase. This means that the 1 PPS output of the MTi-6x0G does not appear at the exact start of each UTC second. The timing of the pulse depends on the moment you power up the MTi. The MTi-6x0G does provide sub-second data in its NMEA messages, however some lidar brands do not copy the full UTC time information from the $GPGGA or $GPRMC packets: They often assume that the 1 PPS signal and its corresponding data packet coincide with the start of a UTC second, and therefore the sub-seconds field is assumed to be zero. This can cause a data timing error of up to 1 second. Configuration Start by configuring your MTi-6x0G to output the correct NMEA string and time data. The easiest way to do this is by using our GUI, MT Manager, which is part of the MT Software Suite . In MT Manager, open the Device Settings window ( ). In the Output Configuration tab, select "String report mode" and choose "GPGGA" and/or "GPRMC". Choose "400 Hz" from the drop-down menu. Click Apply. In the Device Settings tab, set the RS232 port baud rate to 9600 bps and the Protocol to String Output. Click Apply. In the Synchronization Options tab, the "Clock Bias Estimation" and "1PPS Time-pulse" features should already be present in the list of configured settings. Click Add, and select the Interval Transition Measurement function. Set Skip Factor to 399. Leave the other fields as is. This will create a 1 PPS signal on the SyncOut line of the MTi. Click Add, and select the Send Latest (In) function. Leave the other fields as is. This will configure the MTi to transmit its most recent data sample when triggered on the SyncIn line. We will later connect the SyncIn and SyncOut lines. Click Apply. Interfacing The circuit diagram in Figure 4 shows how to connect your MTi-6x0G to the Velodyne Interface Box. Please note the following: For testing purposes it is possible to power the MTi-6x0G directly using the 12V supply available in the Interface Box. We do however recommend powering the MTi-6x0G separately while meeting the requirements mentioned in the MTi 600-series Hardware Integration Manual . As mentioned in the MTi 600-series Hardware Integration Manual, the RS232 CTS line of the MTi-6x0G needs to be tied to a logical high (3-25V). Otherwise the MTi will not transmit data over the RS232 interface. This setup can be realized by using the CA-MP-MTI-12 cable . The wire map for this cable can be found in the MTi 600-series Development Kit User Manual . Figure 4: Interfacing the MTi-6x0G with the Velodyne Interface Box. Troubleshooting How can I check whether the 1 PPS signal and NMEA string messages are received properly? You can use the Ethernet connection to open the Velodyne User Interface (see below screenshot). The User Interface will show a real-time display of the GPS Position and PPS status. Why does my MTi-G-710 not output $GPRMC data? The $GPRMC message is only supported by firmware versions 1.10.0 and up. Check the firmware version of your device using MT Manager and if necessary, update to the latest firmware by using our Firmware Updater . The MTi-670 firmware has always supported the $GPRMC message. Can I configure the MTi to output other data next to the $GPRMC and/or $GPGGA strings? The MTi can be configured to also output other (NMEA) string outputs when triggered by the 1 PPS signal, as long as the 9600 bps baud rate allows for it. Additionally, the MTi 600-series allows for outputting data over the UART (IP51 modules only) and CAN interfaces as well, in parallel with the RS232 interface. Both the UART and RS232 interface will then only report data when triggered by the 1 PPS pulse. The CAN interface does not support the SendLatest functionality and therefore it will simply transmit its data at the configured data rate.insxsensinertial sensorslidarimuvelodynemti-100gnssmti-600 serieshttps://community.element14.com/products/manufacturers/xsens/b/blog/posts/the-new-mti-680-rtk-position-accuracy-in-a-small-form-factorMon, 06 Dec 2021 16:11:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:17696fc8-3aeb-4e6c-a4ad-ca70de2043e4xsenssupportXsens adds a new small form factor to its RTK GNSS/INS module, the new MTi-680 RTK GNSS/INS . This addition to the MTi 600-series brings cm-level RTK technology to the low-cost MTi 600-series module form-factor. We are pleased to announce a new product in our MTi 600-series, expanding the choices of inertial sensor modules . The MTi-680 supports up to centimetre position data from an external RTK GNSS receiver. As part of the MTi 600 series, this module is lightweight, rugged and cost-effective. You can seamlessly integrate the MTi-680 into your application with the header down, mount it directly to a PCB, or as a standalone, using a flat cable for communication. It is also very flexible, with native CAN support. This new product allows for even smaller, lighter and custom designs while enabling accurate cm-level orientation and position data at high speed at an affordable price point. The MTi-680 is great fit for applications that require data to support navigation functions, such as outdoor robotics and autonomous vehicles. These applications can be found in agriculture, last-mile deliveries, autonomous driving and driver assistance systems (ADAS), as well as outdoor construction and mining sites. In addition, interesting markets for the MTi-680 are mapping and recording or stabilization applications. These include, for example, automotive testing, LIDAR, Sonars and USBL, gimbal/camera/platform stabilization or pedestrian navigation. Housed in an IP51-rated plastic enclosure with dimensions of 28 mm x 31.5 mm x 13 mm, the MTi-680 is high vibration and shock-resistant. The module features a standard CAN and RS232 interfaces and an output rate of up to 400 Hz. The MTi-680 offers roll/pitch measurement accuracy of 0.2 deg RMS and heading accuracy of 0.5 deg RMS. All modules in the MTi 600-series offer high-quality features: Accurate factory calibration from MTi. High immunity to magnetic interference Adaptive firmware operation to optimize performance in different types of applications Out-of-the-box operation with Xsens' popular MTi development (DK) or starter kits (SK) Visit the MTi-680 RTK GNSS/INS product page for more information. The MTi-680 RTK GNSS/INS is part of the MTi 600-series. Find out more about it below: Go to the MTi 600-seriesinsxsensinertial sensorsrtkimugnss rtk dead reckoning solutionmti-600 serieshttps://community.element14.com/products/manufacturers/xsens/b/blog/posts/mti-100-series-imu-helps-racelogic-to-achieve-breakthrough-with-new-vips-system-1045026415Mon, 06 Dec 2021 15:45:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:1316b7de-f5ef-4028-8cac-8f3f456a4f47xsenssupportMTi 100-series IMU helps Racelogic to achieve breakthrough with new VIPS system for tracking cars’ motion accurately with no satellite signals. The development and validation of new road vehicles and equipment calls for the precise testing of dynamic behavior including velocity, acceleration, deceleration and attitude. Tests of the safety and performance of new models are generally carried out on dedicated outdoor test tracks. Here, parameters such as acceleration, cornering speed and braking distances can be measured accurately under varied driving conditions. Nearly all the world’s top manufacturers of cars, and of components such as tires, include data acquisition systems supplied by UK technology pioneer Racelogic in their array of vehicle testing equipment. Racelogic’s VBOX is the automotive industry’s preferred data acquisition system for vehicle testing because of its outstanding performance: it logs at a frequency of 100 times a second the exact position of a test vehicle on the road to an accuracy of ±2cm. It achieves this remarkable accuracy by combining signals from multiple GNSS constellations, such as GPS and GLONASS, with inertial measurements and wheel speed data from the vehicle itself. The inertial data – measurements in three dimensions of acceleration and of rate-of-turn – are obtained from the high-accuracy Xsens IMU ( inertial measurement unit ). Racelogic, a long-time customer of Xsens, relies on the MTi series of IMUs because they offer the very high accuracy that Racelogic requires, while being small, light, and easy to integrate into the sensor/receiver unit mounted on the roof of the vehicle under test. Using sophisticated algorithms developed by Racelogic, the VBOX Data Logger base unit performs post-processing on the measurements recorded during a test run. The outputs from a VBOX IMU enable the VBOX data logger to apply error correction to the raw satellite positioning signals: it is the Racelogic software backed by the MTi series IMU’s measurements which allow the system to achieve ±2cm position accuracy and help it to maintain the accuracy in GPS denied environments. When a car manufacturer announces that a new model goes from 0mph to 60mph more quickly than its closest competitor, it relies on measurements from the VBOX to validate its claim. In the same way, when it tests the limits of a car’s high-speed cornering, and the speed at which its tires lose grip, it is the VBOX which detects the first few centimeters of deviation as the rear wheels begin to slide. This is why the VBOX system’s accuracy is so highly prized by the automotive industry. Positioning with no satellite signal The primary use case for the VBOX system is to support vehicle testing on outdoor test tracks. But some tests that car manufacturers want to perform are either difficult or impossible on an open, outdoor test track. Examples include: Testing dynamic behavior when driving through a tunnel, or in other zones which have limited reception of satellite signals, such as urban canyons and in dense forest. Testing the operation of park assist and other driver assistance systems in a multi-story car park or indoor test chamber Tire testing on an ice rink To meet this demand, Racelogic has developed a new indoor positioning system which enables the testing and validation of ADAS sensors, autonomous vehicles and vehicle dynamics indoors. Called the VBOX Indoor Positioning System (VIPS), the equipment achieves the same positional accuracy – ±2cm – as the standard VBOX system, without any satellite signal input. This accuracy is unprecedented in the high-precision world of automotive testing: even the best competing indoor positioning products on the market are only able to achieve accuracy of ±5cm. As well as supporting any indoor test use case, the VIPS product also enables Racelogic to provide an integrated indoor/outdoor system for VBOX users. It is the world’s first indoor positioning system to provide a seamless transition between GPS-based and indoor position measurement systems with no loss of accuracy. IMU data ensure high accuracy The technology which enables Racelogic to achieve such high positional accuracy when out of range of satellite positioning signals is similar in its operation to the outdoor system. But the VIPS system relies on an array of six or more Ultra-Wideband (UWB) static radio beacons mounted at intervals of around 50m to provide the raw position information. A ‘Rover’ sensor unit mounted on the roof of the vehicle under test receives the UWB signals from multiple beacons simultaneously. The Rover unit also contains an MTi-100 series IMU module from Xsens: this provides extremely accurate, synchronized acceleration and rate-of-turn measurements at an output data rate of up to 2kHz. And as with satellite positioning signals, the VBOX Indoor Positioning System software uses the MTi 100-series module’s acceleration and rate-of-turn data to perform error correction on the UWB signals. The combination of UWB data, IMU data and Racelogic’s unique software produces the VIPS product’s ±2cm accuracy on which automotive manufacturers rely. Flexible and scalable system The UWB beacons used in the VIPS product may be battery-powered to allow for positioning on any surface. An installation can include up to 250 beacons, making the system scalable for coverage of a wide surface area. This scalability is particularly useful in applications such as underground mines or construction sites. The VIPS equipment can measure vehicle velocity up to 270km/h. The accuracy of velocity measurements is ±0.1km/h. Julian Thomas, Founder and Managing Director of Racelogic, said: ‘The top priority for Racelogic in developing the VIPS solution was to achieve the industry’s best guaranteed accuracy indoors, in any terrain and any driving conditions – customers have relied on Racelogic for superior accuracy ever since the launch of the VBOX data acquisition system in 2001. ‘That’s why we chose the MTi 100-series IMU from Xsens. Our evaluation showed it provided the most accurate inertial sensor data of any module in its class, enabling our VIPS solution to maintain guaranteed accuracy across the entire measured area.’ For more information about the Racelogic VIPS system, go to the VBOX Indoor Positioning website.insxsensinertial sensorsimumti-100https://community.element14.com/products/manufacturers/xsens/m/managed-videos/144271Thu, 11 Nov 2021 16:19:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:2f5b41a1-f474-447e-958a-fa182a7b6f2axsenssupportOur latest sensor fusion experiments at Carleton using LiDAR, Vision, IMU positioning, mapping and tracking technology.