If you’re looking for something to do throughout the holidays, the team at BLUEsat UNSW are currently looking for several people to join The Off-World Robotics Software Team! The Off-World Robotics Team is currently upgrading a super cool Mars Rover in preparation for a competition for the European Rover Challenge held in Poland each Year. […]
Entries by Harry J.E Day
Welcome to the next installment in my series on the ROS transform system (ROS tf). In my previous article I explained how BLUEsat’s Rovers all run on the Robotics Operating System (ROS), and what the ROS tf system was all about. In this article I will introduce a number of useful tools and packages that […]
At BLUEsat UNSW, the Off-World Robotics Software Team uses the Robotics Operating System (ROS) as the basis for much of our code. The modularity, communications framework, and existing packages it provides are all factors in this, but another key benefit is its “transform” system. The transform library, which is often referred to as “tf”, provides […]
It’s been another busy month at BLUEsat UNSW. This month’s major achievements include our breakthrough with the steering module of the NUMBAT rover, the creation of a successful SDR radio player in the groundstation team and progress on a new magnetorquer project in the ADCS team! Rover From the Rover CTO It’s been a fantastic Month […]
It’s been another busy month at BLUEsat UNSW. This month’s major achievements include our GreenSat team’s success at the EngSoc pitch fair, and completion of the NUMBAT Mars Rover’s core mechanical construction. Rover From the Rover CTO BLUEsat UNSW has now enrolled in the European Rover Challenge (ERC), commencing in September of this year. The […]
Welcome to our February monthly update, its been another busy month at BLUEsat UNSW. As well as an amazing o-week, our teams have made massive progress across the board. Highlights include our Balloon Team’s launch on the 3rd of March, and major progress in the construction of the NUMBAT Mars Rover. Rover From the Mechanical […]
Welcome to our monthly updates, we are going to trial one of these each month to keep you updated on what’s going on at BLUEsat! January has certainly been a busy time for all of our teams here. Rover From the Mechanical Team Its been a fantastic month of development. Our team finalised the rovers […]
So you’ve written the ultimate ROS program: after thousands of lines of code your robot will finally achieve sentience and bring about the singularity!
One by one you launch your nodes. Each one bringing the Apocalypse ever closer. You hit enter on the last command. And. And, nothing happens. What went wrong? How will you find, and forever squash that bug that prevented your moment of triumph? This blog attempts to answer those questions, and more*.
At BLUEsat we’ve had our share of complicated ROS debugging problems. The best ones happen when you are half-way through a competition task, with time ticking on the clock. Although this article will also look at the more common situation of debugging in a less time pressured, and fire prone environment**.
Below are several tools and techniques that we have successfully deployed to debug our ROS environment.
Keep Calm And … FIRE!
You’ve probably heard this before but its very important when debugging to not jump to conclusions or apply fixes you haven’t tested properly. Google for example has a policy of rolling back changes on its services rather than trying to push a fix. A similar idea applies in a competition or time pressured situation: make sure you have thought through that patch that removes the “don’t kill humans” safety from your robot! That being said, unfortunately a roll back is unlikely to be applicable in a competition situation, nor is it likely to be able to put out that fire you just started on your robot. So we can’t just copy Google, but we should think about what we are doing before we do it.
Basically any patches or configuration fixes you apply during such a situation is a calculated risk, and you should make sure you understand those risks before you do something. During the European Rover Challenge last year I found it was possible to tweak small settings, restart certain nodes, and re-calibrate systems; but it was too risky to power cycle the rover during a task due to the time it took to establish communication. Likewise restarting our drive systems or cameras was very disruptive to our pilot, so could only be done in certain situations where the damage done by not fixing the system could be worse. That being said, after a critical camera failed we did attempt to programmatically power cycle that device – the decision being that the camera was important enough to attempt such a risky move. (In the end we weren’t able to do this during the task, and our pilot managed to navigate the rover without the camera in question.)
In a non time pressured situation you can be more flexible. It is possible to test different options and see if they work. That is provided they don’t damage your robot. However a structured approach is often beneficial for those more complicated bugs. I often find that when I’m debugging an intermittent or difficult to detect problem that it is easy to end up lose track of what I’ve tried, or get results mixed up. A technique I’ve found to be very useful was to record what I was doing as I did it, especially if the problem includes sensor data. We had a number of problems with our Rover’s steering system when we first implemented our swerve drive and I found writing down ADC values and rotation readings in different situations really helped debug it (You can read more about how we use ADC’s in our steering system in one of our previous articles).
Basically the main point is too keep your head clear, and think through the consequences before you act. Know the risks and have your E-Stop button ready! Now lets look at some tools you can use to aid you in your debugging.
So you’ve written the ultimate ROS program: after thousands of lines of code your robot will finally achieve sentience and bring about the singularity! One by one you launch your nodes. Each one bringing the Apocalypse ever closer. You hit enter on the last command. And. And, nothing happens. What went wrong? How will you find, […]
At the start of semester we ran a number of seminars on different skills that we use at BLUEsat. In the first of these videos, former Rover Software Team Lead, Harry J.E Day went through an introduction to “the Robotics Operating System” (ROS) covering setting up ROS catkin workspaces, and basic publishers and subscribers. You […]
In our last article, as part of our investigation into different Graphical User Interface (GUI) options for the next European Rover Challenge (ERC) we looked at a proof of concept for using QML and Qt5 with ROS. In this article we will continue with that proof of concept by creating a custom QML component that […]