The New Robot - Githubissues

So, this is more of an announcement more than an issue, but I figured that this would be the easiest way to break the news to everyone.

The current team, as a whole, has decided that the best way for us to move forward is to do a complete redesign of the robot, hardware and software. There are several reasons this decision has come about.

There was kind of a schism in the team between those that wanted to continue Tortuga and those who wanted to start a new project, like restarting the ground vehicle team or even participating in an aerial robotics competition. Those who chose the latter felt that they were just maintaining the old robot instead of contributing anything new. However, due to our limited manpower and budget, we knew that splitting off would ultimately doom both teams, and we couldn't completely abandon AUVSI since that would upset many of our sponsors. Thus, we decided that this would be a good compromise.
For this year, mechanical team and electronics team wanted to upgrade the computer from the Mac Mini to something more powerful. However, the main hull on Tortuga would not accommodate the new computer. As such, mechanical team is redesigning the main hull, as well as adding external battery hulls (so we can actually charge the robot at Transdec). Also, there were several hardware additions that we wanted to make that wouldn't fit on the vehicle in it's current state, like a forward grabber for the new manipulation tasks. Essentially, we had hit the limits of what we could put on Tortuga hardware-wise.
On the software side of things, there were several hurdles that were preventing any of the new members from being able to actually do anything. The most notable hurdle was installing Ubuntu 10.04 or 10.10. Some people with newer laptops couldn't get their wifi OR ethernet ports to work, meaning they were cut off from the internet entirely. Basically, all of last semester was spent trying to get people's laptops working so they could actually code. I'm surprised some of them stuck around as long as they did. And, on top of that, the new computer for the robot is a 64-bit architecture, which means the codebase won't work in it's current state anyway.

So, given all of that, we decided it was time to redesign everything. But that by no means means we are starting from scratch. Our new software design is mostly based on the old design structure-wise, and we are still planning on using snippets of the old code where applicable. However, there are going to be many changes:

First off, we will be switching to Xubuntu 12.10 on the robot, which doesn't use the Unity interface and runs faster than the latest version of Ubuntu (as well as using less CPU and RAM). Apart from that, they're pretty much identical. Nick was a big proponent on this one, and it turned out to be the better choice anyway.

Secondly, we are going to be using ROS as the core of our code, which will free up some of the time we would have to spend redeveloping the core systems for the new computer architecture (since we have less than 6 months at this point). We've already laid out what subsystems we'll need, and our current plan fits in nicely with how ROS's architecture is set up.

We'll still be using the same C++/Python split that the old code did, since ROS primarily supports both languages. We will be using OpenCV for the vision of course, and may be using OROCOS for simulation and physics calculations (Eliot is looking into this one). We're still looking for a good Python & Linux compatible 3D graphics library for the simulator, so if you have any suggestions, let me know (If we have to, we'll use Ogre again).

As for the build system, ROS plays really nicely with CMake, and even has tools to generate CMakeLists for us, so we'll be using that unless we find some overwhelming reason not to (I'm looking at you, Sternberg).

On top of that, we're going to try and document all of our progress as much as possible, so new members can simply look at that instead of having to pry apart the code themselves. Pretty much everyone on the team agreed this was a necessary endeavor.

Overall, though, everyone is eager to work on the new system, and we've already made progress on the new design. We've got 5-6 people including me to do software, with one person even having experience doing computer vision. Unfortunately, Eliot is still the only controls person, but we're still looking for people to help him out. It'll be tough to get everything done, but we can do it.

However, things are still very much in the planning stage. As such, if you have any input you would like to provide to the design process (complaints about the old system, suggestions), I would be more than happy to hear them. One of our goals for this redesign is to not redo mistakes from the old code, so if there is anything that should be fixed right off the bat, let us know.

From a controls perspective, one of the most important things to get right is the mechanical design. If there is a lot of asymmetry in the profile, mass distribution, etc, it will cause problems for the simpler control algorithms and make it much harder to design a control algorithm that will work well. On the other hand, if you get those properties right, there is a decent chance that the existing PID controller for depth and translation as well as the nonlinear PD controller for rotation will work pretty well.

First of all...

First off, we will be switching to Xubuntu 12.10 on the robot, which doesn't use the Unity interface and runs faster than the latest version of Ubuntu (as well as using less CPU and RAM).

Oh god NO! Do not even consider this. Use the server edition of Ubuntu 12.10 and use 64-bit. Do not install a graphical user interface on the robot. It can't afford it and it makes the code more error prone. Do not install anything other than the bare minimal.

For your own laptops? I suggest Linux Mint (which is based on Ubuntu) or using Xubuntu 12.10 on the developer's laptops. Nick is full of shit on this one. You should make sure that people are using the same software sources for their development computer as the one the robot will use.

