About 4 months ago, before graduating from high school, I joined a college robotics team that is developing autonomous robots. My mentor had already built an autonomous robot in ROS, and so he has helped me learn ROS up to a point where I feel fairly comfortable with it. I still have a lot to learn of all the tools, but it has been really cool learning about how the systems in ROS take place.
Recently, I have decided to completely change the structure of how each of the packages and nodes communicate with each other. In the process of doing this, I have run into problem after problem after problem. This is to be expected with code, and it eventually get fixed. However, I’m wondering if these stumbling stones will continue to be there future, if it is just the nature of big software projects like this, or if I just keep on taking particularly difficult processes to accomplish.
I realize that this might be a little bit off topic, but I wanted to write something after being on here for a while. I guess I just couldn’t think of anything else.
To some degree, that is the nature of any system. Probably even more so with systems that include software. As the system grows in complexity from “simple prototype to test an idea” to “something we want to use” to “something we want others to use”, complexity goes up and shortcuts taken in earlier stages have to be replaced with robust solutions.
Robots are complex systems, and ROS introduces some additional complexity in how you architect your software (you get benefits that we believe make the additional complexity worth it). As your robot grows, you need to expect to encounter and solve additional problems.
However, you will also grow in experience and knowledge. This will mean that you will avoid some potential problems before they occur, based on past experience, and other problems that do crop up, you will be able to solve faster. This doesn’t mean that eventually you will never encounter problems, though. What will happen is that your initial “simple prototype” starting point will grow to be more complex than even what you would have considered a “complex” system in the past, which means that you will encounter and solve even more complex problems.
That makes a lot of sense @gbiggs. Thank you for the quick reply! As I started with ROS I knew that it was complicated, but now I actually understand how complex this kind of system can get. And designing a system that is big and complex takes a lot of mental processing, research, and time.
Speaking of designing a system in ROS, I’m wondering if you can give me a couple tips on a over-arching document on how I’m going to design all of it linked below.
In that diagram, I use a field_state_tracker to keep track of all of the objects around the robot whether the objects are coming from Gazebo, or the actual robot. I am wondering if rather than creating my own very simple object tracker of if I should use something built in like tf to keep track of all the states.
The problem that I see with using tf (from the limited research that I have done) is that it is oriented towards keeping track of the change in position, rather than the actual position. So using it would mean that it would be more computationally heavy than using something of my own design. Just a thought
Edit: I realize that the diagram doesn’t have all the information needed to fully understand every part of it, and if my question doesn’t make sense let me know and I would love to explain.
@acetousk Can you talk some more about what your robot will be doing? I think that providing as much context as possible will help people understand your node diagram. (Pictures are great too!)
I’d suggest using built-in tools as much as possible. It will make it easier to bring in 3rd-party packages to add extra functionality you might need, and you’ll benefit from using these robustly tested and maintained open-source packages over rolling your own. Using tf in particular would definitely be a good move, since many perception, visualization, and motion planning packages already use it to represent the relationships between the robot and rigid objects in its environment.
I will say that as you get older and do more projects your mindset changes a bit from things being “difficult” to being “challenging.” I think most senior engineers enjoy projects that are challenging. Frustration often arises when there are problems and you are unclear how to address them.
If you’re having ROS related issues we generally suggest answers.ros.org as the place to get your specific questions answered. If you’re changing your system architecture and running into a lot of stumbling blocks it usually means your nodes aren’t loosely coupled. Building, small, self-contained, and re-usable components should be the goal of any engineer.
When I coach students I generally suggest that they try to make small steps in the direction of a working system rather than trying to get the whole system running in aggregate, all at once. For example, if you have some sort of mobile base, make sure you can move that around. Get that aspect of the robot working flawlessly. Make sure you have strong test suite so if you do make changes to that subsystem you can re-certify its functionality. Once you have a mobile base subsystem locked in move on to the perception aspects of the robot, and repeat the process. It is much easier to debug a robot when you work logically through the subsystems and are fairly confident that the thing you are presently building is the root cause of your errors.
@schornakj yeah of course! The robotics competition that I’m competing in called VEX Robotics. Each year there is a different game on a standardized 12 by 12 foot field. There are game objects that the robot manipulates to score points. There are two teams controlling two robots and whichever team has the most points at the end wins.
This year’s game is to score balls in the cylinder goals for points. Here is a video of the field in gazebo. This is an example of a robot that another team made.
In my diagram above, there are five nodes marked by color. The controller node provides the default state of all the objects in the simulation. This is mainly used at the start of the runtime to take in or to reset the objects position data. This system has to factor in using a real (robot package) or fake robot (simulation package). It also needs to take in data from either of the packages, process the data, and feed out the data to either of the packages. To keep that more simple than it sounds, the controller publishes an Int for all of the nodes to determine what state the system is in: simulation, robot, or resetting the data. There is also a bool that when true, it will stop the entire system for safety.
The detection package’s purpose is to take the encoder, IMU, pointcloud, object position data, etc and convert it so that there is one central node for querying and updating the positions of all the objects.
The driver package’s purpose is to take the state of all the objects around it, decide what the robot should do, and then actually controls the robot. It also makes sure that while the robot is set to complete a goal, it has conditions based off of the feedback on whether to change the goal or continue with the current goal. This part of the system is the part that I have spent the least amount of time on. I need to come up with a set of Actions that will use the drive, the ball intake, and other systems asynchronously while still ensuring that the odometry sensors update and it continues on it’s current task. I have gotten the ROS navigation stack working, by setting a goal pose in RVIZ, but I haven’t found a good way to use something like actionlib with the navstack and my code for that (if it’s even necessary…).
I often think of the problems as being challenging rather than difficult. It’s just there are so many complex and difficult challenges in a row that make it feel more difficult than challenging.
I realize that the nodes need to be loosely coupled, and all those things. It’s just difficult to make it so that each of the nodes are loosely coupled when you want to use the same system for both a simulation and an actual robot. Each node where a topic can be from either the simulation side or the robot side makes it even more complicated.
Maybe I could just have two different systems that reuse the same packages? idk I feel like that wouldn’t help…
These are all excellent points. I wonder if rather than thinking of the nodes connecting to each other as a loop, thinking of it as a node to get working on it’s own as much as possible.
Have you taken a look at similar systems? The joy of open source software is that you can learn from how other people constructed things. Once in a blue moon you can even reuse that software on your robot.
We just released a really good set of tutorials for the SubT challenge that walks you through how to use Cartographer along with Darkent to perform SLAM, navigation, and object detection. Running through those tutorials and looking at the high level node architecture would probably be really instructive. I don’t know what the open source rules are for VEX but I think you would be fine using an outside package like Cartographer or NavStack. I know there are no issues using those packages for something the size and scope of SubT.
As to your simulation vs real problems, something smells a bit fishy. Are you using different message types for each case? Are the data types different between real and simulation? I think if we could see your code we might be able to make suggestions. There’s probably an easier way to do what you are attempting to do. Generally with software if something feels a bit awkward and convoluted it is a sign that you are not approaching a problem in the right manner. When you feel this happening it can be helpful to step back a bit and review the documentation / look at examples.
ROS actually simplifies robot software by a factor of at least 10X. Just try creating a robot that can do basic navigation all by hand.
What you want to do is avoid the usual beginner idea that “this is too complex, so I will redo everything myself from scratch.” Then you spend the next 300 years of you life reinventing wheels and never finish.
What is complex is creating interesting behaviors that are not “brittle” and can handle the real world
The best way to handle the problem is “nothing works” is to make only incremental changes then test, make another change then test again. Don’t re-organize everything at once. You should be testing AT LEAST as much as writing new code.
While true (to a certain degree), I can imagine the proponents of this new-fangled high-level programming language C (and later C++) said the same thing to people about using (an) Assembly language
Yes, ROS does help putting together a robot software architecture, but it does trade complexity for other complexity. Especially for systems which could conceivably even be controlled by a single Python script (and I’ve seen some pretty creative programming in the Lego First and similar leagues), introducing something as complex as ROS and then stating it will help get things done faster will require more than just stating it .
I often introduce ROS to novices by saying “ROS doesn’t have a learning curve, it has a very steep learning cliff.”
There are prerequisites that include a thorough understanding of Linux, preferably Ubuntu from the CLI, math including geometry, and trig, at least one programing language, preferably Python. Furthermore for actual robots, physics, mechanical and electrical engineering, Unix system admin, and I sure I’ve left a lot out, like how sensors and actuators work, interfacing, hardware drivers etc. Etc.
So if you can’t afford a turtlebot, see of you can modify a Roomba or a Neato botvac to a basic platform, alternatively use various simulated robots in RVIZ and Gazebo to learn the basics. Find a user group, you will find many people willing to help. We all were beginners at one point.
Hi, I will say I’m just starting to learn myself, and I hear you! I’ll also second the opinions of @Katherine_Scott and @Chris_Albertson that the large trove of existing open source projects using ROS can be a big help.
My suggestion when in doubt is to see what the most similar things are to what you are doing and see how easy it is to remix and stitch them together. When you work backwards from the actual thing you are imagining to build, and stop worrying too much about the parts you don’t understand, it becomes much more fun. At least that’s how it is for me anyway.
.