This project aims to personalize Advanced Driving-assistance Systems (ADAS) for autonomous vehicles with the self-driving cars simulator CARLA. The two main focus are on personalizing lane changing and personalizing Adaptive Cruise Control (ACC) that includes vehicle following and lane following.

Hardware-In-Loop based simulation with Torque controlled Steering motor and CARLA

Learning Phase

The Learning Phase uses Gaussian Mixture Model (GMM) for clustering the user preferences to into known presets which the ADAS can understand.

The vehicle is initialized with autopilot mode on. To switch between manual control and autopilot mode, press p.

To start or end the learning process, press l in manual control mode. Noted that starting and ending learning process would only collect driver's behavior data. One has to press t to let the model learn from the data and be stored locally.

After learning, one could regenerate the scene by pressing Backspace and turn autopilot mode on to see the performance of the vehicle.

It is advisable to personalize lane following in front in scene 0, to clone vehicle following behavior in scene 1, and to teach the model lane changing in scene 2.

Personalization

Some sets of data of 3 different drivers are stored in data/Driver_Data.

Lane Following

personalized parameter: target_speed

method: GMM

Driver 1 Set 1 Target Speed Histogram Plot & V-t Plot

All sets of 3 drivers' data

Vehicle Following

personalized parameter: Time Headway (THW)

method: GMM

Driver 1 Set 1 THW, TTCi
All sets of 3 drivers' data

Lane Changing

personalized parameter: Lateral Time, Longitudinal Velocity

method: GMM + COS Trajectory

3 drivers' trained models perform in standard case [10m/s, -3.5m, 15m, -12m]

A generic Forward and Inverse Kinematics Solver for Robotic arms with controller connecting to AMBF (Asynchronous Multi-Body Framework) simulator.

AMBF is a ground breaking work by Adnan Munawar, a Multi-body simulator where all bodies (even every link of the body) is an independent entity, a radically different approach for simulating robots. This is one of the few simulators which natively support parallel mechanisms. Check the video below introducing AMBF.

Our work had been to develop a generic FK-IK solver for the simulator. It is developed as a ROS package which can be run with AMBF.

Architecture of Controller

The Controller package reads the robot file(AMBF YAML) which AMBF uses and then loads an appropriate solver from the solvers available.

Solver package is developed in for pluggable (addon) method of extending the supporting robots. A new solver (may be for a different kind of kinematic chain, which cannot be solved by existing solvers) can be implemented just by creating a subclass of "BaseSolver"  class and implementing all the abstact functions. Once this file is placed in the appropriate folder, the solver is available right away, also without interfering the existing system.

Commands and communication to the controller is done using ROS-topics. Below is an example code written to control a robot in AMBF using ROS. (given 3 waypoints, move the robot in linear steps).

Testing of solvers

For a custom solver created for serial manipulators, this is how it was tested by solving for Forward kinematics, and giving the same input to inverse, and vice versa, to expect the robot to be in the same position.

Github Repo

prajankya/ambf_controller

Controller Node for AMBF. Contribute to prajankya/ambf_controller development by creating an account on GitHub.

prajankyaGitHub

Finding memory bugs like memory-leaks, memory corruptions and memory access violations can be difficult if you don't have the right tool to help you narrow down the scope and provide clues. This is what Valgrind does good for code written in C/C++, it can save you hours of frustration.

How to run

You can install valgrind using your package manager (for Ubuntu sudo apt install valgrind). Your program can be complied with any compiler, but try to keep it on no optimizations to get most of valgrind)

For your program named hello, run

valgrind ./hello

Understanding Valgrind

Valgrind is a debugging tool which is available on Linux, it's an opensource project and is free to use. Valgrind helps with memory leak detection, threading bugs and can help optimize code using its profiling support. Valgrind is designed to work non-intrusively as possible with existing executable, this means you don't need to re-link or re-build a binary in order to use Valgrind features. Simply run Valgrind passing it operational parameters and the executable to be tested along with any parameters the executable might accept.

