Robotics with mBot #2

Follow-up of my previous article about my experience hosting a robotic class in a junior high school. Here is a little wrap-up of the second session.


When I was preparing this second session, I started to write a little memo of the things I wanted to share (a mix of a recap of last session and theoretical introduction!) and some exercise ideas (and proposal of solutions). So I came up with this mini-lesson :

and this list of mini-project ideas:

I printed a dozen copies and came to the class with my stack (and some pride!). I probably dared to picture a group of 12 kids reading the document while nodding in approval and then getting on their machine to execute some of my proposals…


Of course this scenario did not happen at all! The attendees were very excited to see their little robot again (after 2 weeks break) so all they wanted to do was start tinkering with them! After 1 minute most of them were already starting to program and not paying any attention to my little speech about what are the robot “inputs” and “outputs”. So I tried to be as concise as possible and essentially gave up with a “ok, go ahead and enjoy”.


Obviously the top-down approach I came up with was not the right one. The essence of this sort of class is to give some tools to a group and let them play, discover, assemble, dissemble etc. That’s quite demanding for the host though because everybody will react differently and answering to their unique/unexpected requests (I am trying to do X and have this problem) will be more complicated than just giving hints for a problem that was asked to the whole group.


Main question I am fighting with about this all pedagogy topic is if I should hope to reach some milestone in term of knowledge or achievement where I could stop and say “ok, now we’ve understood, as a group, the concept of variables/loops/whatever”. Probably not needed.

Robotics with mBot #1

This year, I volunteered to lead a robotic class in the local high school. I will share some bits of this experience in here. Maybe someday that will help someone going through similar project!


Junior High schools in France are for “kids” from 11 to 14. They do have some classes about computer usage and programming. In this school, Scratch is used by teachers to show programming concepts. Some extra-curriculum activities are offered as well, among which a robotic class was started last year. The initiator of this class chose to work with mBot robots. So I am continuing this class, on a 1 hour every 2 weeks rythme for the whole school year.


I host the class during lunch break with 12 kids organised in 6 pairs. Each pair is sitting behind a large-enough table (so they can have some room to manipulate the robot) and they have a Windows PC with mBlock installed. They can save their work on their private network folder to start from there on next class.


So I did not choose the mBots and can’t share all the motivations for this choice. But one thing quite handy with those robots is that the programming tool associated with them (mBlock) is a fork of scratch. So for kids who used Scratch before, this is perfect. In addition, the robots seem to be reliable and robust. For our class we have 6 robots, so one per pair of kids. We decided to stick with the USB connection between PC and robots: more reliable than bluetooth and WiFi connections from our tests.

Session #1

For the first session, I was helped by the initiator of the project. The robots were already mounted but we decided to completely disassemble them and present them to the kids as if they were just acquired. This way, the first session was started with the mounting the robots (following the user guide). This was way smoother than expected and most groups finished in 20/30 minutes and were able to start connecting the robot to the PC and coding before the end of the class. I had found (and printed) a couple of examples of programs (that were recently added on the mblock site) that I gave them so that they could kick off some little projects and see some LED blinking or hear some buzzer buzzing.

Take aways

  • No surprise here, but kids are not shy with technology! The group was made of volunteer, so not at all a representative sample of the school population, but it was still surprising to see them mounting, plugging and clicking without any sort of restraint.
  • Screwdrivers are delivered in the mBot box. Kids are happy to use them to mount the robot. Though once they get too excited, some of them tend to use them as swords to combat other kid. Advice: take back the screwdrivers once they don’t need them anymore :-)
  • Most of the kids have no idea what an RJ45 socket is… Wifi-generation! I had to show to some groups how to insert it the right way, and how to push the little ear to remove it!
  • To share some important messages/information to the group, the only moment seem to be the beginning of the session. Later they are all in the middle of something and it’s difficult to get everyone attention. And at the end of the class, they just disappear like a flock of bird!




Comment écouter des podcasts

Vous entendez parler des podcasts mais n’avez pas réussi à comprendre comment en écouter avec votre iPhone ? Nous allons détailler ici chaque étape afin que même les plus débutants d’entre vous puissent y arriver. Nous utiliserons l’application “podcast” d’Apple.

1) trouver l’application podcast

L’application “Podcast” est livré par défaut avec vote iPhone. Et comme il est impossible de la supprimer, elle doit encore être là. Si vous ne la trouvez pas, le plus simple est de faire une recherche. Pour ça, faites un balayage vers la droite sur l’écran d’accueil de votre iPhone, et vous arrivez dans la page de recherche où vous pouvez chercher “podcast”:


