More scope questions

[Bill Smart]

Colleagues,

I wanted to see if we could get some opinions on other aspects of the
scope of our initial goals. It seems that the infrastructure stuff is
well underway at IHE and Yujin, so I wanted to turn to the other
content. For the purposes of discussion, I'm going to assume that
we're aiming at a bootable USB stick with Ubuntu and some complete
version of ROS on it (although I know that it's completely finalized
yet). With that said, the following questions occur to me:

What else is going to be on the stick?
I'm assuming ros-desktop-full, and all of the supporting packages. Do
we want to specifically include other things like:
- eclipse, or some other IDE
- specific editors and other tools
- specific python (C++) packages
While people can install these on their own, there is some utility for
having them pre-installed. Of course, the question is where to draw
the line. One way of dealing with this would be to include
instructions for downloading other packages, and a list of
potentially-useful ones. I will note that people coming from a
computer science background at many universities will be used to an
IDE, and I think that including one (eclipse might be a reasonable
choice) would be useful.

What documentation and tutorials will we include (and include support for)?
Do we just make sure that the introductory tutorials on the wiki work
as advertised, or do we include some other material? Personally, I
favor the former, because it's a smaller initial step.

What platforms do we target?
Simulation only, or include turtlebot? Old turtlebot and new
turtlebot? If we include real robots, do we address networking
issues? This might be a thorny problem in many university
environments (with strong, inflexible firewall policies). Do we
assume that we have direct access to the computer on the turtlebot?

What sensors?
This might be subsumed a bit by the answer to the previous question.
Do we deal with the kinect? Other sensors?


There are probably several other questions to ask but, hopefully, this
can get things started.

cheers

-- Bill

[Jonathan Bohren]

Another thing is lecture materials. I've put together some crash course slides for a one week intro, but they definitely don't cover everything. Does anyone want to set up a common repo (git or hg where we could keep them and branches?

There is a ton of documentation online along with many tutorials, but I think something that needs to be done is to define a causal path through the scope of the things we'd want to cover in a course.

Another thing that's been on my mind lately is teaching good debugging skills. Since the usefulness of ROS is predicated on using code written by other people this means that it's very likely that ROS users will need to fix code written by other people. One interesting assignment could be to have some broken ROS code (either wrong behavior or so it crashes ) that the students are unfamiliar with, but have to figure out what's wrong and fix it in a certain amount of time. This could be a good candidate for a take-home exam. There ccould be multiple bugs each with different values to male it easier from a grading perspective.

--
You received this message because you are subscribed to the Google Groups "ROS Education Special Interest Group" group.
To post to this group, send email to ros-sig-...@googlegroups.com.
To unsubscribe from this group, send email to ros-sig-educat...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Piyush]

On Tue, Jul 24, 2012 at 12:13 AM, Jonathan Bohren
<jonatha...@gmail.com> wrote:
> Another thing is lecture materials. I've put together some crash course
> slides for a one week intro, but they definitely don't cover everything.
> Does anyone want to set up a common repo (git or hg where we could keep them
> and branches?

+1. Would it make sense to have a private repository (to store
asssignment solutions etc.), or have a publicly visible one?
Additionally, would it make sense to setup a few pages on the ROS wiki
for common information for the students, for instance a
troubleshooting guide (see below)?

>
> There is a ton of documentation online along with many tutorials, but I
> think something that needs to be done is to define a causal path through the
> scope of the things we'd want to cover in a course.
>
> Another thing that's been on my mind lately is teaching good debugging
> skills. Since the usefulness of ROS is predicated on using code written by
> other people this means that it's very likely that ROS users will need to
> fix code written by other people. One interesting assignment could be to
> have some broken ROS code (either wrong behavior or so it crashes ) that the
> students are unfamiliar with, but have to figure out what's wrong and fix it
> in a certain amount of time. This could be a good candidate for a take-home
> exam. There ccould be multiple bugs each with different values to male it
> easier from a grading perspective.

+5. I teach freshmen undergrad students, so the debugging skills I
taught them were pretty basic (how to run gdb... etc.). At the same
time, I would love to have a comprehensive list for troubleshooting
common problems somewhere. Here are a couple of examples:
1) Included header files are missing
-- correct ROS package has not been introduced in manifest.xml
-- (unlikely) ROS package providing library missing export statements
2) Linking errors
-- forgot to link to system libraries explicitly (even if mentioned
in manifest.xml)
-- (unlikely) ROS package providing library missing export statements