Now be very careful. You'll pretty much be able to take the controls and possibly the vision code and re-use it. That may not be the case with the vision code, since it uses a lot of the old OpenCV API. You may want to play take and leave. Don't be afraid to throwaway code.

Decide what you want to do. Do you want to have a core that gets reused between AGV and AUV? If so, have a core library (decide on a name). Get this stuff up on GitHub ASAP. That's the only way a lot of us will be able to give you feedback.

I'm personally not a big fan of ROS, but I didn't delve into it that much. If I were looking at something, I would likely choose to use ZeroMQ for interprocess/network connectivity and possibly use JSON as a serialization and communication mechanism. Then I would likely use waf for the build system, since I think it's faster and cleaner than CMake. I think it also gives a lot more freedom than CMake. My experience with CMake is the current build system, which considering I wrote those CMakeLists files, you should understand when I say, "I can't make modifications to the build system anymore." It takes me hours to change things in there.

I would make each subsystem a separate process. I haven't thought exactly how good this communication would be though, as I haven't completely thought things out.

Add the flag -std=c++11 immediately to the project. Understand move semantics and use unique_ptr very liberally, and shared_ptr occasionally. I would avoid writing wrappers and just use IPC for communication between Python and C++.

Avoid boost. It's really not worth keeping around for all the pain it causes in deployment and new bugs. The primary reason to use boost would be Boost.Python, Boost.DateTime, and the boost shared_ptrs. If you use C++11, you get DateTime and the shared_ptrs as part of the new standard library.

I'll have more to say later, but I really just needed to respond immediately to stress to not use Xubuntu 12.10. The GUI is not a factor for the robot itself.

Wonders: From what I can tell, mechanical team is making sure the robot is as symmetrical as possible, and balancing the weight on either sides when they cannot.

Sternberg: Point taken. I'll look into Ubuntu 12.10 server edition. Thanks for the heads up.

Also, each subsystem is already a separate process in our design. This is one of the reasons we were going to use ROS, since it has built in interprocess communication through the use of messages and services. Honestly, after looking at ROS a bit more, there might be some limitations that would be annoying. I'm just not sure what would replace it yet. I'll take a look at ZeroMQ to see if it has what we need.

As for the build system, I'm sure we could probably use waf with ROS, it's just that it would mean a little more work. But if it's worth the effort to avoid the pitfalls CMake has, I'll give it a try.

I agree with Sternberg that a minimal server version of ubuntu should be put on the robot.

I do not have the same hatred of boost that Sternberg does. If we didn't have custom patches and try to abuse serialization, it would not cause any problems for deployment. I'm not sure what you mean by new bugs. C++11 should certainly be preferred to using boost, but even in C++11 there is no good support for file system operations. Also, the statistical distribution library is very good. Boost is a nice library to have around in order to avoid reinventing the wheel over and over again.

If there are good alternatives, I'd love to hear about them.

I just looked at ZeroMQ and it looks pretty cool. I might play around with it for some things I'm doing at work. I don't know much about ROS, but it seems like the main thing that you would be getting out of it is the IPC.

I also don't understand why CMake would be unmaintainable if IPC is used instead of generated wrappers.

I think the new direction is great. You really need to make the project your own in order to have the passion to put the effort needed.

You made the right choice with ROS here. It took myself and the previous team over a year to build out the first version of the R@M infrastructure software. By sticking with ROS you can get a more capable system out of the gate. You also can avoid all this bike shedding (bickering over small details) about Boost vs. C++11, CMake vs. waf, etc. ROS makes those decision for you: Boost & CMake. Now you can get on with making a robot, so some specific advice:

Simulation

I would look into the existing ROS based Gazebo simulator. It might be possible to simulate what you want with only a little bit of custom coding. Calculating buoyancy and drag forces are pretty simple, especially if you just model the robot as a box or cylinder. Maybe all you need is a simple plugin which applies those forces to a robot.

Starting from scratch?

You don't have to throw out everything, really. With only a little work you could take the less dependency laden subsystem like Controls, Vision and Sonar use those until you have better ones. With ROS it's as simple switching out binary you start up. This will let people working on other subsystems have something to start with. (I make no promises, but it would be fun to port that stuff forward).

Sonar

The crown jewels. If possible, also keep this around until you have a better electrical and software solution. Most teams never actually get a working one, ever.

In the future I recommend you start a mailing list (or use the existing ones), for design discussions.

P.S - My day job is robotics software development with a focus on infrastructure software, so I have some "real world" experience working on this stuff now.

Thanks for the advice! I'll definitely look a bit more into Gazebo since it looks like it can do 3D, which was the main hurdle we were trying to overcome. And yes, I'll try to swap in as much of the old code as possible; we don't have a whole lot of time and probably won't be able to rewrite everything.

robotics-at-maryland / tortuga

The New Robot #10