2) Lancer l’application Podcast

Au premier lancement de l’application, vous arrivez dans l’onglet “non lus” (la barre d’onglet est en bas de l’écran). Comme l’indique l’application, vous n’avez pas de podcast pour l’instant et il va falloir aller en choisir.


3) sélectionner un podcast

Sur l’écran d’accueil de l’application podcast, vous pouvez cliquer sur “Afficher les podcasts recommandés”. Au moment de l’écriture de cet article, la liste proposée était la suivante:


Avant de choisir un podcast dans cette liste, vous pouvez aussi cliquer dans les onglets “Sélection” et “Classements” afin d’avoir un plus grand choix de podcasts.


img_1350Dans l’onglet “Classements”, vous pouvez cliquer sur “Catégories” afin de filtrer la liste sur une seule catégorie.

Pour la suite de l’article, nous allons choisir un podcast : le billet de Nicole Ferroni. Si il n’apparait pas dans les 3 écrans précédents, vous pouvez utiliser l’outil de recherche de l’application (choix “Rechercher” dans l’onglet du bas).

Une fois dans l’écran de recherche, tapez les premières lettre de “Ferroni” et le podcast devrait apparaitre dans la liste. Cliquez dessus :


Vous arrivez dans la page de résultat de la recherche. Dans cette page il y a des épisodes et des podcasts. Plutôt que de télécharger des épisodes de façon unitaire, nous allons voir par la suite comment s’abonner à un podcast (car c’est dans ce scénario que les podcasts prennent tout le sens). Il faut donc cliquer sur le podcast “le billet de Nicole Ferroni” dans la section “Podcasts” des résultats de recherche:


4) s’abonner au podcast

Une fois que vous êtes sur la page de votre podcast, vous avez le choix entre vous abonner au podcast (bouton “s’abonner”) ou télécharger des épisodes en particulier (les icônes ave le nuage et la flèche en face des épisodes qui sont listés):


Comme expliqué plus haut, nous allons nous abonner afin de recevoir régulièrement les nouveaux épisodes futurs. Une fois que vous avez appuyé sur “s’abonner”, on voit apparaitre un petit 1 dans la barre du bas sur l’icône “non lus”. C’est là que les épisodes du podcast seront disponibles.


5) télécharger son premier épisode

Lorsque vous vous abonnez, le dernier épisode du podcast disponible se télécharge automatiquement. Si vous allez sur l’écran “Non lus”, vous voyez que l’épisode est en cours de téléchargement:


Et comme c’est un fichier audio (plutôt petit donc), le téléchargement devrait être assez rapide et il devrait être disponible pour la lecture en quelques secondes ou minutes:


6) Ecouter son premier épisode

Il suffit de sélectionner l’épisode disponible pour que la lecture commence:

img_1358Si vous arrêter la lecture avant la fin de l’épisode, vous pourrez y revenir quand vous voudrez et cela reprendra exactement ou cela s’était arrêté.

7) télécharger d’autres épisodes

Si vous avez terminé d’écouter votre premier épisode, votre écran “Non lus” devraient maintenant être vide :


Si vous ne faites rien et attendez quelques jours, lorsque France Inter va publier un nouvel épisode de Nicole Ferroni, il sera automatiquement téléchargé (quand vous êtes sur un réseau Wi-Fi). Vote liste de lecture va donc s’alimenter toute seule en fonction des publications des podcasts auxquels vous êtes abonnés. Notez que vous ne prenez pas grand risque en terme de taille de stockage sur votre téléphone car les fichiers audios sont plutôt petits.

Si vous ne voulez pas attendre le prochain épisode, vous pouvez aller piocher dans les anciens épisodes. Pour cela, allez dans “Mes podcasts” et choisissez le podcast auquel vous êtes abonné:


La liste des “Non lus” est vide et dessous on voit apparaitre l’épisode lu. Pour voir la liste des épisodes passés, il faut choisir l’onglet “Flux” (pas super intuitif…):


Là vous trouvez les épisodes dans l’ordre inverse de publications (des plus récents aux plus anciens). Si vous choisissez un épisode, la lecture se lance automatiquement ce qui n’est surement pas ce que vous voulez faire, l’idée étant plutôt d’en télécharger plusieurs pour les écouter en faisant son prochain footing. Pour télécharger les épisodes il faut cliquer sur les 3 petits points (encore une fois super intuitif…):


