tag:blogger.com,1999:blog-33067220096863528482024-03-05T00:59:39.738-05:00Killer Robot Penguins!I, for one, welcome our adorable new overlords.Anonymoushttp://www.blogger.com/profile/08217348593509965840noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-3306722009686352848.post-24914575153510018102013-01-20T16:27:00.000-05:002013-01-20T16:27:20.477-05:00Weekend Project: Setting up MythTV on Fedora 18<h2>
Preface/Motivation</h2>
I have had a Windows 7 based media center PC sitting in my living room for the last few years. Its primary function was to run Windows Media Center, where it recorded and played TV shows using a Ceton Infinitv4 CableCARD tuner, and played back music and videos from rips of my DVDs. <br /><br />It has always worked well enough that I wasn't driven to throw it out the window, but over the last year or so it began to act up. It was taking longer and longer to become responsive after a cold boot (something like 10 minutes at the worst,) and even starting Media Center was a four or five minute ordeal as it hung with a spinning blue circle, presumably trying to access the file server sitting next to it. And over the past couple of months it started freezing, blue-screening and even hard-locking under load, indicating some kind of hardware issue. <br /><br />The computer was put together in 2007 as my main workstation, and had an Athlon-X2 5200+ with 6 gigs of RAM and two 320G Seagate hard drives. Since then it's made a transition to a media center PC, as I use my laptop for most of the work I have to do. Since the system has been so unstable, and because I'm no longer a poor college student, I decided it was time for an upgrade. Of course, a hardware upgrade means that my Windows installation has a pretty good chance of falling on its face and never recovering.<br /><br />I've been using Fedora exclusively on my laptop, and decided that I wanted to try to switch to a Linux-based solution for my media center setup as well. I really didn't feel like going through the Windows 7 re-install/endless upgrade dance after updating the hardware. And although Windows Media Center always mostly worked, it was never overly impressive. Windows Media Center always seemed like a second-class citizen to me. It was quirky, hung a lot, never seemed to get any updates, and its future is pretty bleak considering Windows 8 doesn't include it at all. I also did some preliminary research on the capabilities of mythtv with my tv tuner, and it looked like it was possible to do everything I was doing with Windows Media Center with mythtv. So Fedora 18 it was, and my little weekend project took shape.<br />
<h2>
Disclaimer</h2>
This is not a step-by-step setup guide for MythTV. Plenty of those already exist on the web, and I'm not nearly knowledgable enough to write my own. This is a description of what I managed to set up with my new PC build, the gotchas I ran into along the way, all written from my recollection after the fact. Hopefully it can fill in some gaps in the available online documentation, and give an insight into what it's like for a somewhat savvy user to set up a mythtv based media center. <br />
<br />
<h2>
New Hardware</h2>
The new system I'm setting up has the following:<br />- Intel i7 3770K<br />- Asus Maximus V Formula motherboard<br />- 32G Corsair Vengence DDR3 RAM<br />- Radeon HD 6450 (fanless)<br />- 850w Corsair PSU<br />- 128G OCZ SSD<br />- 2x 320G Seagate Hard Drives<br />- Ceton InfiniTV4 CableCARD PCI-e tuner<br />- USB Windows MCE Remote Receiver<br />
<h2>
Setup</h2>
<h3>
Fedora Installation</h3>
Installing Fedora 18 was pretty straightforward once I got the new system put together. I booted the Desktop Live image off of USB, and immediately clicked the Install to Disk option in the startup dialog. I was happy that I got an opportunity to see the new Anaconda installer UI, and I really like where they're going with things.<br /><br />The only hang-up I had was in the disk partitioning screen. I managed to figure out how to get Anaconda to use a standard layout using ext4 (no LVM or brtfs) but the option to preview the partition layout seems to be gone. I decided to trust it anyway. It assigned 500M to /boot, 50G to /, and the rest to /home, which I'm happy with. The rest of the installation was uneventful, and after reboot and going through firstboot I had a working Fedora 18 system.<br />
<br />
<h3>
Hardware Setup</h3>
Fedora doesn't enable TRIM support by default on SSD hard drives. To do so, go into /etc/fstab, and add "noatime,discard" after "defaults" for all of the entries that are partitions on your hard drive (/, /boot, /home, and swap)<br /><br />Mythtv uses a local disk as a buffer for live tv viewing, for pausing and rewinding live tv. I didn't like the idea of it being on my SSD, so I set up one of my hard drives to auto-mount under /media/localstorage. This hard drive happened to perform a similar function under my Windows setup (it just held TV recordings,) so I created a fstab entry using the UUID (found with blkid.)<br />
<h3>
Software Installation</h3>
I did a system upgrade to install all of the updates, then installed mythtv, mysql, the @development-tools group, and kernel-devel and kernel-headers. <br />
<h3>
Ceton kernel driver</h3>
Ceton provides a Linux driver for their tuners on ther support site. I downloaded the source, and followed the installation directions in the README. The ctn91xx_* devices showed up in /dev, and everything seemed just peachy.<br />
<br />
<b><i>GOTCHA!</i></b><br />
Ceton provides a udev rule that forces their devices to show up in a subfolder of /dev, /dev/ceton. It does this by changing the NAME attribute. Unfortunately, Fedora's udev doesn't allow for changing the NAME of block devices, so a warning is printed and the devices are created in /dev. Annoying, but an easy fix. You can change NAME="ceton/%k" to SYMLINK="ceton/%k" in /etc/udev/rules.d/98-ctn91xx.rules. This will cause udev to create the devices in /dev, and provide symlinks to them in /dev/ceton. This is important: as I found out later, mythtv is hard-coded to look in /dev/ceton for the ctn91xx devices.<br /><br />After the ctn91xx module is installed and loaded, you should see that NetworkManager has a new Ethernet interface, and its IP address will be on the 192.168.200.xxx subnet. At this point navigating to 192.168.200.1 in a browser will show the Ceton card's web interface.<br />
<h3>
Mythbackend</h3>
Now it was time to set up the mythbackend. Following the directions on MythTV's website, I set up the MySQL database. Then I enabled it using systemctl enable mysqld.service, and starting it using systemctl start mysqld.service.<br /><br />The next step was to run mythtv-setup and set up each of the categories.<br />
<br />
Under the General tab, the only change I had to make was to switch the local and master backend IP addresses from 127.0.0.1 to the IP address of the machine.<br />
<br />
<br />
Under Capture Cards, I set up four individual cards using the Ceton Cablecard tuner card type. Each has an ip address of 192.168.200.1, and a card number of 0. The four capture cards each have tuner numbers from 0 to 3.<br />
<br />
<br />
The video sources is the next menu option to work with. I added a new video source using the SchedulesDirect DVB service (and forked over some cash for a subscription). This service lets you pull down all of the channel listings and guide information for your area.<br />
<br />
Under Input Connections I selected each tuner and chose the Schedules Direct video source. Then I selected Fetch Channels from Listings Source to get a valid channel list for each tuner. I didn't adjust any of the rest of the settings.<br />
<br />
Finally, under Storage Directories, I selected each of the available groups and entered a file path for storage. I selected a path in my /media/localstorage mount set up earlier so that the storage and caching won't happen on my SSD.<br />
<br />
<b><i>GOTCHA!</i></b><br />
If you're going to be running mythbackend as a system service (e.g. systemctl start mythbackend.service), then that process is going to be launched under the "mythtv" user. As such, all directories under Storage Directories need to be writable by the "mythtv" user. Once you decide where you'd like mythbackend to store its files, you'll want to use chown and chgrp to assign ownership of the storage directories to the mythtv user and group. If you'd like your login user to be able to edit and remove files, you can add your user to the mythtv group.<br /><br />After everything was done, I set mythbackend to start on boot using systemctl enable mythbackend.service, and started it using systemctl start mythbackend.service. Then I ran mythfilldatabase, which pulled tv listings from SchedulesDirect without any issues.<br />
<br />
There's definitely a lot of other stuff you can adjust in here in terms of recording and transcoding profiles. It's ok to ignore this stuff as everything is getting set up, but I'll definitely be digging into it after basic TV viewing is working well.<br />
<h3>
Mythfrontend</h3>
With mythbackend running, I can start mythfrontend and hopefully watch Live TV. I got the TV working, but there wasn't any sound...<br />
<br />
<i><b>GOTCHA!</b></i><br />
My PC is hooked up to a 5.1 channel receiver via HDMI for audio and video. The video part obviously works fine, but audio wasn't. I tried to open the sound settings and set the default output device to the radeon HDMI output, but there was no entry in the devices list. It turns out that the radeon driver disables HDMI audio by default. After adding "radeon.audio=1" to the kernel's bootargs, the device showed up in the list of output devices, and audio output started working properly. Yay! To make this permanent, I edited /etc/default/grub and added to the end of the list of bootargs.<br />
<h3>
Remote xbmc</h3>
Feeling smug with my problem solving skills, I decided to push my luck and try to set up xbmc on my laptop to stream live TV. I fired up xbmc, went to the settings->Live TV, and enabled live tv. Then I enabled the mythtv addon as the livetv provider, and configured it with the IP address of the backend. After doing so, I was faced with a bunch of pop-ups complaining that connecting to the PVR server failed.<br /><br />
<i><b>GOTCHA!</b></i><br />
Now I'm on a remote computer, so I need to open up some firewall ports on the backend system to connect to mythbackend and mysql. Fedora 18 uses a new firewall-config program instead of system-config-firewall, so I had to figure out how to open up some ports in the new program. First, I selected the "home" zone, and switched the Current View dropdown to Persistent configuration. I clicked on the "Ports" tab, and added 3306 (mysql,) 6543 and 6544 (mythbackend.) For the "home" group settings to work, the network interface for my LAN needed to be set to use the "home" group. After going to Options->Change Default Zones of Connections, I selected my network interface and switched the firewall zone under the General tab to "home". <br /><br />After setting the firewall properly, xbmc pulled the channel list from mythbackend, and the Live TV options worked! Hooray, now I can watch Iron Man 2 on FX in the kitchen while I'm cooking dinner!<br />
<h2>
Conclusion</h2>
The mythbackend with mythfrontend/xbmc setup is already light years beyond the capabilities Windows Media Center provided. I can watch, record, and transcode live TV, and now I can stream it to remote PCs and use multiple frontend clients. Unfortunately, setup was still a little bit bumpy. I'm not sure a newbie could have figured all of this out inside of 6 hours.<br />
<br />
I'm excited to play with the functionality I've thus far skipped over (tv recording and automatic transcoding, commercial skip, etc.), get my MCE remote working, and maybe see if I can get an xbmc frontend running on my raspberry pi.Anonymoushttp://www.blogger.com/profile/08217348593509965840noreply@blogger.com8tag:blogger.com,1999:blog-3306722009686352848.post-52256049060610927502011-05-30T14:36:00.000-04:002011-05-30T14:36:57.573-04:00rosjava setup on Fedora 15After the announcement of the <a href="http://code.google.com/p/rosjava/">rosjava</a> stack for android devices, I decided to bite the bullet and finally familiarize myself with <a href="http://www.ros.org/">ROS</a>. I have been looking for a way to periodically transmit my phone's GPS coordinates to a remote server for a project I'm working on, so I figured I'd try that as my first project with rosjava.<br />
<br />
I've been following the directions at http://code.google.com/p/rosjava/wiki/Welcome to install the rosjava stack on my Fedora 15 x86_64 system. Unfortunately, there are a few gotchas that aren't outlined in the documentation:<br />
<br />
1) If you have an x86_64 installation, you'll need some i686 libraries for the android SDK. Luckily, Fedora supports installing libraries from multiple architectures side-by-side very well. You can install the required libraries using the following command:<br />
<br />
sudo yum install ncurses-devel.i686 zlib.i686 glibc.i686 libgcc.i686 ncurses-libs.i686 libstdc++.i386 <br />
<br />
2) Before you run "ant dist" to build rosjava, you'll likely have to edit the ant property files. This is for two reasons: the location of your SDK installation may not be detected, and the target android API may also be wrong. You can add a build.properties to the following directories:<br />
<br />
rosjava/android/library<br />
all subdirs under rosjava/android/tutorials/<br />
<br />
containing the following text:<br />
target=android-10<br />
sdk.dir=/path/to/your/android-sdk-linux_x86<br />
<br />
You can modify the target for your desired API version (I found a more detailed explanation of these levels at http://sagistech.blogspot.com/2010/05/android-sdk-error-unable-to-resolve.html).<br />
<br />
3) There's a missing directory in the build tree that ant seems to need, a simple "mkdir rosjava/android/library/libs" should suffice.<br />
<br />
Now you should be able to run "ant dist" as per the directions and build rosjava.Anonymoushttp://www.blogger.com/profile/08217348593509965840noreply@blogger.com4tag:blogger.com,1999:blog-3306722009686352848.post-79013800082361856522011-05-23T18:06:00.001-04:002011-05-23T19:04:31.335-04:00The Fedora 15 Robotics SuiteWith Fedora 15's release imminent, I'd like to take the time to talk about the Fedora Robotics Suite. As some of you may have noticed, the Fedora Robotics Suite is a new <a href="https://fedoraproject.org/wiki/Features/RoboticsSuite">feature</a> for Fedora 15 and it is already showing up as a bullet point in many reviews of the Fedora 15 alpha and beta releases. In an effort to elevate this feature past 'neat-sounding bullet point,' I'll do my best to explain the motivations behind the feature and give a preview of what's in store for future Fedora releases.<br />
<br />
<span class="Apple-style-span" style="font-size: large;">What is it?</span><br />
The Fedora 15 <a href="http://fedorapeople.org/groups/docs/release-notes/en-US/sect-Release_Notes-Changes_for_Specific_Audiences.html#sect-RelNotes-Robotics">release notes</a> have this to say about the Robotics Suite:<br />
<blockquote>Fedora 15 now includes the Robotics Suite, a collection of packages that provides a usable out-of-the-box robotics development and simulation environment. This ever-growing suite features up-to-date robotics frameworks, simulation environments, utility libraries, and device support, and consolidates them into an easy-to-install package group. Visit <a href="http://fedoraproject.org/wiki/Robotics">http://fedoraproject.org/wiki/Robotics</a> for more details. </blockquote>In a nutshell, the Fedora <a href="http://fedoraproject.org/wiki/SIGs/Robotics">Robotics SIG</a> has been working hard over the past few releases to create a fast and easy way to dive into robotics development, for newbies and seasoned developers alike. The first visible result of this effort is the Fedora Robotics Suite, a package group that brings together many different robotics related libraries to make it as easy as possible for developers to use Fedora in their robotics projects.<br />
<br />
<span style="font-size: large;">Why is the suite needed?</span><br />
The open-source robotics scene is diverse, consisting of vast amounts of independent libraries and frameworks that can be used for all kinds of robotics tasks. Unfortunately, the robotics develpment community is small enough that even some of the largest and most well-known software packages are still "niche" packages in the scope of a large Linux distribution, often with only a handful of developers upstream. These factors add up to several problems that the Robotics Suite aims to alleviate: <br />
<ul><li><b>Software is difficult to configure and install</b>. This is mostly a problem for users who aren't familiar with Linux development and are diving in headfirst. A short visit to many small projects' mailing lists can tell you: if the configuration and installation process for a software component is complex, or the process isn't well documented, new users can be put off by the hurdle of getting their software environment set up, long before any development can take place. Our goal is to streamline the process by doing the hard work for you in the context of robotics-related software.</li>
<li><b>Software has too many dependencies</b>. Many robotics-related programs have critical dependencies on small or fledgling libraries that otherwise have little use to the Linux community in general. For example, the Point Cloud Library (currently under review) depends on the cminpack, flann, and eigen3 libraries. We want to make sure all of these are available with Fedora to spare the users the time-consuming process of finding, building, troubleshooting, and installing all of these small dependencies.</li>
<li><b>Software doesn't build properly with Fedora's system libraries</b>. Fedora leads the way in software versions with the latest and greatest packages from upstream. Often, developers of smaller libraries are only testing their packages against the set of libraries on their own machine, and may be oblivious to build errors resulting from newer system libraries. The Robotics SIG encounters these errors during packaging and updates and works with upstream to correct the issues.</li>
</ul>Basically we want to extend the benefits of pre-packaged software to the robotics community, and in the process make Fedora the distribution of choice for robotics developers.<br />
<ul></ul><span style="font-size: large;">What's in the suite?</span><br />
As noted at <a href="http://fedoraproject.org/wiki/Robotics">http://fedoraproject.org/wiki/Robotics</a>, the Robotics Suite currently includes several large-scale robotics frameworks and simulators, including Fawkes, Player, Stage, and the RoboCup Soccer Simulator. The Robotics Suite also consists of many specialized libraries like libphidget and libkni that interact with sensors and actuators, libraries like mrpt and openni that implement specialized algorithms for things like motion planning and image processing, and IDEs like Eclipse and Arduino to make code development easier.<br />
<span style="font-size: large;"><br />
</span><br />
<span style="font-size: large;">What's next?</span><br />
The Robotics Suite is a big milestone for the Robotics SIG, but we've got plenty of grand plans for future Fedora releases. We'd like to create an official Robotics Spin for future releases to make it even easier to sample and use the Robotics Suite, in the home or the classroom, without having to go through the whole install process. We are also sponsoring a Google Summer of Code student to create educational robotics software for new users that takes advantage of the packages available in the Robotics Suite. Finally, we're always hard at work packaging new and interesting robotics-related software for the Fedora community.Anonymoushttp://www.blogger.com/profile/08217348593509965840noreply@blogger.com5tag:blogger.com,1999:blog-3306722009686352848.post-30830676229090894732010-11-13T01:19:00.001-05:002011-05-24T15:19:34.308-04:00Kinect working on FedoraAs most of the internet has already heard, there is a very large effort underway to reverse engineer Microsoft's new Kinect for the XBox. The community quickly assembled around the first working open driver, and spawned a project called <a href="https://github.com/OpenKinect/openkinect">OpenKinect</a> on github and Google Groups.<br />
<br />
Once I heard that an open (GPLv2+) driver had reached a working state with the Kinect, I immediately went on Amazon and got myself one. Two days later (love that Amazon Prime) it arrived and I spent the night coding intensely trying to get a driver to work using the <a href="http://playerstage.sourceforge.net/">Player</a> robot server. I spent a few hours looking over the example code provided by OpenKinect and porting it into a Player driver that serves the data through a Camera interface. A few hours later, this is the result:<br />
<br />
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjp-UAm8MgCdrRssgOnjdtu-ZRb6zewmBTNY2EtU_8ufLYXRxST7ZH7GscS49slqtrhHacy9E1QEfddNPBNVOJLN_Zq2Q1X73mrLA8-HGFqK3HymlNSVxzvU7MC0PNL3oFfiS5fu-BjwTk/s1600/Screenshot-1.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="225" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjp-UAm8MgCdrRssgOnjdtu-ZRb6zewmBTNY2EtU_8ufLYXRxST7ZH7GscS49slqtrhHacy9E1QEfddNPBNVOJLN_Zq2Q1X73mrLA8-HGFqK3HymlNSVxzvU7MC0PNL3oFfiS5fu-BjwTk/s400/Screenshot-1.png" width="400" /></a></div><br />
<br />
The above is data from both camera sensors: the upper one is from the RGB sensor, and the lower one is the depth image, with a color gradient applied (hot colors are closer, cool colors are farther.) The Player server collecting, parsing, and publishing the data to the network, and the PlayerCam application subscribes to the server and displays the broadcast information.<br />
<br />
This project still has a long way to go: as of yet the OpenKinect project has yet to integrate the PTZ controls, audio streaming, LED control, and accelerometer readings into a single library. The <a href="http://fedoraproject.org/wiki/SIGs/Robotics">Robotics SIG</a> is following OpenKinect closely, and once OpenKinect is ready we'd like to include it in Fedora, with a working implementation via the <a href="https://admin.fedoraproject.org/pkgdb/acls/name/player">Player</a> package.Anonymoushttp://www.blogger.com/profile/08217348593509965840noreply@blogger.com1