16 September

It's too early to be certain, but ICRA 2019 is looking to be a big one, which is what we expected. The number of submissions to RA letters has exceeded previous records, and the number of regular submissions is climbing (see figure), and there are also a few typhoon/hurricane extended-deadline papers to come later.

The plot below shows submissions coming in, but the absolute number is misleading since it fails to indicate papers in the other input streams.

ICRA 2019 submissions
ICRA 2019 submissions
over time as the deadline approaches,
not including RA-letter and delayed papers
(Click to expand)

By Gregory Dudek at | Leave a comment |    
14 September

Extensions for natural disasters

As the ICRA 2019 deadline was approaching, two natural disasters became apparent: Hurricane Florence and Typhoon Mangkhut. As far as I know, no standard policy for deadlines extensions due to natural disasters exists in our community, and some sub-communities like SIGGRAPH do not make exceptions in such cases. Worse yet, we don't have a good standard mechanism for monitoring such events. This is especially tricky since hurricanes and typhoons are intrinsically unpredictable and people can also get upset when extensions are given out selectively and without sufficient cause. Moreover, broad extensions cause a whole cascade of downstream problems and deadline changes what can have potentially serious repercussions.

In our case in 2018, we first became aware of Hurricane Florence (due to being contacted several days early on by members whose universities announced closure policies) and shortly afterwards developed a policy to provide deadline extensions for those who were experiencing extreme hardship.

Subsequently, we learned of Typhoon Mangkhurt and extended the policy to that event, first informally and then via an official web site update that took some time to propagate.

As this seems to have become a somewhat regular issue and ad hoc methods we used a few year ago when our community was much smaller are not adequate any longer. We will have to develop better mechanisms for world-wide monitoring and adaptation to such emergencies.

By Gregory Dudek at | Leave a comment |    
13 September


Submissions for ICRA 2019 are coming in.

We created a special policy for people and organizations being hit directly by hurricane Florence. Since that is probably not a huge fraction of our community, we opted for a solution that involves a substantial amount of manual intercession and verification.

I looks like the conference will be far bigger that originally predicted back when we made our bid many years ago. Best estimates from our team and our community at large are currently at about 4,000 people, but with quite a lot of variance.

We have repeatedly scaled up our plans and with the paper deadline imminent, we should finally have a solid estimate of how big the conference will be, although it's still hard to know the ratio of attendees to papers.

By Gregory Dudek at | Leave a comment |    
15 July

Why embedded systems like the raspberry pi should not allow swapping to an SDcard

SDcard and Flash memory errors

SD card corruption and eventual failure is common on embedded systems like the raspberry pi. I've realize there is a lack of consistent and reliable information on this. This post describes the problem and provides solutions.

This post has 3 parts: description of the problem, practical implications, and tricks to disable swap on the raspberry pi and related linux devices. People who just want a solution can skip to part 3.


In our lab we have a range of systems from expensive underwater robotics to small embedded IoT devices all of which use SD card or flash memory. There are modes of operation that are acceptable on a normal desktop or laptop that will gradually degrade and eventually destroy an embedded device after a few thousand cycles of writing to a given cell. Since the damage is gradual, it can easy to overlook the cause during setup and testing, and just blame it on "bad memory."

The root issue is that solid state memory wears out with successive changes to the contents, and this happens on a per-memory-cell basis. Modern SD and flash memory have sophisticated internal algorithms for "wear levelling" that try to reduce the impact and extend the life of the chips, but these cannot eliminate the problem totally, since it's intrinsic to the physics of the devices. Hard disks, by the way, can also wear out, but not generally as a function of the read-write behaviour. The key idea behind wear levelling it to change the physical location used for frequently-changing data, to spread the use.
[ Technical aside: As of 2011, 25nm MLC NAND lasted for about 3,000 write cycles. As of 2018 some sources suggest that single level cell NAND (SLC) can last for 10,000 cycles ]

For normal use, only a small amount of the device is written at a time and if this is moved around the device it can be many years before the flash memory storage wears out. Without wear levelling it's easy to write a malicious program that "burns through" a specific cell in just a few minutes (although OS cacheing policies also try to preclude this).

