Category: Post categories

Automatic Wheels and Camera Calibration for Monocular and Differential Mobile Robots

Posted on | by Konstantin Chaika
  • Automatic Wheels and Camera Calibration for Monocular and Differential Mobile Robots
  • Konstantin Chaika, Anton Filatov, Artyom Filatov, Kirill Krinkin
  • Applied Sciences 11, no. 13: 5806.

Automatic Wheels and Camera Calibration for Monocular and Differential Mobile Robots

After assembling the robot, components such as the camera and wheels need to be calibrated. This requires human participation and depends on human factors. We describe the approach to fully automatic calibration of a robot’s camera and wheels.

The camera calibration collects the necessary set of images by automatically moving the robot in front of the chess boards, and then moving it on the marked floor, assessing its trajectory curvature. As a result of the calibration, coefficient k is calculated for the wheels, and camera matrix K (which includes the focal length, the optical center, and the skew coefficient) and distortion coefficients D are calculated for the camera. 

Proposed approach has been tested on duckiebots in Alexander Popov’s International Innovation Institute for Artificial Intelligence, Cybersecurity and Communication, SPbETU “LETI”. This solution is comparable to manual calibrations and is capable of replacing a human for this task. 

Camera calibration process

The initial position of the robot is a part of the floor with chessboards in front, where the robot is located from the very beginning, on which its camera is directed and the floorsurface is marked with aruco markers on the other side of it.

There can be any number of chessboards, determined by the amount of free space around the robot. To a greater extent, the accuracy of calibration is affected by the frames with different positions of the boards, e.g., boards located at different distances from the robot and at different angles. The physical size and type of all the boards around the robot must be the same.

In fact, the camera calibration implies that the robot is rotating around its axis and taking pictures of all the viewable chessboards in turn. In this case, the ability to make several “passes” during the shooting process should be provided for, to control which of the boards the robot is currently observing and in which direction it should turn. As a result, the algorithm can be represented as a sequence of actions: “get a frame from the camera” and “turn” a little. The final algorithm comprises the following sequence of actions:

  1. Obtain frame from the camera;
  2. Find a chessboard on the camera frame;
  3. Save information about board corners found in the image;
  4. Determine the direction of rotation according to the schedule;
  5. Make a step;
  6. Either repeat the steps described above, or complete the data
    collection and proceed with the camera calibration using OpenCV.

 

Wheels calibration process

Floor markers should be oriented towards the chessboards and begin as close to the robot as possible. The distance between the markers depends on camera’s resolution, as well as its height and angle of inclination, but it must be such that at least three recognizable markers can simultaneously be in the frame. For ours experiments, the distance between the markers was set as 15 cm with a marker size of 6.5 cm. The algorithm does not take into account the relative position of the markers against each other; however, the orientation of all markers must be strictly the same.

Let us consider the first iteration of the automatic wheel calibration algorithm:

  1. The robot receives the orientation of the marker closest to it and remembers it.
  2. Next, the robot moves forward with thespeeds of the left and right wheels equal to
    ω1ω2 for some fixed time t. The speeds are calculated taking into account the calibration
    coefficient k, which for the first iteration is chosen to equal 1 – that is, it is assumed that
    the real wheel speeds are equal.
  3. The robot obtains the orientation of the marker closest to it again and calculates the
    difference in angles between them.
  4. The coefficient ki for this step is calculated.
  5. The robot moves back for the same time t.

In order to reduce the influence of the error in calculating ki, coefficient k is refined only by the value of (ki−1)/2 after each iteration. It is important to complete this step after the robot moves back, because it reduces the chance of the robot moving outside the area width. If, after the next step, the modulus of the difference between (ki−1)/2 and 1.0 becomes less than the pre-selected E, then at this iteration (ki−1)/2 is not taken into account. If after three successive iterations ki is not taken into account, the wheel calibration is considered to be completed.

Accuracy Evaluation

To compare camera calibration errors, the knowledge of how to calculate these errors is needed. Since the calibration mechanism is used by the OpenCV library, the error is also calculated by the method offered by this library.

As noted earlier, with respect to calibration factors, the approach used to calibrate the camera is not applicable. Therefore, the influence of the coefficient on the robot’s trajectory curvature is estimated. To do this, the robot was located at a certain fixed distance from a straight line, along which it was oriented and then moved in manual mode strictly directly to a distance of two meters from the start point along the axis, relative to which it was oriented. Then, the robot stopped and the distance between the initial distance to the line and the final one was calculated.

