For next year shopping list: the Parrot Mambo, which can grab (and shoot).
July 28, 2016
Tested the modification of yesterday (added the year to log, removed some compiler warnings). It still works:
2016-07-28 19:51:07 (RTXD) Restarting, listening to port 34055 on nb-ros
2016-07-28 19:51:41 (7) New Connection (read/write)
2016-07-28 19:51:41 (7) New client (read/write), user arnoud
2016-07-28 19:51:57 (7) onetransaction: RTX_CMD_SOAK
2016-07-28 19:51:57 (RTXD) called rtx_do(0,1,10,0,0,0,0,0)
2016-07-28 19:51:57 (RTXD) called rtx_do(1,1,10,0,0,1,0,0)
July 27, 2016
It would be nice to implement the chess-problem in pyDatalog.
Checked /opt/prac/robotics on nb-ros. The directory /opt/prac/robotics/rtxipc contained several subdirectories which are not necessary. I moved them to /tmp/prac/robotics/rtxipc. Removed many ipc-files./tmp/prac/robotics/rtxipc/robot contained the sparc-executables, the working binaries are in /tmp/prac/robotics/rtxipc/robot/linux.
The rtxd (from 2013) in /opt/prac/robotics/rtxipc/robot/linux doesn't work, because it depends on /home/rtxipc
The rtxd in ~/onderwijs/ZSB/assistance/repository/umi-drivers/daemon is starting, so I copied that one to /opt/prac/robotics/rtxipc/robot/linux. The rtxsh has an error loading the sharedlibrary libreadline.so.5.
The rtxsh in ~/onderwijs/ZSB/assistance/repository/umi-drivers/shell stil fails on Jul 27 16:00:51 (RTXD) 'rtx_init_comms' fails on CMD_TOGGLE_OFF
Retried with the pl2303 converter. Now I get the another warning from rtxsh:
RTX command line interface $Revision$
======================= ARM version 24 June 2008
downloadlib has problems connecting to socket: Permission denied
[armlib:downloadlib] failed
init: Retry the connection
This was because the rtxsh, connected with the previous rtxd was still running. RTX_QUIT killed the new rtxd.
Starting fresh worked (so good, that I couldn't switch it off):
RTX command line interface $Revision$
======================= ARM version 24 June 2008
arm_interrupt: RTX_CMD_INIT
rtxsh> arm
arm> soak init_soak
arm_interrupt: RTX_CMD_SOAK
arm> soak off
arm_interrupt: RTX_CMD_SOAK
arm: soak: Not enough bytes in command
arm> quit
rtxsh> quit
arm_interrupt: RTX_CMD_QUIT
July 20, 2016
The depth (without artificial colouring) can be visualized with the command rosrun image_view image_view image:=depthsense/depth_image. The result:
The confidence_image (command rosrun image_view image_view image:=depthsense/confidence_image) was not informative (just grey).
July 19, 2016
Got the DepthViewer working. Essential is that linux-download is only visible when logged in.
The release-notes are for Windows, the working download was the deb.run package. After changing this to a executable (which chmod +r), the software (and documentation) is installed at /opt/softkinetic/DepthSenseSDK.
The Viewer is not that simple, to see a depth-image first the node has to be registered, than a window has to be opened by double-clicking on the node, followed by hitting the play button.
Cloned ros_depthsense_camera in catkin_ws/src next to bb8_jakku. Builds without problems for ros-indigo.
Started the node with command roslaunch ros_depthsense_camera depthsense.launch, but got an Exception (another instance of DepthSenseSDK is already running).
With rostopic I see now several depthsense topics, such as /depthsense/image_raw.
The image_raw can also be visualized with the command rosrun image_view image_view image:=depthsense/image_raw. The result:
July 10, 2016
Graded Task3 of this year. Downloaded positions.txt from ZSB/2012 from u033089.uwp.science.uva.nl. Checked the resulting joints.txt with umirtxsimulator (no problem with floats in joints.txt).
Checked Freecom-drive for sremote-files, but those ZSB-archives are gone.
Should write unittest-functions for the TAs for each of the IK-functions.
Downloaded several moves from acheron (b5c4, c6b6, g6f7), but the move is one of the argmuents to the PP-function. More important is the corresponding board.gch (which reflects the board after the move).
The file Test.java test the StudentBoardTrans. Had to change b.readBoard() to b.read() to get a working Test.
Modified a beginning board for d8c5 move, which needs a detour (and a configuration switch). Good test board!
Made even a more challenging board (d8c6), which forces to make always an configuration switch).
July 3, 2016
Installed bb_8_jaku cleanly on the Tuxedo from Echoic.
Had to install sudo apt-get install ros-indigo-joy ros-indigo-controllers ros-indigo-rgdb-launch to be able to run roslaunch bb_8_gazebo main.launch. BB8 is visible in the world, but the desert and tatooine are missing(worlds should be copied to /usr/share/gazebo-5.3/worlds?).
Still no response on roslaunch bb_8_teleop keyboard_teleop.launc, the simulation doesn't publish gazebo topics (nor /clock). Try to source /usr/share/gazebo-5.3/setup.sh after the devel/setup.sh?
With /usr/share/gazebo-5.3/setup.sh the clock is published! Yet, still no reaction on the keyboard.
The trick was to hit the play-button in gazebo: finally I am able to move BB8 around:
Succesfully reproduced the result on nb-ros: first killall -9 gzserver gzclient, start source /usr/share/gazebo-5.3/setup.sh after the catkin_ws/devel/setup.sh, launch and hit the play button!
July 2, 2016
Now roslaunch bb_8_gazebo main.launch only fails on a not installed rgbd_launch, which is easily repaired with a sudo apt-get install ros-indigo-rgbd-launch.
roslaunch bb_8_gazebo main.launch starts, but no gazebo screen pops-up (nothing suspisious in the log. Maybe the network setting, should try roslaunch gazebo_plugins multi_robot_scenario.launch again (which was working yesterday).
Something wrong with my Gazebo installation. roslaunch gazebo_plugins multi_robot_scenario.launch starts nicely, but the standard gazebo worlds/pioneer2dx.world not. The GAZEBO_RESOURCE_PATH points to an non-existing /usr/share/gazebo_models and a non-existing /usr/share/gazebo-5.3 (only /usr/share/gazebo-5.1 exists).
Checked with sudo apt-cache search gazebo | more for available packages, but all gazebo5 packages are installed and the latest version.
Did a combined sudo apt-get update; apt-get upgrade. Many ros-indigo packages are updated, but not the gazebo ones. Yet, it has some effect, because gazebo worlds/pioneer2dx.world now starts, because /usr/share/gazbo5.3 is in the GAZEBO_RESOURCE_PATH.
Copied the desert.world and tatooine.world from install/share to /usr/share/gazebo5.3. Also copied the desert, star_destroyer and tatooine-directories to ~/.gazebo/models. gazebo worlds/tatooine.worlds, main problem seems to be that that the bb_8 model is not found.
Installed catkin_ws. Did a catkin_make, did a source devel/setup.sh, copied the bb_8_jakko in source and did a catkin_make again. Now roscd works and a gzserver starts. Nothing is visible, but that is because no gzclient is started. Finally I have my bb_8:
Couldn't move it around with roslaunch bb_8_teleop keyboard_teleop.launc, but this can be due to my restarting=false for move_controller.
Also with restarting is true in the main, no response on the keyboard. The script is publishing cmd_vel, but rostopic list shows both /teleop/cmd_vel, /cmd_vel as /cmd_vel_mux/selected.
Published a drive command with on all three topics, but to no avail.
Looked at the tutorial based on TurtleBot, but that works fine.
Restarted the computer, but that didn't help.
Was looking at cmd_vel_mux, which is called is called as /opt/ros/indigo/lib/topic_tools/mux, with as arguments base_controller/command /cmd_vel. Yet, the keyboard_teleop directly publish to /cmd_vel.
For mux the input/output is precisely vise-versa: cmd_vel is converted into a base_controller/command.
Yet, nobody is subscribed to base_controller/command, but according to rostopic list -v two subscribers are subscribed to /cmd/vel
Tried to see the camera from the bb8 with image_proc. The command ROS_NAMESPACE=bb8/camera1 rosrun image_proc image_proc?distro=indigo worked, rosrun image_view image_view image:=bb8/camera1/image_rect_color failed on not installed image_view.
The image is compressed, so maybe image-transport is needed. both image_raw as image_mono are available in compessed and theora.
Checked with rostopic echo odom, but no messages are submitted.
Checked the instructions of gazebo-ros and installed ros-indigo-gazebo5-control.
Yet, none of the gazebo topics nor gazebo services are published. Checked main.launch, but that says (find gazebo_ros). The command roscd gazebo_ros works.
Tested the soda can example: rosrun gazebo_ros spawn_model -database coke_can -sdf -model coke_can -y 1. Takes some time (downloading coke_can model from the online database?). Until now, only a /rosout topic.
July 1, 2016
Ricordo Tellez from TheConstruct tested the bb8 with Gazebo 4 - ROS Indigo without problems.
Repeated catkin_make and catkin_make install after source ~/catkin_ws/devel/setup.sh and now it works! Fault was to use source /opt/ros/indigo/setup.sh.
Yet, to run roslaunch bb_8_gazebo main.launch still fails:
File "/opt/ros/indigo/share/xacro/xacro.py", line 62, in
xacro.main()
AttributeError: 'module' object has no attribute 'main'
while processing /home/arnoud/catkin_ws/src/bb_8_jakku/bb_8_gazebo/launch/include/bb_8.launch.xml:
Invalid tag: Cannot load command parameter [robot_description]: command [/opt/ros/indigo/share/xacro/xacro.py /home/arnoud/catkin_ws/src/bb_8_jakku/bb_8_description/robots/bb_8.gazebo.xacro] returned with code [1].
Param xml is command="$(find xacro)/xacro.py $(find bb_8_description)/robots/bb_8.gazebo.xacro" name="robot_description".
There is something wrong with my installation: I followed the suggestion at this ros answer, but also roslaunch gazebo_plugins multi_robot_scenario.launch fails.
Tried different versions of my bashrc file. There are three relevant setup.sh. The following combination seems to work for the multi_robot_scenario:
source /opt/ros/indigo/setup.sh
source /usr/share/gazebo/setup.sh
#source ~/catkin_ws/devel/setup.bash
Only error is that the network is not configured right:
A common cause is that the machine cannot ping itself. Please check
for errors by running:
ping nb-ros
For more tips, please see
http://www.ros.org/wiki/ROS/NetworkSetup
Set in the ~/.bashrc export ROS_HOSTNAME=127.0.0.1;export ROS_MASTER_URI=http://127.0.0.1:11311 and was able to start roslaunch gazebo_plugins multi_robot_scenario.launch.
Still, roslaunch bb_8_gazebo main.launch failed because bb_8_gazebo was not in the ROS_PACKAGE_PATH. Added /home/arnoud/catkin_ws/install/share to the ~/.bashrc (adding ~/catkin_ws/devel/setup.bash directly corrupts my ros-setup.
June 24, 2016
Found the cable again and connected to nb-ros to DeLock.
Checked the connection with dmesg | grep tty, and restarted sudo rtxd /dev/ttyUSB0.
Still chess doesn't work, tried rtxsh. Got both for init_comms and soak init_soak No reponse (with TOGGLE error in the log).
June 20, 2016
Downloaded the bb_8_jakku.zip that I had bought.
Followed the instructions in the README.md, and extracted the code in catkin_ws/src and did a catkin_make.
Failed on missing dependency on robot_controllers. Performed a sudo apt-get install ros-indigo-robot-controllers
Continued with the following command roslaunch bb_8_gazebo main.launch, but this failed on find bb_8_description, while roscd bb_8_description works. Also rosrun xacro xacro.py robots/bb_8.gazebo.xacro fails on that the xacro has no main.
Tried catkin_make install. Had to modify bb_8_gazebo/CMakeList.txt to be able to run catkin_make install succesfully. Still same xacro error.
June 16, 2016
Executed on the 32bits Virtual Machine the umirtxsimulator with a joints.txt. When the list contains floats, the machines freezes. All intergers works fine.
Connected the umirtx to nb-ros with the DeLock connector. Tried ./rtxd /dev/ttyUSB0 from /opt/prac/robotics/rtxipc/robot, but rtxd is a wrong format (sparc).
Instead, started the daemon from ~/onderwijs/ZSB/assistance/repository/umi-drivers/daemon. Seems succesful, the /opt/prac/robotics/rtxipc/logs/rtxlog shows as last line: Jun 17 10:14:11 (RTXD) Restarting, listening to port 34224 on nb-ros.
The program chess in ~/onderwijs/ZSB/assistance/repository/umi-drivers/chess_demo is linked with UMI and ARM version of 2014 (and gets no response). Yet, this was the program I used in June 9, 2015. The log shows many rtx_do commands, but the third line doesn't seem promesing:
Jun 17 10:16:47 (7) New Connection (read/write)
Jun 17 10:16:47 (7) New client (read/write), user arnoud
Jun 17 10:16:48 (RTXD) 'rtx_init_comms' fails on CMD_TOGGLE_OFF
Tried ~/onderwijs/ZSB/assistance/repository/umi-drivers/shell/linux/x86. but failed on missing libtermcap.so file.
June 14, 2016
Checking and fixing the drones.
Tested the white rolling spider (after putting Bluetooth on) with Freefright 3.0. First flight was not stable, second was.
Tested the red spider and replaced one rotor.
Tested the Jumping sumo (wifi connection) and it works fine.
June 7, 2016
In August 16, 2015 I tested the umirtxsimulator in the virtual image, which works because it is still 32bits (yet with an old location of the namefile).
In June 19, 2014 I mention that the working 32bits simulator is from June 2006, while in June 2009 I was able to compile the umirtxsimulator with gcc-2.95.3.
At acheron, the onderwijs/ZSB/assistance/robotics is from June 19, 2014. Yet, without /opt/prac, I couldn't use gcc-2.95.3 to compile.
No umirtxsimulator binary in onderwijs/ZSB/assistance/robotics or onderwijs/ZSB/assistance/repository/robotics.
Checked u033089 (Jose's machine): not even in fransve.
In June 5, 2012 I was working on ow139 (u013570), maybe I should check if this machine is still alive. Checked, and this machine is gone.
I found this post on askubuntu; the cybermirror with the source is no longer available, I could try Debian packages at old-releases.ubuntu.com.
Installed gcc-2.95 by these commands:
cd /tmp
wget http://old-releases.ubuntu.com/ubuntu/pool/universe/g/gcc-2.95/cpp-2.95_2.95.4-22_i386.deb
sudo dpkg -i cpp-2.95_2.95.4-22_i386.deb
wget http://old-releases.ubuntu.com/ubuntu/pool/universe/g/gcc-2.95/gcc-2.95_2.95.4-22_i386.deb
sudo dpkg -i gcc-2.95_2.95.4-22_i386.deb
On request of Boas, I created robotics.zip with also a endgamequeen.
Downloading 64bits 2nd year virtual machine, to make also a 64 bits version of /opt/prac/robotics (via acheron onderwijs/ZSB/assistance/assistance.zip).
Tried the BscKI_y2.vdi, but this could only be started from the Oracle VM VirtualBox Manager (and gave a boot-choice, followed by a black screen).
June 6, 2016
The call in playchess.c makes a call to pl (version 5.7.11), while at the virtual machine the executable is now prolog (version 6.6.4).
Call to 'p' directly quits (how to get the buffer overflow?).
Call 'p' directly exits on chess_command 'get board.gch'
This call is executed in robotics/src/game/chessraw.c. The 'get board.gch' is interpreted as a call with no_answers=0.
Chess_command crashes on fputs.
I moved the directory, so gnuchess wasn't defined on the right location anymore. Now Chess_command continues after fputs and gets a buffer overflow after malloc. Yet, the compiler gives a warning on overflow on line 432, so I should check this warning.
Warning and runtime error can be solved by changing the strcpy to a strncpy.This are the modified files:
The software4students.tgz was missing the binaries and data-files, which were available on acheron (at /opt/prac/robotics).
Asked Auke to restore the auto-mount of /opt/prac/robotics.
On acheron I also had /home/avisser1/onderwijs/ZSB/software4students/, with software from 22 May 2006 (which was two weeks newer than the software on u033089).
After copying board.txt, position.txt, joints.txt the endgamerook functioned, although it complained about missing java-classes. Copying those classes from assistance/java solved this.
Remaining issue are the inialisation: board.gch and board.txt are different, some have a white queen, other a black queen (while we should play with a rook). Should wait on the files at /opt/prac/robotics/data.
About the latest software: June 3, 2014 I cloned the hg-repository in /opt/stud/robotics/assistance/hgrepos/, which I have cloned into /home/arnoud/onderwijs/ZSB/assistance/repository/ (both on sremote).
In September 12 I found the ~/onderwijs/ZSB/assistance/repository/ on acheron, with in java/dataseveral gch- and rtx files from Jun 2011 (no *.txt files).
In September 13 I mention the files on nb-ros! There are many gch files on /opt/prac/robotics/data, from Jun 2013.
In June 12, 2015 I found that the source of simulator in hgrepos are from 6 jun 2011, the object files from 28 jun 2012. The source-code of the simulator in /home/avisser1/onderwijs/ZSB/assistance/robotics/src/ from Jun 19 2014 (acheron).
On June 18, 2015 I copied the ~/onderwijs/ZSB/assistance/repository/umi-drivers/ on nb-ros to the same location in u019942.
Conclusion, the latest drivers can be found at nb-ros, but this machine has no java-software (bewegen directory). The latest java-software should be available on acheron.
On August 16, 2015 I tested endgame in the 32-bit virtual machine, but failed because the executables were 64 bits. No previous reference of endgame.
>June 19, 2015 I tested java PP, when I was making playchess.
Copied acheron.fnwi.uva.nl:onderwijs/ZSB/assistance/java to 32bits Virtual Machine on nb-udk (usb3 stick).
Also copied acheron.fnwi.uva.nl:onderwijs/ZSB/assistance/robotics/Makefile*. Make now works partly:
javac IK.java
javac PP.java
make: *** No rule to make target `/usr/include/sys/cdefs.h', needed by `playchess.o'. Stop.
Removed manually playchess.d and added acheron.fnwi.uva.nl:onderwijs/ZSB/assistance/robotics/include.
make fails now on ../robotics/include/chesscmds.h, because mode_t is also defined in stdlib.h. Renamed this in chess_mode_t. Compilation works, linking fials on missing libstub.a, libmatrix.a and libchess.a.
Modified game/chesscmds.c. Could succesfully make libchess.a from src/game. Executable chess still depends on libstub.a and several others!
Could easily make a libstub.a from the three stub_* directories and libmatrix.a from the matrix directory.
Linking of java/playchess now fails on undefined stub_init_pp and spp_read_board. After a make clean I could make 32-versions of endgamerook, endgamequeen, endgamepawn. endgamerookrook and playchess.
The java/pldirectory contains several files mentioned in manual: AL0.pl, KRPL.pl, KRAProok.pl, KRPLrook.pl. The boards is initialized with a queen. The manual suggest to press 'r' to load renewboard.gch. Yet, also this file contains a board with a queen, and endgamerook crashes on a malloc:
endgamerook: malloc.c:2372: sysmalloc: Assertion `(old_top == (((mbinptr) (((char *) &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk, fd)))) && old_size == 0) || ((unsigned long) (old_size) >= (unsigned long)((((__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 *(sizeof(size_t))) - 1)) & ~((2 *(sizeof(size_t))) - 1))) && ((old_top)->size & 0x1) && ((unsigned long) old_end & pagemask) == 0)' failed.
Aborted (core dumped)
Copied endgamerook.gch from nb-ros (/opt/prac/robotics/data) to endgamerook.gch and copied that one over board.gch (so that I don't need to push 'r').
Pushing 'p' is no success: equivalent with quit. Move board seems to work.
Only new file is chess.error_report, which complains on missing gnuchessr.
nb-ros contains two versions of gnuchessr (both from Jun 5, 2013), which according to the file command are 32bits exectables.
On October 7, 2013, I found out that gnuchessr is defined in config.h and gnuchess.h
Copied the nb-ros gnuchessr from /opt/prac/robotics/bin/linux to gnuchessr.
Made a version of gnuchessr (on the 32bits virtual machine) in robotics/src/game/gnuchessr, but robotics/include/config.hspecifies as location /home/mtjspaan/linux/bin/gnuchessr.
gnuchessr itself starts nicely, only complaining abouts its book (which is available on game/gnuchessr).
The students have to write an essay on Visual control of navigation and its relevance for robotics. In this paper five examples of bioinspired robotic navigation are given. Invent another example.
Requires is a personal answer (one paragraph, ~250 words)
Found the 360fly camera, but it seems that the movies can only be transfered from the camera by apps, couldn't find a ADK. Still, the transfer is performed via Wifi, so it should be possible.