> On Jul 24, 2012 1:31 AM, "Bill Smart" <sma...@engr.orst.edu> wrote:
>>
>> Colleagues,
>>
>> I wanted to see if we could get some opinions on other aspects of the
>> scope of our initial goals. It seems that the infrastructure stuff is
>> well underway at IHE and Yujin, so I wanted to turn to the other
>> content. For the purposes of discussion, I'm going to assume that
>> we're aiming at a bootable USB stick with Ubuntu and some complete
>> version of ROS on it (although I know that it's completely finalized
>> yet). With that said, the following questions occur to me:
>>
>> What else is going to be on the stick?
>> I'm assuming ros-desktop-full, and all of the supporting packages. Do
>> we want to specifically include other things like:
>> - eclipse, or some other IDE
>> - specific editors and other tools
>> - specific python (C++) packages
>> While people can install these on their own, there is some utility for
>> having them pre-installed. Of course, the question is where to draw
>> the line. One way of dealing with this would be to include
>> instructions for downloading other packages, and a list of
>> potentially-useful ones. I will note that people coming from a
>> computer science background at many universities will be used to an
>> IDE, and I think that including one (eclipse might be a reasonable
>> choice) would be useful.

I would recommend placing only those packages that are reasonably
large (or have large dependencies). I suspect it is unlikely we'll
ever have a situation where no downloads will be necessary.
Consequently we can try and reduce the time required for a complete
installation. I am ambivalent to the choice of IDE, all grad students
in my lab (including myself) end up using vim or emacs.

>>
>> What documentation and tutorials will we include (and include support
>> for)?
>> Do we just make sure that the introductory tutorials on the wiki work
>> as advertised, or do we include some other material? Personally, I
>> favor the former, because it's a smaller initial step.

Introductory tutorials sound fine.

>>
>> What platforms do we target?
>> Simulation only, or include turtlebot? Old turtlebot and new
>> turtlebot? If we include real robots, do we address networking
>> issues? This might be a thorny problem in many university
>> environments (with strong, inflexible firewall policies). Do we
>> assume that we have direct access to the computer on the turtlebot?

At UT, we ask our sysadmins to setup a private wireless network for
robotics courses. In such a situation, we assume that students have
full networking control, and direct access to the robots. I wonder if
the same is possible elsewhere.

>>
>> What sensors?
>> This might be subsumed a bit by the answer to the previous question.
>> Do we deal with the kinect? Other sensors?

I recommend throwing in all the main ROS driver packages. I think
there is a list on one of the earlier threads on this mailing list. I
don't see a space issue being a major problem.

Piyush

[Bill Morris]

Our current focus is the TurtleBot install but we are happy to discuss
anything else anyone may need.

Here is the current documentation we will be shipping with the
TurtleBots.
https://github.com/TurtleBot-Mfg/turtlebot-doc-fuerte
https://launchpad.net/~iheartengineering/+archive/ros-support

If we can package the .edu documentation as a Debian package it will
make adding it to a ROS Workstation USB drive easier.

It is our belief that the most common setup will be a WiFi router with a
firewall for the robots with ethernet access for workstations. This
setup may or may not have internet access. At some point in the future
we may offer the robots with a preconfigured WiFi router running
Open-WRT.

We are looking at enabling Zeroconf to speed up the out of box
experience. In the future we would like to build some management tools
to provide a webpage where you can check on the battery status of a room
full of robots using rosjs running on the Open-WRT WiFi router.

For the TurtleBot ISO we are currently at 1.3GB out of 2GB, so we have
room for a few more packages. Also, if we uninstall things like Libre
(Open) Office we can save some more room.

--
Bill Morris <bi...@iheartengineering.com>
I Heart Engineering
http://www.iheartengineering.com
<3