Two metrices were estimated – reprojection error and straight line deviation. First one shows the quality of camera calibration, and the second one represents the quality of wheels calibration. Two pictures below present result of 10 independent tests in comparison with manual calibration.

 

 

 

The tests found that the suggested solution, on average, shows that the results are not much worse, than the classical manual solution when calibrating the camera, as well as when calibrating the wheels with a well known calibrated camera. However, when calibrating both the wheels and the camera, the wheel calibration can be significantly affected by the camera calibration effect. As a result of testing, a clear relationship was found between the reprojection error and the straight line deviation.

Method Modifications

After the integration of this approach, it became necessary to automate the last step-moving the robot to the field. Due to the fact that after the calibration step completion the robot becomes fully prepared for launching autonomous driving algorithms on it, the automation of this step further reduces the time spent by the operator when calibrating the robot, since instead of moving the robot to the field manually, he can place the next robot at the starting position. In our case, the calibration field was located at the side of the road lane so that the floor markers used to calibrate the wheels are oriented perpendicular to the road lane.

Thus, the first stage of the robot automatic removal from the calibration zone is to return its orientation back to the same state, as it was at the moment when the wheel calibration started. This was carried out using exactly the same approach that was described earlier—depending on the orientation of the floor marker closest to the robot, the robot rotates step by step about its axis clockwise or counterclockwise until the value of the robot’s orientation angle is modulo less than some preselected value.

At this point, the robot is still on the wheel calibration field, but in this case, it is oriented towards the lane. Thus, the last step is to move the robot outside the border of the field with markers. To do this, it is enough to give the robot a command to move directly until it stops observing the markers, when the last marker is hidden from the camera view. This means that the robot has left the calibration zone, and the robot can be put into the lane following mode.

 

 

 

 

Future Work

During the robot’s operation, the wheels calibration may become irrelevant. It can be influenced by various factors: a change in the wheel diameter due to wear of the wheel coating, a slight change in the characteristics of motors due to the wear of the gearbox plastic, and a change in the robot’s weight distribution, e.g., laying the cables on the other side of the case after charging the robot, and so a slight calibration mismatch can occur. However, all these factors have a rather small impact, and the robot will still have a satisfactory calibration. There is no need to re-perform the calibration process, just a little refinement of the current one seems to be enough. To do this, a section of the road along which the robots will be guaranteed to pass regularly, was selected. 

Further, markers were placed in this lane according to the rules described earlier: the distance between the markers is 15 cm; the size of the marker is 6.5 cm. The markers are located in the center of the lane. The distance between the markers may be not completely accurate, but they should be oriented in the same direction and co-directed with the movement in the lane on which they are placed. 

The first marker in the direction of travel must have a predefined ID. It can be anything, the only limitation is that it must be unique for a current robot environment. Further, the following changes were made to the algorithm for the standard control of the robot: when the robot recognizes the first marker with a predetermined ID while driving right in the lane, it corrects its orientation relative to this marker and continues to move strictly straight ahead. Further, the algorithm is similar to the one described earlier—the robot recognizing the next marker can refine its wheel calibration coefficient, apply it, and change the orientation coaxially with the next marker.

 

Conclusions

As a result, a solution was developed that allows a fully automatic calibration of the camera and the Duckiebot’s wheels. The main feature is the autonomy of the process, which allows one person to run the calibration of an arbitrary number of robots in parallel and not be blocked during their calibration. In addition, the robot is able to improve its calibration as it operates in default mode.

Comparing the developed solution with the initial one resulted in finding a slight deterioration in accuracy, which is primarily associated with the accuracy of the camera calibration; however, the result obtained is sufficient for the robot’s initial calibration and is comparable to manual calibration. 

Did you find this interesting?

Read more Duckietown based papers here.

Embedded out-of-distribution detection on an autonomous robot platform

Posted on | by michaelj004

Embedded out-of-distribution detection on an autonomous robot platform

Introduction

Machine learning is becoming more and more common in cyber-physical systems; many of these systems are safety critical, e.g. autonomous vehicles, UAVs, and surgical robots.  However, machine learning systems can only provide accurate outputs when their input data is similar to their training data.  For example, if an object detector in an autonomous vehicle is trained on images containing various classes of objects, but no ducks, what will it do when it encounters a duck during runtime?  One method for dealing with this challenge is to detect inputs that lie outside the training distribution of data: out-of-distribution (OOD) detection.  Many OOD detector architectures have been explored, however the cyber-physical domain adds additional challenges: hard runtime requirements and resource constrained systems.  In this paper, we implement a real-time OOD detector on the Duckietown framework and use it to demonstrate the challenges as well as the importance of OOD detection in cyber-physical systems.