Choisissez “Télécharger l’épisode” et faites de même pour tous les autres épisodes que vous souhaitez télécharger. Ensuite vous pouvez retourner sur l’onglet “Non lus” où vous devriez retrouver les épisodes que vous avez choisis qui seront rapidement téléchargés:


Vous savez donc maintenant faire un petit stock d’épisodes d’un seul podcast. Si vous souhaitez vous abonner à plusieurs podcasts, le principe est le même. Retournez à l’étape du choix du podcast, et choisissez d’autres podcasts auxquelles vous abonner.

Quelques informations pour aller plus loin:

  • quand les épisodes s’empilent trop, vous pouvez les effacer dans l’onglet “Non lus” en balayant vers la droite (l’option “Supprimer” apparait). Même chose pour supprimer complètement un podcast: balayage droit dans l’onglet “Mes podcasts”
  • si vous cherchez des podcasts à écouter, vous avez donc pas mal de choix dans l’application, mais vous pouvez toujours jeter un coup d’oeil à ma selection.
  • si l’application “podcast” vous donne des boutons, vous pouvez aller regarder du côté de Overcast qui est très bien faite (mais pas non plus complètement intuitive)

Bonne écoute !!!

Silicon Cowboys

Now that Personal Computers sales seem to have peaked to the profit of iOS and Androids mobile devices, it is worth remembering how this market grew from hobbyists-only to massive market during the 80’s. Apple and Microsoft “wars and peace” made it into many books/documentaries and Steve Jobs and Bill Gates fame is such that we are regularly remembered of their biographies. But at the same time, another battle took place: IBM versus its clones. The documentary “Silicon Cowboys” is telling the story of how Compaq (created in Texas, hence the “cowboys”) entered the market of Personal Computer with a bet on high compatibility with IBM PCs and portability. This is quite a fascinating watch to see “David” Compaq beating “Goliath” IBM in the PC market. An episode I was not totally familiar with is how Compaq and 8 others manufacturers responded with EISA standard to IBM move to launch an “incompatible” PS/2 computer. At the beginning of the 90’s the “IBM PC clones” market was huge and as DOOM (released?) was available on PC, it was about time for the late-teenagers to sell their Commodore/Atari and buy a 486. Unfortunately for Compaq, the market remained ultra-competitive, and Compaq was unable to fight with DELL or unbranded PC assembled in small shops.

Watch “Silicon Cowboys” if you want a nice piece of geek-history!
And if you want to go further on the topic, you might be interested in
– The book written by Rod Canion about the story of Compaq: How Compaq Ended IBM’s PC Domination and Helped Invent Modern Computing (amazon/audible)
Halt and Catch Fire (loosely based on Compaq history)
Internet History Podcast episode with Rod Canion


My favorite podcasts

Year after years, I am becoming more and more addicted to podcasts. Here is a list of the the ones I am currently listening to:

  • Internet History Podcast – My all-time favorite. Starting with Mosaic and Netscape, it is the story of Internet since the beginning of the web 20 years ago. Mix of “chapter episode” where Brian tells episodes of this amazing period and “interview episode” in which actors of this story appear.  Very very well researched and delivered. Hats off to Brian for this fabulous (and useful) work!
  • This week in TechLeo Laporte is a great host and have some very interesting guests to discuss all things about tech. Sometimes a bit chatty but always full of energy.
  • NipTech – (in french). Their motto: “#tech #startups #inspiration”. Good content and rythme. Ben and Mike are doing a great job! Fun to listen!
  • Le RDV Tech – (in french).  Tech news, rumors and stories by Patrick with various guests. He takes time to explain and dig into some hot topics and is not afraid to share opinions on polemical topics.
  • a16z – Andreessen Horowitz VC company podcast. High quality with high profiles guests. Mostly about topic in which a16z is investing (bitcoins, AI, big data etc.).
  • Foundation – Interviews with tech entrepreneurs who share their paths, their advices and some anecdotes.
  • This American Life –  My other all-time favorite, this time not tech related. Mostly true stories of everyday people. Deep dive in american life. Very very well produced. Fascinating.

Should the test automation framework be written in the same language the application is being written or developed in?

Just tweeted an article published by Sauce Labs on “Reducing False Positives in Automated Testing” that takes the form of a Q&A about automation. I mostly agree with the article but there is one answers that bothers me :