Note that there are differences between expensive SD cards and cheap ones. These differences include both the robustness of the memory elements themselves, their speed and also the nature of the wear levelling (e.g static vs dynamic).

Practical implications

Normal file IO will take many years to damage a modern (wear levelled) flash device. Swapping, however, can be much more destructive. The issue is that swapping is a mechanism used by the operating system to compensate for insufficient RAM (memory) and is depends on writing large amounts of data to "disk", and sometimes doing it a lot. This heavy usage could damage a flash device like an SD card in just a few months.

Note that swapping to a "slow device" will also make the system run slow, but on the other hand in can preclude a hard crash that could occur if the system runs out of memory.

The commands below require root (or prefix each command with sudo).

Turning off swapping

dphys-swapfile swapoff
dphys-swapfile uninstall

and also (to make it permanent):

update-rc.d dphys-swapfile remove

Turn off swapping temporarily

The following two lines work (or npt) depending on the kind of linxu distribution you have (i.e does it use systemd):

swapoff -a

systemctl disable dphys-swapfile

Totally disable the swapping mechanism for keeps

apt-get remove dphys-swapfile

Aside from swapping, you can also make the entire filesystem read-only that preventing any writes (but also limiting the kinds of things you can do).

By Gregory Dudek at | Leave a comment |    
24 June


The International Conference on Robotics and Automation took place in Brisbane, Australia this year. Despite some concerns that the regional robotics community in Australia was smaller than in other regions, the attendance at the conference exceeded any prior year. This is, no doubt, a reflection of how robotics (as well as AI and vision) are growing in significance, impact and relevance.

The industrial trade show that accompanies the academic tracks of the conference was only a small event that had only limited appeal. It has not grown to a major phenomenon with many companies of all kinds participating. This include companies that address leading edge robotics technologies, as well as organizations that use relatively small-scale (yet important) industrial automation. Some of the attendees seeks to advertise and sell technologies, while others focus on attracting attention to better hire new employees or maybe even build partnerships.

With over 1,000 research presentations, it's hard to summarize the diverse kinds of work being done. Field robotics got a fair bit of attention, which aligns well with some of the challenges in the Australian environment, as well as Canada. Rod Brooks gave a great keynote talk which commented on the importance of considered human needs and interactions, while at the same time delivering a stinging critique of classical HRI research. In fact, his critique related to much of the academic community which he felt was overly focussed on obscure or unrealistic quantitative research benchmarks, as opposed to having a greater impact on real-world needs and performance challenges. Rod has defined much of his career by railing against contemporary research trends, which is a great way to get attention. I feel his critique had some truth in it, yet also was a bit too hyperbolic since conducting scientifically valid quantifiable research is critical to ongoing progress, especially as the field matures. Doing stuff that really works in practice is critical, which was part of Rod's message, but it's also important not to use hype and public relations as the arbiters of progress. Anybody who doubts that should just reflect on the Theranos scandal.

On aspect of the conference that provoked a mixed emotional reaction from me was the fact that only a very small fraction of papers could get full-length oral presentations. While reviewing standards have increased and papers were fully-reviewed and generally of pretty good quality, there was simply not enough space or time to allow them to be presented orally and poster-style presentations were the order of the day. This seems like a development that is not likely to be reversed and we are planning something similar for ICRA 2019.

By Gregory Dudek at | Leave a comment |    
13 January

Underwater and surface robotics leaning and mapping the ocean

I am at the 2018 marine robotics field trials and things are ramping up nicely. There are a wide selection of cool projects from several universities including York, University of South Carolina, University of Minnesota and McGill University.

Our own lab is looking at a nice application of inverse reinforcement learning in the context of following divers (such as a marine biologist) and taking optimal photo documentation (such as regions of the reef of interest). We are also deploying an underwater camera to takes footage using similar motivating principles implement in a deep learning architecture.

We start our day at 8am with a morning briefing regarding the day's experiments an the previous days results, successes and challenges. Then we work at sea until dark and do development work and fine-tuning (or more) until late at night. It's exhilarating, but also exhausting.

We have another 5 or 6 applications being fielded.

By Gregory Dudek at | Leave a comment |    

Earlier entries...