Out-of-Distribution Detection

Machine learning systems perform best when their test data is similar to their training data.  In some applications unreliable results from a machine learning algorithm may be a mere nuisance, but in other scenarios they can be safety critical.  OOD detection is one method to ensure that machine learning systems remain safe during test time.  The goal of the OOD detector is to determine if the input sample is from a different distribution than that of the training data.  If an OOD sample is detected, the detector can raise a flag indicating that the output of the machine learning system should not be considered safe, and that the system should enter a new control regime.  In an autonomous vehicle, this may mean handing control back to the driver, or bringing the vehicle to a stop as soon as practically possible.

In this paper we consider the existing β-VAE based OOD detection architecture.  This architecture takes advantage of the information bottleneck in a variational auto-encoder (VAE) to learn the distribution of training data.  In this detector the VAE undergoes unsupervised training with the goal of minimizing the error between a true prior probability in input space p(z), and an approximated posterior probability from the encoder output p(z|x).  During test time, the Kullback-Leibler divergence between these distributions p(z) and q(z|x) will be used to assign an OOD score to each input sample.  Because the training goal was to minimize the distance between these two distributions on in-distribution data, in-distribution data found at runtime should have a low OOD score while OOD data should have a higher OOD score.

Duckietown

We used Duckietown to implement our OOD detector.  Duckietown provides a natural test bed because:

  • It is modular and easy to learn: the focus of our research is about implementing an OOD detector, not building a robot from scratch
  • It is a resource constrained system: the RPi on the DB18 is powerful enough to be capable of navigation tasks, but resource constrained enough that real-time performance is not guaranteed.  It servers as a good analog for a  system in which an OOD detector shares a CPU with perception, planning, and control software.
  • It is open source: this eliminates the need to purchase and manage licenses, allows us to directly check the source code when we encounter implementation issues, and allows us to contribute back to the community once our project is finished.
  • It is low-cost: we’re not made of money 🙂
 In our experiment, we used the stock DB18 robot.  Because we took advantage of the existing Duckietown framework, we only had to write three ROS nodes ourselves:
  • Lane following node: a simple OpenCV-based lane follower that navigates based on camera images.  This represents the perception and planning system for the mobile robot that we are trying to protect.  In our system the lane following node takes 640×480 RGB images and updates the planned trajectory at a rate of 5Hz.
  • OOD detection node: this node also takes images directly from the camera, but its job is to raise a flag when an OOD input appears (image with an OOD score greater than some threshold).  On the RPi with no GPU or TPU, it takes a considerable amount of time to make an inference on the VAE, so our detection node does not have a target rate, but rather uses the last available camera frame, dropping any frames that arrive while the OOD score is being computed.
  • Motor control node: during normal operation it takes the trajectory planned by the lane following node and sends it to the wheels.  However, if it receives a signal from the OOD detection node, it begins emergency breaking.

The Experiment

Our experiment considers the emergency stopping distance required for the Duckiebot when an OOD input is detected.  In our setup the Duckiebot drives forward along a straight track.  The area in front of the robot is divided into two zones: the risk zone and the safe zone.  The risk zone is an area where if an obstacle appears, it poses a risk to the Duckiebot.  The safe zone is further away and to the sides; this is a region where unknown obstacles may be present, but they do not pose an immediate threat to the robot.  An obstacle that has not appeared in the training set is placed in the safe zone in front of the robot.  As the robot drives forward along the track, the obstacle will eventually enter the risk zone.   Upon entry into the risk zone we measure how far the Duckiebot travels before the OOD detector triggers an emergency stop.

We defined the risk zone as the area 60cm directly in front of our Duckiebot.  We repeated the experiment 40 times and found that with our system architecture, the Duckiebot stopped on average 14.5cm before the obstacle.  However, in 5 iterations of the experiment, the Duckiebot collided with the stationary obstacle.

