Soldering of the Arduino Uno is OK, because Hello World is running. .
jeelib-master could be loaded, because of the '-' in the name. Unpacked the zip, renamed the directory in the default directory ~/Arduino/libraries to jeelib and loaded the directory via Sketch->Import Library->jeelib. Now I could use Sketchbook->libraries->jeelib->RF12->rf12demo. Giving the command G100 starts a pinging of all connected radios to a central hub.
Looking at the other RF12 demos. HomePower seems to be simple send-receive scenario. The weather station is listening on channel 5, but get the same print of active stations as on channel 100.
Adding an intelligent light is relatively simply (flat soldering red, yellow, white, black).
Starting with the InfraRed plug.
When I use the HiTec remote control, I could analyze the commands:
On: 9211121112111111121212121111 (Basic position <-> Sitting position)
P1: 513211121112111112121111111111 (ignore P1 and P2, this are the values when messages are mixed)
: 412111121112111112121111111121
P2: 1
: 1
1: 9211121112111111111111111111 (2x)
2: 9211121112111111111111112121 (2x)
3: 9211121112111111111111211121 (2x)
4: 9211121112111111111111212111 (2x)
5: 9211121112111111111121111121 (2x)
6: 9211121112111111111121112111 (2x)
7: 9211121112111111111121211111 (2x)
8: 9211121112111111111121212121 (2x)
9: 9211121112111111112111111121 (2x)
0: 9211121112111111112111112111 (2x)
Up: 9211121112111111112111211111 (2x)
Dn: 9211121112111111112111212121 (2x)
Rt: 9211121112111111112121111111 (2x)
Lt: 9211121112111111112121112121 (2x)
Hd: 9211121112111111211111112121 (2x)
A: 9211121112111111111121211121 (2x)
Checking the RoboNova manual. On page 36/48 the meaning of the different buttons are indicated.
My hypothesis is that the RoboNova does not start anymore in the original firmware. Reading best hacking guide to the RoboNova: the RoboSavy wiki.
Starting to read the documentation of the ZSB-project 'RoboNova Mimic'.
According to the students, the robot has to start lying on the ground. Now the robot listens to the infrared!
October 7, 2013
Frans Lotty made the port /dev/ttyUSB0 on U030245 fully accessible. repository/umi-drivers/daemon/rtxd /dev/ttyUSB0 starts without problems on the logfile. Couldn't find chess_demo. ../shell/rtxsh has problems connecting to the socket, so should be recompiled: downloadlib has problems connecting to socket: Connection refused
[armlib:downloadlib] failed
Connection is part of armlib/armraw.c, which is recompiled with correct paths in include/rtxd.h. Library is stored in ../../robotics/lib/Linux/libarm.a, which is also loaded by rtxsh.
Strange enough, couldn't find the chess_demo at nb-ros.
Redid my work on June 3: Copied chess_demo from /home/arnoud/src/bewegen/umi-driversNew/chess_demo on mremote. Just running the executable resulted in printing init_board (Nothing in rtxlog). Recompiling requires several robotics-libraries.
Copied also the Makefiles from src, and defined OSTYPE=linux. Defined to use /home/avisser1/onderwijs/ZSB/assistance/repository/robotics as PRAC-lib. Compilation goes well, linking fails on missing libumi.a, libmatrix.a, libstub.a, libpathplan.a and libinverse.a.
Making libumi.a fails on dependence on /opt/stud/robotics/assistance/robotics/ in Makefile. Removed the dependency on /opt/stud in ../../Makefile.common. Dependency could only be removed after make clean (to remove *.d files). Compilation fails on L_cuserid (see June 5). Tried again with defines, but ended up with an defining L_cuserid itself. libumi.a is successful made.
Also matrix, stub, pathplan and inverse worked fine. Also made xml_parser. Still, segmentation error in reading "/home/stud/robotics/data/board.rtx" in init_board from pathplan.c.
Modified ../../include/config.h. Also modified the location of the name_file in umicmds.c. Now the server is called (but fails, time to call Frans Lotty again). Yet, before chess_command crashed. The location of gnuchessr is also defined in chess_demo/gnuchess.h.
The communication now starts correctly, but fails in armraw.c:212, when the first arm_raw_transaction is send. Had same problems in June 7, 2011. Code on mremote is slightly different.
Should try to get the shell working. In 2011, I was working on sremote.
Tried umi-drivers/test directory. Couldn't made test (although I could make rtxlib). test1 was up-to-date, but gave (compare with June 7, 2011):
avisser1@u030245 test]$ ./test1
======================= ARM version 24 June 2008
downloadlib has problems connecting to socket: No such file or directory
[armlib:downloadlib] failed
IP1 version: (12,0) 9 0 21d3b28e
IP0 version: (12,0) 9 0 21d3b28e
Errno = 12
Errno = 12
Errno = 12
On mremote, there are several versions of armraw.c. Oldest is ./src/robotica/old_src/rtx/port/armraw.c (May 27, 1994) . The newest is ./src/bewegen/robotics/src/armlib/armraw.c(Jan 27, 2004). This is also a large file (size 14739) I accidently modified ./src/bewegen/umi-driversNew/armlib/armraw.c (size 14965). The armraw at acheron is even larger (size 15273).
In onderwijs/ZSB/assistance/repository/umi-drivers/test I still could make ./init, but also starts with arm_init_comms.
Starts because doinit (in misc.c) is the first command of the toplevel.
Made doinit in misc.c a dummy and started rtxd. Result that I the shell is started. Tried to do a probe, but function is hanging:
[avisser1@u030245 shell]$ rtxsh
RTX command line interface $Revision$
rtxsh> probe
/dev/ipc0: No such file or directory
/dev/vme32: No such file or directory
Can not talk to RTX on device 'IPC'
rtxsh> probe /dev/ttyUSB0
^C
emergency_stop 2
Interrupt
rtxsh> test
Call probe to initiate the pointer to the library.
emergency_stop 11
Segmentation fault
Emergency stop failed: Communication not initialised
Segmentation fault (core dumped)
Also tried if arm is listening, but commands arm->soak init gave:
[avisser1@u030245 shell]$ rtxsh
RTX command line interface $Revision$
rtxsh> arm
arm> soak init
arm: soak: Communication not initialised
arm>
At June 6, 2011 I comment that the second ACK is not needed.
Finally found my code on nb-ros back. It was on /home/arnoud/onderwijs/ZSB/assistance/repository. On nb-ros, combination rtxd and chess_demo still worked. Copied the programs to acheron in directory /home/avisser1/src/bewegen.
Tried to start chess_demo/chess directly, but /lib64/libc.so.6: version `GLIBC_2.14' not found.
New make chess failed on dependency on /home/arnoud/onderwijs/ZSB/assistance/repository/robotics. Also copied robotics-directory from ros to src/bewegen. Modified chess_demo Makefile to include this robotics-directory. Compilation works, but fails on location of board (still /home/arnoud/src/robotica/data/ which exists on nb-ros). After recompiling pathplan and inverse, chess compiles. Running it starts initialisation, but no response.
Lets try to start the rtxd from nb-ros. Seems to work, but couldn't get the tail of the rtxlog. Going into this directory already hangs computer (maybe due to debug statement of loadlibrary?).
Also the combination of the daemon and chess_demo from nb-ros (combined with the cable that worked for nb-ros) fails. Strange !!
Also found the Hitsquad manual, form a recent Hackspace project, which includes ROS interface and URDF model for the arm. The source code could be found on githup. They have a Ros simulation node coupled to an Arduino controller.
In addition, I found project which was able to solve the inverse kinematics of the Kuka youBot. The code is available on github.
September 3, 2013
According to Toto, the port issue with the UMI-RTX is now solved. Yet, /dev/ttyUSB0 is still only rw for the group dailout (and I am not in it).
Connected the UMI-RTX to U030245 and checked the serial-connector was mounted on /dev/ttyUSB0 with command dmesg | grep tty. Started the rtxd from ~/onderwijs/ZSB/assistance/umi-drivers, but although the executable is quite recent (June 19), it refers to /home/rtxipc (the old science.uva.nl setup).
The rtxd in /opt/prac/robotics/assistance/umi-drivers/daemon is even older (2006 and fails on missing libelf.so.1).
The rtxd in /opt/prac/robotics/rtxipc/robot/linux is from 2005.
Finally found the latest rtxd in ~/onderwijs/ZSB/assistance/repository/umi-drivers/daemon. Result (from tail /opt/prac/robotics/rtxipc/logs/rtxlog: Sep 03 11:44:54 (RTXD) Couldn't open '/dev/ttyUSB0'
Also tried it with the other USB-serial converter (pl2303). Still same result.
June 19, 2013
Modified the makefile in both hostlib and daemon (defined OSTYPE=linux). Yet, still nlist is not found (while libelf-dev is installed). Made download with option -H, and /usr/include/nlist.h is used. Adding -lelf to the LDLIBS solved this issue.
Still no part of group dailout, so couldn't start rtxd.
Made the ZSB directory recursively part of group rtxipc-unix-local-sec-fnwi.
Copied /home/rtxipc to /opt/prac/robotics. Added Toto and the assistants to robot/name_file.
Changed the path definitions in rtxd.h and made a new daemon. Result is that the /opt/prac/robotics/rtxipc/logs/rtxlog is updated (with the expected result as long as am not member of the dailout group):
Jun 19 20:41:53 (RTXD) Restarting, listening to port 53898 on u019915.fnwi.uva.nl
Jun 19 20:41:53 (RTXD) Couldn't open '/dev/ttyUSB0'
June 12, 2013
The UMI-RTX is in G0.10, next to U019915. The robot still works, the decent is so fast that you have to build in an intermediate point to prevent overshout through the board.
Look if I also could start a daemon from U019915, or that I can connect to the daemon on 145.18.214.250 (port 41995).
Copied my onderwijs/ZSB to uva.nl domain.
When I plug in my USB-serial adapter, /dev/ttyUSB0 is created (crw-rw----) with owner root, and group dialout.
Followed the instructions from askubuntu, and added myself to group dialout. Not only sudo adduser dialout, but also a full sudo reboot. Tested it on nb-ros, and I could start both the rtx daemon and the chess_demo as normal user.
After the reboot nb-ros started with downloading some updates, but failed to connect to eduroam after that.
On U019915, the gcc version is 4.4.6-4.
June 10, 2013
The UMI-RTX robot is repaired: the robot arm goes full speed down and the gripper picks up a pawn at the correct height:
June 6, 2013
Showed the behavior (not going down) to people of the Technical Support. Initially the hypothesis was that it was something mechanical. Yet, putting more or less stress on the band of the z-axis didn't help. Even with the band loose, the band couldn't be removed from the bottom or top wheel:
It seems not to be a mechanical problem (the arm can slide freely), but an electronic or sensor problem. The cabinet was opened and when the motor was given power, it only in one direction. In the other direction measurements indicated 4 ampere (full power).
The motor and the bottom wheel were removed and brought to the electronic support for testing:
June 5, 2013
All libraries needed for chess_demo compiled without problem. After correcting the Makefile, make chess worked without problem. Time to test it on the UMI-RTX robotarm.
chess crashed. Inspection with the debugger gdb showed that I failed to read /home/arnoud/src/robotica/data/board.rtx. Copied the whole robotica directory from mremote.
Pitty, the board.rtx is actually in /home/stud/robotics/data. Copied this directory from sremote to /opt/prac/robotics.
Also copied /home/stud/robotics/bin to /opt/prac/robotics.
Now chess works, but still it is searching for /home/rtxipc/robot/name_file. This was defined in robotics/src/umi/umicmds.c. Making a new libumi failed on "‘L_cuserid’ undeclared". This constant is defined via stdio.h declared in bits/stdio_lim.h, but protected with a USE_POSIX ifdef. Defining POSIX didn't help, so patched it directly into umicmds.c
The robot didn't respond, but this was initially because root was not in the name_file. After that it still failed. Restarted daemon, but this was not succesful (according to rtx.log). Checking with dmesg | grep -i ftdi showed that the serial port was now installed on /dev/ttyUSB1. Starting the daemon with sudo ./rtxd /dev/ttyUSB1 was succesfull.
chess crashed on interaction with gnuchess. Forcing the program to play "e2e4" all the time solved this (temporally).
June 3, 2013
The USB-Serial Adapter from DeLock is arrived. Found the robotarm in the basement. Umi-Rtx arm is still functional (only have to initiate the communication).
dmesg | grep tty gives: [30237.242287] usb 3-2: FTDI USB Serial Device converter now attached to ttyUSB0
ls -galt /dev/ttyUSB0 gives: crw-rw---- 1 dialout 188, 0 Jun 3 11:40 /dev/ttyUSB0
Found the hg-repository in /opt/stud/robotics/assistance/hgrepos/, which I have cloned into /home/arnoud/onderwijs/ZSB/assistance/repository/ (both on sremote). Not clear (yet) how I could clone this into another machine.
Should start with repository/umi-drivers/daemon and shell.
Copied repository/umi-drivers to nb-ros. daemon depends on hostlib, so started with hostlib.
Make gives only some warnings, until download.c, which fails on nlist.h.
In 2012 I compiled daemon with gcc 4.1.2 (and failed with gcc-4.2-0). Now I have gcc 4.6.3.
Doing a sudo apt-get install libelf-dev solved the nlist.h problem.
Could build the daemon. Daemon fails on non-existing /home/rtxipc. Copied /home/rtxipc from sremote to /opt/prac/robotics/rtxipc on nb-ros. Now the daemon starts, but the rtxlog shows:
Jun 03 15:30:03 (RTXD) Restarting, listening to port 46456 on nb-ros
Jun 03 15:30:03 (RTXD) Couldn't open '/dev/ttyUSB0'
Jun 03 15:30:03 (RTXD) No rtx_ops found for '/dev/ttyUSB0'
Jun 03 15:30:03 (RTXD) Can not talk to RTX
Connecting to /dev/ttyS0 and /dev/tty gave the same result.
The driver (Dec-2008) on the CD pointed to a Sourceforge project, including troubleshouting.
The command arnoud@nb-ros:~$ dmesg | grep -i ftdi gave: [30237.242034] USB Serial support registered for FTDI USB Serial Device
[30237.242117] ftdi_sio 3-2:1.0: FTDI USB Serial Device converter detected
[30237.242287] usb 3-2: FTDI USB Serial Device converter now attached to ttyUSB0
[30237.242301] usbcore: registered new interface driver ftdi_sio
[30237.242303] ftdi_sio: v1.6.0:USB FTDI Serial Converters Driver
Downloaded serial_loopback.pl. Needed also to install Benchmark-Timer. Running the script perl serial_loopback.plas normal user gave: Can't open tty_out '/dev/ttyUSB0' - error : Permission denied at serial_loopback.pl line 161.
Running as root gave: count: 1, bytes read on first read: 0.
Running rtxd as root gave: Jun 03 17:06:28 (RTXD) Restarting, listening to port 41159 on nb-ros.
Compiled armlib and shell. Starting shell as normal user gave warning: downloadlib has problems connecting to socket: Permission denied
[armlib:downloadlib] failed
As root the shell starts without problems. Gave the commands init, arm and soak init and robot nicely started initialisation routine.
Copied chess_demo from /home/arnoud/src/bewegen/umi-driversNew/chess_demo on mremote. Just running the executable resulted in printing init_board (Nothing in rtxlog). Recompiling requires several robotics-libraries.
Copied repository/robotics from sremote. Tried to build simulator, but dependence of robot.c failed on /usr/include/sys/cdefs.h.
April 16, 2013
A simple make in soem_core/build created soem_core/bin/slaveinfo. Yet, this gave no additional information (ec_init on eth1 succeeded. No slaves found!).
Read the information about EtherCAT on wikipedia. Not so informative, so I read two of the referenced articles.
Three observations:
I get regulary a Wired network disconnected update at my Ubuntu desktop.
I see a IPv6 address for eth1, but no IPv4 address (eth0 has).
In the article EtherCAT – the Ethernet fieldbus, they mention that a crosscable is needed for direct communication: made a crosscable, still no slaves found. Also in the EtherCAT socket, both cables didn't work.
April 15, 2013
Unpacked YouBot. Installing remastered Ubuntu didn't work for nb-ros. Made a new partition on pc-udk. The installation ask for a username, but installs as user youbot anyway. Making the hello_world_demo works fine, but running it gives:
Warning: No EtherCAT slaves found!
Followed on nb-ros the instructions from youbot. Cloning works, but roscd youbot_oodl not. Went manually to ~/ROS/packages/youbot-ros-pkg/youbot_drivers/youbot_oodl/, but rosmake didn't know the option --rosdep-install. Making a build-directory and doing cmake .. failed on missing youbot_oodl in ROS_PACKAGE_PATH. Anyway, controlling the youbot from nb-ros will be problematic as long as I don't have an Ethernet adapter (or have wifi working on the youbot).
The ocorus website indicates that the status of the EtherCat connection can be checked with slaveinfo of the Simple Open EtherCat Master library. Unfortunatelly, this requires the orocos toolchain (without ROS), and the orocos toolchain bootstrap doesn't install because it detects ROS. The ros wiki for this toolchain is broken.
February 22, 2013
Can order the Argos 3D from BlueTechnix, which should be able to recognize the chess pieces from nearby.
The manufacturer provides this software to record and visualize the data.
.
