update ros wiki link to my package after renaming it

edit

It would appear that the doc job for your package ran before you changed the name from muse to muse_bldc_motor_driver (from here):

Invoking '. /opt/ros/indigo/setup.sh && PYTHONIOENCODING=utf_8 PYTHONUNBUFFERED=1 catkin_make_isolated --install --cmake-args -DCATKIN_SKIP_TESTING=1 --catkin-make-args -j1' in '/tmp/catkin_workspace'
...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~  traversing 1 packages in topological order:
~~  - muse
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

If I change the PackageHeader(..) argument on your wiki page from muse_bldc_motor_drive to muse, I see the expected info rendered:

The doc job is triggered by changes to your repository, so you could commit and push some arbitrary change to get it to run again. That should make the package header appear on your wiki page.

Note however that doc jobs are only run once every three days, so it could take some time for the changes to become visible.

Edit: I would actually suggest you make some other changes to your repository, so these could be used to trigger the doc job again instead of some arbitrary change. As follows:

1. remove the src/CMakeLists.txt link: it's not supposed to be versioned, it is (re)created automatically be Catkin on every user's machine. Additionally, having an extra CMakeLists.txt in there could cause some hard-to-diagnose errors as there will be now two files pointing to /opt/ros/indigo/share/catkin/cmake/toplevel.cmake in the workspace.
2. move the contents of src/muse_bldc_motor_drive to the root of the repository: the src/ folder would appear to be the actual source space of your Catkin workspace, which is normally not versioned.
3. remove the contents of the muse_bldc_motor_drive/doc/html directory: those files get rebuild by the ROS doc job on every build, so there is no need to include them in the repository. Additionally, users can easily regenerate them locally, reducing maintenance for you as you don't need to keep them up-to-date with the code in the repository.
4. (minor): locations specified in your CMakeLists.txt are already relative to the location of that CMakeLists.txt, so there is no need to do things like ${MUSE_ROS_PATH}/...