We wanted to analyze what lead to the collision in those five cases.  We started by looking at the times it took for our various nodes to run.  We plotted the distribution of end-to-end stopping times, image capture to detection start times, OOD detector execution times, and detection result to motor stop times.  We observed that there was a long tail on the OOD execution times, which lead us to suspect that the collisions occurred when the OOD detector took too long to produce a result.  This hypothesis was bolstered by the fact that even when a collision had occurred, the last logged OOD score was above the detection threshold, it had just been produced too late.  We also looked at the final two OOD detection times for each collision and found that in every case the final two times were above the median detector execution time.  This highlights the importance of real-time scheduling  when performing OOD detection in a cyber-physical system.

We also wanted to analyze what would happen if we adjusted the OOD detection threshold.  Because we had logged the the detection threshold every time the detector had run, we were able to interpolate the position of the robot at every detection time and discover when the robot would have stopped for different OOD detection thresholds.  We observe there is a tradeoff associated with moving the detection threshold.  If the detection threshold is lowered, the frequency of collisions can be reduced and even eliminated.  However, the mean stopping distance is also moved further from the obstacle and the robot is more likely to stop spuriously when the obstacle is outside of the risk zone.

 

Next Steps

In this paper we successfully implemented an OOD detector on a mobile robot, but our experiment leaves many more questions:

  • How does the performance of other OOD detector architectures compare with the β-VAE detector we used in this paper?
  • How can we guarantee the real-time performance of an OOD detector on a resource-constrained system, especially when sharing a CPU with other computationally intensive tasks like perception, planning, and control?
  • Does the performance vary when detecting more complex OOD scenarios: dynamic obstacles, turning corners, etc.?

Did you find this interesting?

Read more Duckietown based papers here.

EdTech awards 2021: Duckietown finalist in 3 categories!

Posted on | by Ivano Marocchi

Duckietown reaches the finals in the EdTech Awards 2021

The EdTech awards are the largest and most competitive recognition program in all of education technology.

The competition, led by the EdTech digest, recognizes the biggest names in edtech – and those who soon will be, by identifying all over the world the products, services and people that bet promote education through the use of technology, for the benefit of learners.

The 2021 edition has brought a big surprise to Duckietown, as it was nominated as a finalist in 3 different categories:

  • Cool Tool Award: as robotics (for learning, education) solution;
  • Cool Tool Award: as higher education solution;
  • Trendsetter Award: as a product or service setting a trend in education technologies.

Although a final is just a starting point, we are proud of the hard work done by the team in this particularly difficult year of pandemic and lockdowns, and grateful to you all for the incredible support, constructive feedback and contributions!

To the future, and beyond!

(hidden) Want to learn more about us?

Click here
Ubuntu laptop terminal interface with hands operating keyboard, Duckiebot and duckies out of focus in foreground

“Self-Driving Cars with Duckietown” MOOC starting soon

Posted on | by Duckietown Admin

Join the first hardware based MOOC about autonomy on edX!

Are you curious about robotics, self-driving cars, and want an opportunity to build and program your own? Set to start on March 22nd, 2020, “Self-Driving Cars with Duckietown” is a hands-on introduction to vehicle autonomy, and the first ever self-driving cars MOOC with a hardware track!

Designed for university-level students and professionals, this course is brought to you by the Swiss Federal Institute of Technology in Zurich (ETHZ), in collaboration with the University of Montreal, the Duckietown Foundation, and the Toyota Technological Institute at Chicago.

Learning autonomy requires a fundamentally different approach when compared to other computer science and engineering disciplines. Autonomy is inherently multi-disciplinary, and mastering it requires expertise in domains ranging from fundamental mathematics to practical machine-learning skills.

This course will explore the theory and implementation of model- and data-driven approaches for making a model self-driving car drive autonomously in an urban environment, while detecting and avoiding pedestrians (rubber duckies)!

Enroll for free on edX

In this course you will learn, hands-on, introductory elements of:

  • computer vision
  • robot operations 
  • ROS, Docker, Python, Ubuntu
  • autonomous behaviors
  • modelling and control
  • localization
  • planning
  • object detection and avoidance
  • reinforcement learning.
Duckietown Duckiebot model DB21J4 on a lane

The Duckietown robotic ecosystem was created at the MIT Computer Science and Artificial Intelligence Laboratory (CSAIL) in 2016 and is now used in over 90 universities worldwide.

“The Duckietown educational platform provides a hands-on, scaled down, accessible version of real world autonomous systems.” said Emilio Frazzoli, Professor of Dynamic Systems and Control, ETH Zurich, “Integrating NVIDIA’s Jetson Nano power in Duckietown enables unprecedented access to state-of-the-art compute solutions for learning autonomy.”