Should the test automation framework be written in the same language the application is being written or developed in?

A: Yes. Creating the automation framework in the same language of application will help the development team in testing specified areas whenever there is any code change or defect fix.[…]

I would replace the “yes” by “it depends”. I also see value in using another langage to automate functional tests. Specially when you have a dedicated QA/tester team. Here are a couple of reasons:

  • if your company is producing different products in different langages, then it could be difficult for your QA team to keep up with those different langages for their automation. So using a single langage for the tests would ease QA life. That would also allow QA to share libraries/tools among different tests for different SUT.
  • hiring skilled QA is not easy. Finding people with good functional understanding/curiosity of the SUT *and* a good technical knowledge can be difficult. Asking them to code in a langage like Python/Ruby rather than coding in C, C#, Java etc. could be make it easier to achieve
  • using a different langage than the SUT is also a good way to force QA (or dev if they code tests) to take a new perspective on the SUT. If you test your Java product in Java, you might swim in the “integration tests” water and even when you try to black-box test your application, you might end up interacting with the SUT in a gray-box way.

In the end it really depends on your organisation, culture, people etc. but it is worth having a debate on that point. You might want to take a look at this other article on the same subject: Your automated acceptance tests needn’t be written in the same language as your system being tested

Re-executing failed test cases and merging outputs with Robot Framework

In a previous post, I discussed solving intermittent issues aka building more robust automated tests. A solution I did not mention is the simple “just give it another chance”. When you have big and long suites of automated tests (quite classic to have suites in the 1000’s and lasting hours when doing functional tests), then you might get a couple of tests randomly failing for unknown reasons. Why not just launching only those failed tests again? If they fail once more, you are hitting a real problem. If they succeed, you might have hit an intermittent problem and you might decide to just ignore it.

Re-executing failed tests (–rerunfailed) appeared in Robot Framework 2.8. And since version 2.8.4 a new option (–merge) was added to rebot to merge output from different runs. Like explained in the User Guide, those 2 options make a lot of sense when used together:

# first execute all tests
pybot --output original.xml tests 
# then re-execute failing
pybot --rerunfailed original.xml --output rerun.xml tests 
# finally merge results
rebot --merge original.xml rerun.xml

This will produce a single report where the second execution of the failed test is replacing the first execution. So every test appears once and for those executed twice, we see the first and second execution message:


Here, I propose to go a little bit further and show how to use –rerunfailed and –merge while:

  • writing output files in an “output” folder instead of the execution one (use of –outputdir). This is quite a common practice to have the output files written in a custom folder but it makes the whole pybot call syntax a bit more complex.
  • giving access to log files from first and second executions via links displayed in the report (use of Metadata). Sometimes having the “new status” and “old status” (like in previous screenshot) is not enough and we want to have details on what went wrong in the execution, and having only the merged report is not enough.

To show this let’s use a simple unstable test:

*** Settings ***
Library  String

*** Test Cases ***
    should be true  ${True}

    ${bool} =  random_boolean
    should be true  ${bool}
*** Keywords ***
    ${nb_string} =  generate random string  1  [NUMBERS]
    ${nb_int} =  convert to integer  ${nb_string}
    Run keyword and return  evaluate  (${nb_int} % 2) == 0

The unstable_test will fail 50% of times and the stable test will always succeed.

And so, here is the script I propose to launch the suite:

# clean previous output files
rm -f output/output.xml
rm -f output/rerun.xml
rm -f output/first_run_log.html
rm -f output/second_run_log.html
echo "#######################################"
echo "# Running portfolio a first time      #"
echo "#######################################"
pybot --outputdir output $@
# we stop the script here if all the tests were OK
if [ $? -eq 0 ]; then
	echo "we don't run the tests again as everything was OK on first try"
	exit 0	
# otherwise we go for another round with the failing tests
# we keep a copy of the first log file
cp output/log.html  output/first_run_log.html
# we launch the tests that failed
echo "#######################################"
echo "# Running again the tests that failed #"
echo "#######################################"
pybot --outputdir output --nostatusrc --rerunfailed output/output.xml --output rerun.xml $@
# Robot Framework generates file rerun.xml
# we keep a copy of the second log file
cp output/log.html  output/second_run_log.html
# Merging output files
echo "########################"
echo "# Merging output files #"
echo "########################"
rebot --nostatusrc --outputdir output --output output.xml --merge output/output.xml  output/rerun.xml
# Robot Framework generates a new output.xml