The executable is run on a synthetic CPU provided by the Valgrind core, every single instruction executed is simulated, which will cause the executable to run much slower. Lets look at Valgrind by testing the Linux date command from the shell.

==20943== Memcheck, a memory error detector
==20943== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==20943== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==20943== Command: ./hello
==20943== 
==================================================================================================
Hello World!
==================================================================================================
==20943== 
==20943== HEAP SUMMARY:
==20943==     in use at exit: 72,768 bytes in 3 blocks
==20943==   total heap usage: 6,247 allocs, 6,244 frees, 1,071,757 bytes allocated
==20943== 
==20943== 32 bytes in 1 blocks are still reachable in loss record 1 of 3
==20943==    at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==20943==    by 0x6340E77: CRYPTO_malloc (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==20943==    by 0x63F841E: sk_new (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==20943==    by 0x60B94F9: ??? (in /lib/x86_64-linux-gnu/libssl.so.1.0.0)
==20943==    by 0x60BB5F8: SSL_COMP_get_compression_methods (in /lib/x86_64-linux-gnu/libssl.so.1.0.0)
==20943==    by 0x60C0D82: SSL_library_init (in /lib/x86_64-linux-gnu/libssl.so.1.0.0)
==20943==    by 0x52BA77: boost::asio::ssl::detail::openssl_init_base::do_init::do_init() (openssl_init.ipp:39)
==20943==    by 0x52BE42: boost::asio::ssl::detail::openssl_init_base::instance() (openssl_init.ipp:131)
==20943==    by 0x52C955: boost::asio::ssl::detail::openssl_init<true>::openssl_init() (openssl_init.hpp:60)
==20943==    by 0x562DB2B: __static_initialization_and_destruction_0(int, int) (openssl_init.hpp:90)
==20943==    by 0x562E538: _GLOBAL__sub_I_http_client.cpp (http_client.cpp:426)
==20943==    by 0x40106C9: call_init.part.0 (dl-init.c:72)
==20943== 
==20943== 32 bytes in 1 blocks are still reachable in loss record 2 of 3
==20943==    at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==20943==    by 0x6340E77: CRYPTO_malloc (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==20943==    by 0x63F843C: sk_new (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==20943==    by 0x60B94F9: ??? (in /lib/x86_64-linux-gnu/libssl.so.1.0.0)
==20943==    by 0x60BB5F8: SSL_COMP_get_compression_methods (in /lib/x86_64-linux-gnu/libssl.so.1.0.0)
==20943==    by 0x60C0D82: SSL_library_init (in /lib/x86_64-linux-gnu/libssl.so.1.0.0)
==20943==    by 0x52BA77: boost::asio::ssl::detail::openssl_init_base::do_init::do_init() (openssl_init.ipp:39)
==20943==    by 0x52BE42: boost::asio::ssl::detail::openssl_init_base::instance() (openssl_init.ipp:131)
==20943==    by 0x52C955: boost::asio::ssl::detail::openssl_init<true>::openssl_init() (openssl_init.hpp:60)
==20943==    by 0x562DB2B: __static_initialization_and_destruction_0(int, int) (openssl_init.hpp:90)
==20943==    by 0x562E538: _GLOBAL__sub_I_http_client.cpp (http_client.cpp:426)
==20943==    by 0x40106C9: call_init.part.0 (dl-init.c:72)
==20943== 
==20943== 72,704 bytes in 1 blocks are still reachable in loss record 3 of 3
==20943==    at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==20943==    by 0x67ACEFF: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==20943==    by 0x40106C9: call_init.part.0 (dl-init.c:72)
==20943==    by 0x40107DA: call_init (dl-init.c:30)
==20943==    by 0x40107DA: _dl_init (dl-init.c:120)
==20943==    by 0x4000C69: ??? (in /lib/x86_64-linux-gnu/ld-2.23.so)
==20943== 
==20943== LEAK SUMMARY:
==20943==    definitely lost: 0 bytes in 0 blocks
==20943==    indirectly lost: 0 bytes in 0 blocks
==20943==      possibly lost: 0 bytes in 0 blocks
==20943==    still reachable: 72,768 bytes in 3 blocks
==20943==         suppressed: 0 bytes in 0 blocks
==20943== 
==20943== For counts of detected and suppressed errors, rerun with: -v
==20943== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

As you can see, there are no errors reported by Valgrind (shown in the last line). There were 6247 allocations and 6244 frees on the heap, with 3 memory leaks. Also reported is the total bytes allocated over the run-period. This lets us peek inside an process to see how memory is getting utilized.

The general Report format will be:

==99999== some valgrind message:

Where 99999 is the process id, above 20943 is the process id that was monitored.

If you can, when debugging, make sure to debug code that is not optimized. Otherwise you will encounter odds results. Also build with -Wall to eliminate all possible compile time warnings as Valgrind does not report these.

When fixing errors reported by Valgrind, fix them in the order reported, as subsequent errors may be caused by earlier errors. If you want to know how many times an error has occurred, use the "-v" option. This option will also turn on verbose reporting. The link below explains extra warnings you might see as a result of using this option.

Logging to file

Since Valgrind takes everything as an input parameter, the following Valgrind invocations will not work as you expect(No Piping possible for output). The file operation and any other program passed to Valgrind will get instrumented which is not what you want.

valgrind some_exe > valtest.log
valgrind some_exe | tee valtest.log

The correct way to log is to use the option, "--log-file=filename"

Threading

Valgrind fully supports threaded programs. The executable code will use the native thread library, however Valgrind will serialize the calls and restrict all thread operations to a single CPU core. Valgrind will only run one thread at a time, this is done to avoid implementation problems with Valgrind. Thread scheduling is still handled by the OS. Multi-threaded executable will run much slower, also on average Valgrind instrumentation results in a 10 to 50 times slow down of execution for a single threaded program.

Detecting memory leaks with Valgrind

Memcheck is the memory error detector tool in Valgrind, to use it, you "may" specify the option "--tool=memcheck", but you don't need to since Memcheck is the default tool of Valgrind. To get detailed memory check, you can run as:

valgrind --leak-check=full --show-leak-kinds=all ./hello

Lets try to debug and study a test program. The sample program provided below allocates memory and fails to delete it. The simple leak-test app takes a single parameter which is the size in bytes of the memory to be allocated.

#include <iostream>
#include <cstring>
#include <stdlib.h>

using namespace std;

int main(int argc, char* argv[])
{
   int size = 10;
   if( argc == 2 ) size = atoi(argv[1]);
   int* p = new int[size];
   memset( p, 0, 10 );
   return 0;
}

Create a test folder and save this file as main.cpp

Building with GNU GCC

The program can be built with any compiler, here we are using GNU g++, no special steps are required.

mkdir build
cd build
g++ ../main.cpp -o testapp

valgrind --leak-check=yes ./testapp 1000

Note: Valgrind needs the system debug symbols installed in order for it to work correctly. If you see the error below, you will need to install the debug symbols for libc on Linux. Just read the Valgrind message carefully for instructions on must be done.

==8838== Memcheck, a memory error detector
==8838== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==8838== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==8838== Command: ./testapp
==8838==

valgrind:  Fatal error at startup: a function redirection
valgrind:  which is mandatory for this platform-tool combination
valgrind:  cannot be set up.  Details of the redirection are:
valgrind: 
valgrind:  A must-be-redirected function
valgrind:  whose name matches the pattern:      strlen
valgrind:  in an object with soname matching:   ld-linux-x86-64.so.2
valgrind:  was not found whilst processing
valgrind:  symbols from the object with soname: ld-linux-x86-64.so.2
valgrind: 
valgrind:  Possible fixes: (1, short term): install glibc's debuginfo
valgrind:  package on this machine.  (2, longer term): ask the packagers
valgrind:  for your Linux distribution to please in future ship a non-
valgrind:  stripped ld.so (or whatever the dynamic linker .so is called)
valgrind:  that exports the above-named function using the standard
valgrind:  calling conventions for this platform.  The package you need
valgrind:  to install for fix (1) is called
valgrind: 
valgrind:    On Debian, Ubuntu:                 libc6-dbg
valgrind:    On SuSE, openSuSE, Fedora, RHEL:   glibc-debuginfo
valgrind: 
valgrind:  Cannot continue -- exiting now.  Sorry.

On Ubuntu, to install libc debug symbols, type:

sudo apt-get install libc6-dbg

If Valgrind runs correctly you will see something similar to the following output.

==29618== Memcheck, a memory error detector
==29618== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==29618== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==29618== Command: ./testapp 1000
==29618== 
==29618== 
==29618== HEAP SUMMARY:
==29618==     in use at exit: 76,704 bytes in 2 blocks
==29618==   total heap usage: 2 allocs, 0 frees, 76,704 bytes allocated
==29618== 
==29618== 4,000 bytes in 1 blocks are definitely lost in loss record 1 of 2
==29618==    at 0x4C2E80F: operator new[](unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==29618==    by 0x4007F0: main (in /tmp/test/build/testapp)
==29618== 
==29618== LEAK SUMMARY:
==29618==    definitely lost: 4,000 bytes in 1 blocks
==29618==    indirectly lost: 0 bytes in 0 blocks
==29618==      possibly lost: 0 bytes in 0 blocks
==29618==    still reachable: 72,704 bytes in 1 blocks
==29618==         suppressed: 0 bytes in 0 blocks
==29618== Reachable blocks (those to which a pointer was found) are not shown.
==29618== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==29618== 
==29618== For counts of detected and suppressed errors, rerun with: -v
==29618== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

This output clearly states that there is a memory-leak. There are many kinds of memory-leaks; two important ones are:

• "definitely lost": you have a memory-leak.
• "probably lost": you may have a memory-leak, unless you are doing something funny with moving heap pointers around.

Let's add the missing delete.

#include <iostream>
#include <cstring>
#include <stdlib.h>

using namespace std;

int main(int argc, char* argv[])
{
   int size = 10;
   if( argc == 2 ) size = atoi(argv[1]);
   int* p = new int[size];
   memset( p, 0, 10 );
   delete[] p;
   return 0;
}

Build and run Valgrind one more time. This time there is no error/ memory leak.

==30609== Memcheck, a memory error detector
==30609== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==30609== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==30609== Command: ./testapp 1000
==30609== 
==30609== 
==30609== HEAP SUMMARY:
==30609==     in use at exit: 72,704 bytes in 1 blocks
==30609==   total heap usage: 2 allocs, 1 frees, 76,704 bytes allocated
==30609== 
==30609== LEAK SUMMARY:
==30609==    definitely lost: 0 bytes in 0 blocks
==30609==    indirectly lost: 0 bytes in 0 blocks
==30609==      possibly lost: 0 bytes in 0 blocks
==30609==    still reachable: 72,704 bytes in 1 blocks
==30609==         suppressed: 0 bytes in 0 blocks
==30609== Reachable blocks (those to which a pointer was found) are not shown.
==30609== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==30609== 
==30609== For counts of detected and suppressed errors, rerun with: -v
==30609== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Valgrind tells us 2 allocation took place and 1 free of 76,704 bytes and no memory leaks on exit.

NOTE: if you want to get more detailed memory-leak output, use Valgrind like this:

valgrind --leak-check=full

You can also add the "-v" verbose option.

Few other types of issues which can be detected are :

• Uninitialized variable detection (These errors can be difficult to track down in larger code, so to get more information to find the root cause use, "--track-origin=yes".  This option will cause slow down in the execution speed, so use it when you need to)
• Invalid memory access
• Buffer overrun detection
• Source and destination memory overlap
• System calls with inadequate read/write permission
• Mismatch memory allocation and deletion
• Double delete

Taken from the Valgrind site:

In C++ it's important to deallocate memory in a way compatible with how it was allocated. The deal is:

• If allocated with malloc, calloc, realloc, valloc or memalign, you must deallocate with free.
• If allocated with new, you must deallocate with delete.
• If allocated with new[], you must deallocate with delete[].

Last words

Even if you are not having to track down a memory bug, as a professional you should be in the practice of executing all your code through Valgrind. You've seen how easy it is to use Valgrind, so turn it into a new habit.

Tools and Setup

colour-valgrind (python wrapper)

Heaptrack - A Heap Memory Profiler for Linux

Hello everyone, with a tingly feeling in my belly, I’m happy to announce heaptrack, a heap memory profiler for Linux. Over the last couple of months I’ve worked on this new tool in my free time. What started as a “what if” experiment quickly became such a promising tool that I couldn’t stop working …

Milian WolffMilian Wolff

This tool helps in calculating Transformation matrices often required when working on Serial Robots for kinematics/control/dynamics. It uses the most common method of representing joints and links, i.e. DH parameters. Please follow along the steps to use it for your application.

Step 1: Define Z Axis

Choose z_i along the axis of motion of the i+1^th link.

Go along all the Joints in the Robot and define Z axis for each joint as shown above.

Step 2: Define X Axis

Choose x_i such that it is the shortest vector between z_i-1 and z_i.

Step 3: Get D-H Parameters

Now enter the 4 DH parameters into the tool shown below.

Step 4: Get Transformation matrix

Use this Transformation matrix to calculate Inverse and Forward Kinematics.

T = [[l.name]]  * 

T = (I)

More Info about Demo Robot

The Example DH parameters are for ABB IRB120

The Robot and the images related to it are courtesy of abb.com website and are used here as reference only.
Close

A Web portal for Grievance reporting, Request and Custom N.M.S.

Very basic information:

Platform Architecture

Bare Metal: Intel Xeon E3 based rack mount server
OS: Ubuntu 16.04 Server edition
Server: Node.js
Database: MongoDB
Service manager: Node Upstarter
Live Updating clientside: Using socket.io
Node router: express
Clientside Renderer: EJS
Clientside runtime: Angular.js

Network Monitoring System part:
Polling: SNMP data polling every 5 seconds
Interrupt: Using SNMP Trap
Device status: Pinging device every 5 seconds(ICMP Server)
80: For HTTP site(Apache Proxy)
161, 162: SNMP and SNMP Trap
3000: For Node.js HTTP server(Forwarded by apache to port 80)
Also used for Socket.io Websockets

Frontend Site

The main page features The Infocell team, the Noticeboard and some other prime links.
The sub pages are about filling form for any complaints or Audio-Video requests which is handled by the Infocell team.

Backend website

The backend opens in hidden link and ask for Login, after successful the landing page in the Dashboard, It shows all the current Complaints and AV Requests. It also show the new updates and features added to the suite.

From the top bar we can change password navigate and search. On the sidebar are Event calendar Noticeboard and Many other features, most of which visible only to administrators and not for other users.

In Complaints and requests page there are two parts, current pending and already done or resolved.
Any issue marked done by any user carries the information forward with the time at which it was done. These pages are searchable throughout, with every information from date to name is searchable. All the visible(even the searched data) is downloadable as CSV.

Admins can delete complaints edit to change the group of a complaint to assign it to the desired users. also Admins only can edit any request to change the date and time of any event, as in Registration form in frontend, it is possible to register an event only 24 hrs before. so this place admins can change the date for any exceptions.

Admin features

Manage users and groups feature is only for admins. In Manage users the admin can create or edit new users, give them hirarchy priorities, assign work(by selecting the group that user belongs to) define designation as to be shown on the frontend website in Infocell Team, and also can make a user inactive for not able to login, but still have all the complaints and requests completed by him in the database.

User features

The 'My Profile' add feature for display name and Profile picture change facility, which is to be shown in frontpage in 'Infocell Team'. Also In Noticeboard page, new notices can be added, edited or deleted. These notices are visible on the frontpage as well.

NMS (Network Management System)

The Dashboard sidebar has got "Live Map" which is in fact the Network Monitoring System.
The Map is made by VIZ.js and uses various technologies to make the map. All the devices visible are shown with UP/DOWN configuration by Pinging each device every 5 seconds. The Line UP/DOWN status at the top are using SNMP Trap to show when the line goes down. The Left side UTM statistics as taken using SNMP as well as ghost browser login in PhantomJS

prajankya/Infocell

BVBCET Infocell Website. Contribute to prajankya/Infocell development by creating an account on GitHub.

prajankyaGitHub

A 4-foot Humanoid robotics platform (Ajit v1.0 and v2.0) developed under KLE Technological University.

Led and mentored the project as Research Assistant under the Head of Department, Robotics- Arun Giriyapur. Walking Gaits developed with the help of Matlab, Simulink and SpeedGoat. Integration to ROS from Matlab, Dynamixel Motors and Intel Realsense D435.

Initial Gaits trails

Student (Akshay Dhonthi) working and testing gaits.

A delta robot designed for sorting parts on conveyor belt, using Beckhoff Automation PLCs and Computer vision using webcam.

Handheld robot to measure foliage and/or count trees in horticulture fields using a 2D Lidar, IMU, and odometry(wheel or visual odometry for using untethered from ground). It can be mounted on any agricultural machinery or be mounted on a hand-cart(as shown below).

As shown in the Application Interface below, RViz is used for displaying the lidar scan data, mapping data, as well as the detected tree trunks in bottom left corner.

OpenCV is used to detect tree trunks by using SimpleBlobDetector used to Extracted blobs by circularity and areas.

prajankya/AgriMapper

A Precision Horticulture 2D Vegetation Mapping Robot - prajankya/AgriMapper

prajankyaGitHub

Report Paper
https://www.ijert.org/research/feasibility-of-using-cost-effective-lidar-for-precision-horticulture-IJERTV7IS010168.pdf

A mobile robot developed for demonstrating various applications such as surveying, 2D mapping, indoor navigation and SLAM(Simultaneous Localization And Mapping).

The robot is developed for indoor use, a holonomous drive with 4 omni-wheels. It uses Lidar as the primary sensor and explore unknown terrain to create a map (blue print) of the surveying site. We used ROS(Robot Operating System) for the same, configured /programmed it with Frontier exploration, AMCL for localization and building Octo-maps / 2D pgm maps as an output.

What was the inspiration

Mapping, localization, and path-planning are some of the fundamental requirements of any mobile robot. Most of the mobile robots which work outdoors use localization techniques like GPS or radar. Similarly for indoor robots technologies like beaconing is used, but the problems with those is that we have to have the environment setup with beacons, leading to immobile setup. This project hence aimed at mobile platform, which can work in unknown terrains. Also our study focused on holonomous drive as it gives us more degrees of freedom to move in smaller areas indoor.

Below you can see few images of robot (and few early iterations).

Developed QT based plugin for RQT for controlling the Robot

2D Lidar used in the project

Working of 4 Wheeled Omni

Few of the working videos of first prototype

An Academic report on the same can be found at :

prajankya/Lidar-Robot

Autonomous L.O.A.M. Omni Wheeled Robot. Contribute to prajankya/Lidar-Robot development by creating an account on GitHub.

prajankyaGitHub

Inspired by the display at Changi Airport - Singapore, This was a team effort for developing a similar display with feedback controlled normal DC motors with controllers in Microcontrollers (3 motors per MCU), which in turn are controlled over RS485 and Modbus by a central computer with a Web Interface to setup and control the animation.

Configuration software

First it starts with moving the balls to required position(can use the depth control on right side of the screen to move balls which are behind). A timeline is  shown on the bottom. Key-frames can be added to the timeline which leads to animating the whole artwork. Finally there is a button for going live or Generating code to be deployed to a controller on site, to run the animation in loop.