Pedestrian detection: there are many obstacles in Duckietown - some move and some don't. Being able to detect pedestrians (duckies) is important to guarantee safe driving.
Enroll for free on edX

This massive online open course will be have a hands-on learning approach using, for the hardware track, real robots. You will learn how autonomous vehicles make their own decisions, going from theory to implementation, deployment in simulation as well as on the new NVIDIA Jetson Nano powered Duckiebots.

“The new NVIDIA Jetson Nano 2GB is the ultimate starter AI computer for educators and students to teach and learn AI at an incredibly affordable price.” said Deepu Talla, Vice President and General Manager of Edge Computing at NVIDIA. “Duckietown and its edX MOOC are leveraging Jetson to take hands-on experimentation and understanding of AI and autonomous machines to the next level.”

The Duckiebot MOOC Founder’s edition kits are available worldwide, and thanks to OKdo, are now available with free shipping in the United States and in Asia!

Get the Hardware in the USA or Asia
Get the Hardware in the rest of the world

“I’m thrilled that ETH, with UMontreal, the Duckietown Foundation, and the Toyota Technological Institute in Chicago, are collaborating to bring this course in self-driving cars and robotics to the 35 million learners on edX. This emerging technology has the potential to completely change the way we live and travel, and the course provides a unique opportunity to get in on the ground floor of understanding and using the technology powering autonomous vehicles,” said Anant Agarwal, edX CEO and Founder, and MIT Professor.

Enroll now and don’t miss the chance to join in the first vehicle autonomy MOOC with hands-on learning!

Enroll for free on edX

Robert Moni’s experience after winning AI-DO 5

Posted on | by Liuxin

An interview with Robert Moni

Robert is a Ph. D. student at the Budapest University of Technology and Economics.

His work focuses on deep learning and he has (co)authored papers on reinforcement learning (RL), imitation learning (IL), and sim-to-real learning using for autonomous vehicles using Duckietown.

Robert and his team won the LFV_multi hardware challenge of the 2020 AI Driving Olympics.

Today, Robert shares some of his thoughts with us!

What brought you to work on AVs?

I started my journey in the world of AV’s in 2016 when I was hired at the automotive supplier company “Continental” in Romania. In 2018 I moved to Budapest, Hungary, to join Continental’s Deep Learning Competence Center where we develop novel perception methods for AVs.

In 2019, with the support of the company, I started my Ph.D. at Budapest University of Technology and Economics on the topic “Deep Reinforcement Learning in Complex environments”.

At this time, I crossed paths with the Duckietown environment. Continental bought 12 Duckiebots and supplementary materials to build our own Duckietown environment in a lab at the university.

Tell us about you and your team

At the beginning of my Ph. D. and with the arrival of the Duckietown materials we established the “PIA” (Professional Intelligence for Automotive) project with the aim to provide education and mentorship for undergrad and master students in the field on Machine Learning and AV.

In each semester since 2019 February I managed a team of 4-6 people developing their own solutions for AI-DO challenges. I wrote a short blogpost presenting my team and our solutions submitted to AI-DO 5.

"With the arrival of the Duckietown material we established the PIA project with the aim to provide education and mentorship for undergrad and master students in the field on Machine Learning and autonomous vehicles (AV)."

Robert Moni

What approach did you choose for AI-DO, and why?

I started to tackle the AI-DO challenges applying deep reinforcement learning (DRL) for driver policy learning and state representation learning (SRL) for sim2real transfer.

The reason for my chosen approach is my Ph. D. topic, and I plan to develop and test my hypotheses in the Duckietown environment.

What are the hardest challenges that you faced in the competition?

In the beginning, there was a simple agent training task that caused some headaches: finding a working DRL method, composing a good reward function, preprocessing the observations to reduce the search space, and fine-tuning all the parameters. All these were challenges, but well-known ones in the field.

One unexpected challenge was the continuous updates of the gym-duckietown environment. While we are thrilled that the environment gets improved by the Duckietown team, we faced occasional breakdowns in our methods when applying them to the newest releases, which caused some frustration.

The biggest headache was caused by the different setups in the training and evaluation environments: in the evaluation environment, the images are dimmed while during training they are clear. Furthermore, the real world is full of nuisances – for example lags introduced by WiFi communication, which causes different outcomes in the real environment. This challenge can be mitigated to some degree with the algorithms running directly on the Duckiebot’s hardware, and by using a more powerful onboard computer, e.g., the Jetson Nano 2GB development board.