and here is an example of execution (case where unstable test fails once and then succeeds):

$ ./ unstable_suite.robot

# Running portfolio a first time      #

Unstable Suite
stable_test                                       | PASS |
unstable_test                                     | FAIL |
'False' should be true.
Unstable Suite                                    | FAIL |
2 critical tests, 1 passed, 1 failed
2 tests total, 1 passed, 1 failed
Output:  path/to/output/output.xml
Log:     path/to/output/log.html
Report:  path/to/output/report.html

# Running again the tests that failed #

Unstable Suite
unstable_test                                     | PASS |
Unstable Suite                                    | PASS |
1 critical test, 1 passed, 0 failed
1 test total, 1 passed, 0 failed
Output:  path/to/output/rerun.xml
Log:     path/to/output/log.html
Report:  path/to/output/report.html

# Merging output files #

Output:  path/to/output/output.xml
Log:     path/to/output/log.html
Report:  path/to/output/report.html

So, the first part is done: we have a script that launch the suite twice if needed and put all the output in “output” folder. Now let’s update the “settings” section of our test to include links to first and second run logs:

*** Settings ***
Library   String
Metadata  Log of First Run   [first_run_log.html|first_run_log.html]
Metadata  Log of Second Run  [second_run_log.html|second_run_log.html]

 If we launch our script again, we will get a report with links to first and second run in the “summary information” section:


The script and the test can be found in a GitHub repository. Feel free to comment on that topic if you found out more tips on those Robot options.

Visual Regression Tests

The first rule of “UI automated regression tests” is “You do not perform any UI automated regression tests”.

The second rule of “UI automated regression tests” is “In some contexts, if you really know what you are doing, then some automated regression tests performed via the UI can be relevant”.

Martin Fowler explained it very well in his Testing Pyramid article: “a common problem is that teams conflate the concepts of end-to-end tests, UI tests, and customer facing tests. These are all orthogonal characteristics. For example a rich javascript UI should have most of its UI behaviour tested with javascript unit tests using something like Jasmine”. So the top of a testing pyramid should be:

  • built on top of a portfolio of unit and service/component/api tests (that should include some tests focussed on the UI layer)
  • a (small) set of end-2-end tests performed via the GUI to check that we did not miss anything with our more focussed tests.

For those end-2-end tests, the usual suspect in the Open Source scene is Selenium. Driving the browser through our app via the most common paths is a good way to gain some final confidence on the SUT. But one should really understand that what Selenium will check is the presence of some elements on the page and the events associated with some elements. “if I fill this input box and click on that button then I expect to see a table with this and that strings in it”, but it does not check the visual aspect of the page. To put it another way, with Selenium we are checking the nervous system of our SUT, but not its skin. Here come the visual regression testing tools.

Thoughtworks Radar raised their level from “assess” to “trial” on “visual regression testing tools last July with this comment: “Growing complexity in web applications has increased the awareness that appearance should be tested in addition to functionality. This has given rise to a variety of visual regression testing tools, including CSS Critic, dpxdt, Huxley, PhantomCSS, and Wraith. Techniques range from straightforward assertions of CSS values to actual screenshot comparison. While this is a field still in active development we believe that testing for visual regressions should be added to Continuous Delivery pipelines.”

So I wanted to give it a try and did a quick survey of the tools available. I wanted to know which project were still active, what was their langage/ecosystem and what browser were supported. Here is list I just built:

My shopping list was:

  • Python, as I am already using Robot Framework in this langage
  • Support for another browser than PhantomJS because my SUT does not render very well under PhantomJS at the moment

So I chose needle which, according to its author is “still being maintained, but I no longer use it for anything”. I gave it a try and it works well indeed. I now have a basic smoke test trying to catch visual regression tests. More on that soon if I have more feedback to share.

Create Jenkins Job for Robot Framework

Once you have created your first tests in Robot Framework, next step is to include those tests in your Continuous Integration (CI) System. Here I will show the different steps to do so in Jenkins.

Let’s assume you have


First we create a new job to launch our Robot tests:


Once the job is created, we configure it.

  1. set up Source Code Management for the source code of the tests:jenkins_svn
  2. set up a first “Build Trigger” on the success of the job that builds the SUT:trigger_build
  3. set up a second “Build Trigger” on changes in the Source Code of the tests:trigger_scm
    This way your tests will be launched either if there is a new build of the SUT or if your tests have changed. Second trigger is relevant because some modifications in your tests may have broken some of them, and you don’t want to wait for the next build of the SUT to find it out. In other words, when a test fails in Jenkins, it is good to know if this is a consequence of a change in the SUT of a change in the tests (if both changed, analysis will be tricker).
  4. get the artefact from the project that build your SUT so that your SUT is available from your Jenkins’ workspace where the Robot tests will be run. To do so you can either use the Jenkins Copy Artifact Plugin or write a piece of Batch/Shell script.screenshot-copy-artefacts
  5. The comes the step in which Robot tests are going to be launched. For this you create a “Execute Shell” Build step that contains, at least:
    pybot path/to/my_tests/

    and all the –variable, –include, –exclude etc. that you use to customise you run.
    One noteworthy command line option in the context of a CI server is –NoStatusRC, which force Robot’s return code to zero even when there is test that fails. This way the status of the Jenkins build can be driven by Robot Jenkins Plugin like you will see in final step.build_robot

  6. Finally, to have a more granular settings of the results of the tests, and keep a copy of the report/log of the test executions located in the Jenkins Server, you can use Robot Framework Plugin. Once the plugin is installed, it will be available in the list of “Post Builds Actions”. A simple configuration would be like this:pluginand after a couple of builds, the project page would look like that:plugin_project_page

Once this basic setup is working, you will find out many options in Jenkins and Robot Framework to get more value out of it. To give just one example, once the test portfolio becomes large and/or long, you might find out that this is not efficient to launch the full regression suite at once when there is a change in the SUT or the tests’ code. A good strategy is to have 2 Jenkins job. The first one (“smoke tests”) is running only a portion of the whole suite that runs quickly (say 5/10 minutes for example):

pybot path/to/my_tests/ --include smoke --exclude not_ready

and the second job (“full tests”) launches all the tests:

pybot path/to/my_tests/ --exclude not_ready

but is launched only when smoke tests are run successfully: chain_builds

so if your SUT or your tests have some essential feature (covered in the smoke test) broken, you will save your machine a “full test”, and, more important, the team have a quicker feedback on the quality of the SUT build.


What editor for Robot Framework test cases

Robot Framework home page lists a number of plugins to edit Robot Framework test cases along with Robot’s own editor RIDE. Here is a feedback based on my experience with some of those tools.

RIDE was my first choice four years ago when I started using Robot. We were a team of 20 quality engineers working on Windows machine. Some of us had a technical background and some others were more on the banking business side (we were producing a financial software). RIDE ended up being a good choice, specially for the non-tech people as it hided part of the grammar of test cases: Suite Setup, Tags, Library etc. are all input boxes in a GUI. The ability to launch test cases from Ride was also very handy and kept us away from the command-line (which most of the team was never using). Overall we had a very good experience with RIDE and I would recommend it in a similar context.

TextMate (with its Robot’s bundle) was the editor I switched to when I switched to Mac. There were 2 motivations to move away from RIDE. First one is that RIDE is not very slick on Mac (there are several issues opened for a while) and even install is a bit complicated with WxPython and Python versions collisions. Second motivation was that I joined a more technical company where manipulating the source code of the test was much more frequent (e.g. editing the test case on a remote VM via SSH with vi, merging changes done by another tester…). So I didn’t want anymore to have a GUI layer hiding the source code of the tests. I chose TextMate because it was free, lightweight and worked at once with Robot and SVN. After some time, I started to miss keyword completion and quick access to keywords source code though.

PyCharm is the editor I am using for a couple of weeks now. This time the switch was motivated by some limitation of TextMate (see before) and also by looking over my colleague’s  shoulder who were getting happier and happier with PyCharm. Looks like  JetBrains’s IDE is getting momentum in the Python  community as I hear/read more and more about it. There are currently 2 competing plugins for Robot Framework: Robot Plugin and Intellibot. Both are providing Syntax Highlighting, Code Completion, Jump to Source with some little differences. Best thing is to try them both and see which one fits best.

A side note about this editor topic. when I moved to PyCharm, the amount of syntax checking became one level higher than on previous editor, and I was bothered by the fact that all my TXT files were getting analysed by the plugin (making my non-Robot TXT files uneasy to read). So I changed the extensions of my Robot Test Cases and libraries from .txt from .robot. This way I can configure Robot Plugin to affect only my Robot files and not all the classical text files.