Are you satisfied with the final outcome?

I am satisfied with the achievements of my team, which kept the resolve throughout the technical challenges faced.

I’m sure we would’ve done even better in the real-world challenge if we had seen our submission running earlier in the Autolab, so we could have adjusted our algorithms. We are going to work to bring one to our University in the next future.

What are you going to change next time?

I believe the AI-DO competition as well as the Duckietown platform would improve through more powerful hardware. I hope to see Duckiebots (DB19)  upgraded to support the new Jetson Nano hardware!

(Since the date of the interview, Duckiebots model DB21 supports Jetson Nano boards)

Learn more about Duckietown

The Duckietown platform offers robotics and AI learning experiences.

Duckietown is modular, customizable and state-of-the-art. It is designed to teach, learn, and do research: from exploring the fundamentals of computer science and automation to pushing the boundaries of knowledge.

Find out more use cases
Get Started with Duckietown!

Tell us your story

Are you an instructor, learner, researcher or professional with a Duckietown story to tell? Reach out to us!

AI Driving Olympics 5th edition: results

Posted on | by Ivano Marocchi

AI-DO 5: Urban league winners

This year’s challenges were lane following (LF), lane following with pedestrians (LFP) and lane following with other vehicles, multibody (LFV_multi). 

Let’s find out the results in each category:

LF

  1. Andras Beres 🇭🇺  
  2. Zoltan Lorincz 🇭🇺
  3. András Kalapos 🇭🇺

LFP

  1. Bea Baselines 🐤
  2. Melisande Teng 🇨🇦 
  3. Raphael Jean 🇨🇦

LFV_multi

  1. Robert Moni 🇭🇺
  2. Márton Tim 🇭🇺
  3. Anastasiya Nikolskay 🇷🇺

Congratulations to the Hungarian Team from the Budapest University of Technology and Economics for collecting the highest rankings in the urban league!

Here’s how the winners in each category performed both in the qualification (simulation) and in the finals running on real hardware:

Andras Beres - Lane following (LF) winner

See the evaluation details

Melisande Teng - Lane following with pedestrians (LFP) winner

See the evaluation details

Robert Moni - Lane following with other vehicles, multibody (LFV_multi) winner

See the evaluation details

AI-DO 5: Advanced Perception league winners

Great participation and results in the Advanced Perception league! Check out this year’s winners in the video below:

AI-DO 5 sponsors

Many thanks to our amazing sponsors, without which none of this would have been possible!

Stay tuned for next year AI Driving Olympics. Visit the AI-DO page for more information on the competition and to browse this year’s introductory webinars, or check out the Duckietown massive open online course (MOOC) and prepare for next year’s competition!

Learn more about the MOOC
Learn more about the AI-DO

AI-DO 5 competition leaderboard update

Posted on | by Jacopo Tani

AI-DO 5 pre-finals update

With the fifth edition of the AI Driving Olympics finals day approaching, 1326 solutions submitted from 94 competitors in three challenges, it is time to glance over at the leaderboards! 

Leaderboards updates

This year’s challenges are lane following (LF), lane following with pedestrians (LFP) and lane following with other vehicles, multibody (LFV_multi). Learn more about the challenges here. Each submission can be sent to multiple challenges. Let’s look at some of the most promising or interesting submissions.

The Montréal menace

Raphael Jean at Mila / University of Montréal is a new entrant for this year. 

An interesting submission: submission #12962 

All of raph’s submissions.

The submissions from the cold

Team JetBrains from Saint Petersburg was a winner of previous editions of AI-DO. They have been dominating the leaderboards also this year.

Interesting submissions: submission #12905

All of JetBrains submissions: JBRRussia1. 

 

BME Conti

PhD student Robert Moni (BME-Conti) from Hungary. 

Interesting submissions: submission #12999 

All submissions: timur-BMEconti

 

Deadline for submissions

The deadline for submitting to the AI-DO 5 is 12am EST on Thursday, December 10th, 2020. The top three entries (more if time allows) in each simulation challenge will be evaluated on real robots and presented at the finals event at NeurIPS 2020, which happens at 5pm EST on Saturday, December 12.

Join the AI Driving Olympics now!

Test your skills in the urban league challenges and qualify for the finals at NeurIPS!
Join the AI-DO
AI-DO 5

AI-DO 5 competition Update

Posted on | by Andrea Censi

AI-DO 5 Update

AI-DO 5 is in full swing and we want to bring you some updates: better graphics, more maps, faster and more reliable backend and an improved GUI to submit to challenges! 

Challenges visualization

We updated the visualization. Now the evaluation produces videos with your name and evaluation number (as below).

Challenges updates

We fixed some of the bugs in the simulator regarding the visualization (“phantom robots” popping in and out). 

We updated the maps in the challenges to have more variety in the road network; we put more grass and trees to make the maps more joyful!

We have updated the maps with more trees and grass

Faster and more reliable backend

The server was getting slow given the number of submissions, and sometime the service was unavailable. We have revamped the server code and added some backend capacity to be more fault-tolerant. It is now much faster!

Thanks so much to the participants that helped us debug this problem!

We overhauled the server code to make it much faster!

More evaluators

We brought online many more CPU and GPU evaluators. We now encourage you to submit more often as we have a lot more capacity.

We have many more evaluators now!

Submit to testing challenges

We also remind you that the challenges on the front page are the validation challenges, in which everybody can see the output. However what counts for winning are the testing challenges!  

To do that you can use dts challenges submit with the –challenges option

Or, you can use a new way using the website that we just implemented, described below.

Submitting to other challenges

Step 1: Go to your user page, by clicking “login” and then going to “My Submissions”.

Step 2: In this page you will find your submissions grouped by “component”. 

Click the component icon as in the figure.

Step 3: The page will contain some buttons that allow you to submit to other challenges that you didn’t submit to yet.

Join the AI Driving Olympics

Imitation Learning Approach for AI Driving Olympics Trained on Real-world and Simulation Data Simultaneously

Posted on | by Konstantin Chaika

Imitation Learning Approach for AI Driving Olympics Trained on Real-world and Simulation Data Simultaneously

The AIDO challenge is divided into two global stages: simulation and real-world. A single algorithm needs to perform well in both. It was quickly identified that one of the major problems is the simulation to real-world transfer. 

Many algorithms trained in the simulated environment performed very poorly in the real world, and many classic control algorithms that are known to perform well in a real-world environment, once tuned to that environment, do not perform well in the simulation. Some approaches suggest randomizing the domain for the simulation to real-world transfer.

We propose a novel method of training a neural network model that can perform well in diverse environments, such as simulations and real-world environment.

Dataset Generation

To that end, we have trained our model through imitation learning on a dataset compiled from four different sources:

  1. Real-world Duckietown dataset from logs.duckietown.com (REAL-DT).
  2. Simulation dataset on a simple loop map (SIM-LP).
  3. Simulation dataset on an intersection map (SIM-IS).
  4. Real-world dataset collected by us in our environment with car driven by PD controller (REAL-IH).

We aimed to collect data with as many possible situations such as twists in the road, driving in circles clockwise/counterclockwise, and so on. We have also tried to diversify external factors such as scene lighting, items in the room that can get into the camera’s field of view, roadside objects, etc. If we keep these conditions constant, our model may overfit to them and perform poorly in a different environment. For this reason, we changed the lighting and environment after each duckiebot run. The lane detection was calibrated for every lighting condition since different lighting changes the color scheme of the image input.

We made the following change to the standard PD algorithm: since most Duckietown turns and intersections are standard-shaped, we hard-coded the robot’s motion in these situations, but we did not exclude imperfect trajectories. For example, the ones that would go slightly out of bounds of the lane. Imperfections in the robot’s actions increase the robustness of the model. 

Neural network architecture and training

Original images are 640×480 RGB. As a preprocessing step, we remove the top third of the image, since it mostly contains the sky, resize the image to 64×32 pixels and convert it into the YUV colorspace.

We have used 5 convolutional layers with a small number of filters, followed by 2 fully-connected layers. The small size of the network is not only due to it being less prone to overfitting, but we also need a model that can run on a single CPU on RaspberryPi.

We have also incorporated Independent-Component (IC) layers. These layers aim to make the activations of each layer more independent by combining two popular techniques, BatchNorm and Dropout. For convolutional layers, we substitute Dropout with Spatial Dropout which has been shown to work better with them. The model outputs two values for voltages of the left and the right wheel drives. We use the mean square error (MSE) as our training loss.

Results

For the training evaluation, we compute the mean square error (MSE) of the left and the right wheels outputs on the validation set of each data source. 

The first table shows the results for the models trained on all data sources (HYBRID), on real-world data sources only (REAL) and on simulation data sources only (SIM). As we can see, while training on a single dataset sometimes achieves lower error on the same dataset than our hybrid approach. We can also see that our method performs on par with the best single methods. In terms of the average error it outperforms the closest one tenfold. This demonstrates definitively the high dependence of MSE on the training method, and highlights the differences between the data sources.

The next table shows simulation closed-loop performance for all our approaches using the Duckietown simulator. All methods drove for 15 seconds without major infractions, and the SIM model that was trained specifically on the simulation data only drove just 1.8 tiles more than our hybrid approach.

The third table shows the closed-loop performance in the real-world environment. Comparing the number of tiles, we see that our hybrid approach drove about 3.5 tiles more than the following in the rankings model trained on real-world data only.

Conclusion

Our method follows the imitation learning approach and consists of a convolutional neural network which is trained on a dataset compiled from data from different sources, such as simulation model and real-world Duckietown vehicle driven by a PD controller, tuned to various conditions, such as different map configuration and lighting. 

We believe that our approach of emphasizing neurons independence and monitoring generalization performance can offer more robustness to control models that have to perform in diverse environments. We also believe that the described approach of imitation learning on data obtained from several algorithms that are fitted to specific environments may yield a single algorithm that will perform well in general.

 —
 JBRRussia1 team
Join the AI-DO!

The “Self-Driving cars with Duckietown” Massive Open Online Course on edX

Posted on | by Jacopo Tani

"Self-Driving Cars with Duckietown" hands-on MOOC on edX

We are launching a massive open online course (MOOC): “Self-Driving Cars with Duckietown” on edX, and it is free to attend! 

This course is made possible thanks to the support of the Swiss Federal Institute of Technology in Zurich (ETHZ), in collaboration with the University of Montreal, the Duckietown Foundation, and the Toyota Technological Institute at Chicago.

This course combines remote and hands-on learning with real-world robots. It is offered on edX, the trusted platform for learning, and it is now open for enrollment. 

Learning activities will support the use of Jetson Nano equipped Duckiebots, powered by NVIDIA.

Enroll on edX

Learning autonomy

Participants will engage in software and hardware hands-on learning experiences, with focus on overcoming the challenges of deploying autonomous robots in the real world.

This course will explore the theory and implementation of model- and data-driven approaches for making a model self-driving car drive autonomously in an urban environment.

Pedestrian detection: there are many obstacles in Duckietown - some move and some don't. Being able to detect pedestrians (duckies) is important to guarantee safe driving.

Pedestrian detection

MOOC Factsheet

  • Name: Self-driving cars with Duckietown
  • Start: March 2021
  • Platform: edX
  • Cost: free to attend

Prerequisites

  • Basic Linux, Python, Git
  • Elements of linear algebra, probability, calculus
  • Elements of kinematics, dynamics
  • Computer with native Ubuntu installation

What you will learn​

  • Computer Vision
  • Robot operations
  • Object Detection
  • Localization, planning and control
  • Reinforcement Learning
Enroll on edX

Why Self-driving cars with Duckietown?

Teaching autonomy requires a fundamentally different approach when compared to other computer science and engineering disciplines, because it is multi-disciplinary. Mastering it requires expertise in domains ranging from fundamental mathematics to practical machine-learning skills.

Robot Perception 

Robots operate in the real world, and theory and practice often do not play well together. There are many hardware platforms and software tools, each with its own strengths and weaknesses. It is not always clear what tools are worth investing time in mastering, and how these skills will generalize to different platforms. 

Duckiebot Detection: driving in Duckietown is fun but safety should always be paramount. DuckieBots can detect other vehicles and estimate their relative poses to avoid collisions.

Duckiebot Detection

Learning through challenges

Progressing through behaviors of increasing complexity, participants uncover concepts and tools that address the limitations of previous approaches. This allows to get Duckiebots to actually do things, while gradually re-iterating concepts through various technical frameworks. Simulation and real-world experiments will be performed using a Python, ROS, and Docker based software stack.

Robot Planning: as Duckietowns grow bigger, smart Duckiebots plan their path in town. Traffic signs at intersections provide landmarks to localize on the global map and determine next turns.

Robot Planning

Enroll on edX

(Hidden) This line and everything under this line are hidden

This course combines remote and hands-on learning with real-world robots.

It is offered on edX, the trusted platform for learning, and it is now open for enrollment.

Learning activities will support the use of NVIDIA Jetson Nano powered Duckiebots.