strands-project / scitos_robot Goto Github PK

View Code? Open in Web Editor NEW

0.0 29.0 10.0 5.43 MB

Everything related to the STRANDS robot hardware can go in here

scitos_robot's People

Contributors

Watchers

Forkers

cburbridge kunzel raresambrus bfalacerda jailander cdondrup hawesie gestom nilsbore somebodyus

scitos_robot's Issues

using chest and head camera simultaneously

I have some problems starting our robot with chest and head camera connected at the same time.
If both are plugged in, we are not even able to boot our PC (it gets stuck shortly after the BIOS setup).
I somehow managed to get both running yesterday, but this seems impossible at the moment. I even tried to plug the head camera in after starting Ubuntu, which causes the system to freeze.

We are currently using the chest cam, sound, touch screen and an additional USB hub (joystick and keyboard) as USB 2.0 ports. The only thing connected to USB3.0 is the head cam.

Has anyone else experienced this problem?

Power supply for external PCs broken

Has anyone else ever had problems with the power supply (g4m11 M3-ATX) of the external PC? One of ours doesn't supply power to the main PCs anymore. (I checked the input voltage to the power supply, which is fine. Plugging in the second power supply to the same PC works.)

As the robot was running for some weeks now, I was just wondering if the power supply is okay for such long-term performance. Therefore, if other power supplies from any of our robots break as well, we might have to consider replacing it by a better one.

ASUS Xtion USB id

We are going to purchase a new ASUS Xtion for our university. As there seems to be some problems with Xtions with USB id 1s27:0601 on the STRANDS robot, we are thinking of buying one with the proposed id 1s27:0600. Just wondering if there is any way to figure out the id from the model name or so to order the correct one.

Charging slow on Werner

Hi,

since yesterday, Werner's charging rate is very low. The charging current is typically below 2A and is fluctuating wildly. The 'charger_status' field internal_error_flag is True and 'const_current_mode' is fluctuating between True and False. Battery level was about 77% when I checked.
We recorded the 'battery_status' for a few hours - the rosbag is available here: https://lcas.lincoln.ac.uk/owncloud/index.php/s/FbRBWMZnZQQjVcQ.

Can we do anything to figure out why is the charging slow ? normally it's about 10A.

Best,

Tom

Calibrate Odometry: How?

Is it possible to calibrate the odometry of the robot? We discovered a systemic error in the odometry (the robot is accumulating rotation even if it is not rotating). @gestom and @cdondrup know the details. It would improve mapping and localisation if this systemic error could be avoided.

Robot not charging past 90%

Our robot does not charge past 90%. It even went down from 91% to 90% while charging. This happens both with the charging station or when charging by cable.

Virtual bumper for detecting resistance in the environment

As proposed by @gestom at the BHAM meeting.

Fast odometry causes over shooting

For some reason the increase of the publishing frequency for the odometry causes the robot to over shoot its target. We set it to a publishing frequency of 20 which resulted in 45hz which is still not very fast for odometry. With setting however Mira seems to fail updating the robot position and therefore move_base never reaches its goal. Setting it to 25hz solved this but I'm quite puzzled why this happens. Any ideas anyone?

Check for cliff detection for dealing with downward stairs

BIOS settings

I'd need some help for the BIOS settings. After disabling the USB 3.0 support in BIOS (Advanced - USB Configuration - USB 3.0 Support - Disable), these ports are disabled completely. Neither Keyboard nor ASUS Xtion are working when plugged into the blue USB ports with this setting.

I then tried to change few other settings in the BIOS in the hope that the USB bus gets separated from the CAN bus. However without any success. I ended up trying to restore the BIOS defaults, which wasn't too clever I assume. Now I can only work with an external monitor as the touchscreen monitor stopped working (only white background light) and persisting USB problem.

Can anyone tell me how to configure the BIOS correctly (given the default settings)? Or is there anyone I could ask from Metralabs?

Werner sometimes loses control of one Wheel

Hello, Werner sometimes loses control of one Wheel and reconnecting the wires going to the motors is necessary, they are not obviously disconnected but that seems to be the magic fix, @creuther can we do something about this (it was the left wheel both times)

Robot head trying to move down when initalizing

We had a bit of a problem with our problem when it arrived. The motor driving the "nodding" of the head was scratching the plastic bowl and we eventually realized that it had come off. The problem was probably due to the motor pulling to strongly at initialization, driving the "nodding" of the head down towards the hardware stop. This is probably a design feature to initialize the encoder at the bottom of the movement.

We have received a spare motor from metralabs and it generally seems to work now. However, it still drives the head downward at initialization, making some noise for a couple of seconds. I remember there being some noise at this step from the other robots as well. Can one of you guys check if the noise is originating from the same source? We want to make sure that our robot is working as it's supposed to and then get back to the metralab guys. Cheers!

Magnetic sensor too insensitive

After trying to get the magnetic strip detector working on Werner/Henry today at AAF, @Jailander and I finally came to the conclusion that the sensor is setup a bit too far away or it is too insensitive to magnets.

I dismounted the lower cover from the robot and checked the LED of the sensor. There is no light when I stick the magnetic strip on the ground and put the sensor above, but if I lift the magnetic strip a little bit and bring it closer to the sensor, it goes on.

@chmartin21, @creuther: Is there a way to fix this?

FTDI disconnecting

Lately, LINDA suffers from quite serious HW problems that are probably related to the serial connection between the PC, CAN bus and the laser scanner. Basically, we get this kernel message:

[33075.354321] usb 2-1.8: USB disconnect, device number 6
[33075.354696] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
[33075.354725] ftdi_sio 2-1.8:1.0: device disconnected
[33075.355070] ftdi_sio ttyUSB1: FTDI USB Serial Device converter now disconnected from ttyUSB1
[33075.355091] ftdi_sio 2-1.8:1.1: device disconnected
[33075.355186] ftdi_sio ttyUSB2: error from flowcontrol urb
[33075.355261] ftdi_sio ttyUSB2: FTDI USB Serial Device converter now disconnected from ttyUSB2
[33075.355274] ftdi_sio 2-1.8:1.2: device disconnected
[33075.355410] ftdi_sio ttyUSB3: FTDI USB Serial Device converter now disconnected from ttyUSB3
[33075.355428] ftdi_sio 2-1.8:1.3: device disconnected

and we have to completely restart the robot. This happens several times a day.

Udev rules

@chmartin21 :
Hi,
I have a question regarding numbering the robot devices:

Sometimes (30% of cases), the ROS fails to start, because neither the SICK nor CAN are sending data. Trying to launch ROS again does not help and the only solution is rebooting the PC. I had a look at the system configuration and found out that both the SICK and CAN are connected through an quad FTDI and appear as ttyUSB0 and ttyUSB2 respectively.

So my question is if it might happen that the ttyUSB0 and ttyUSB2 might swap occationally, so ROS would try to communicate with the SICK thinking it is the CAN and vice versa.

try/catch in driver code

The driver code needs exception handling to address issue #10.

CAN bus

CAN bus tends to crash:

SerialCommS300: Checksum's dont match, thats bad (data packet size 1104)
SerialCommS300: Checksum's dont match, thats bad (data packet size 1104)
[WARNING ] 2013-Aug-01 09:58:43.025712 Invalid CRC on MetraLabs CAN-to-Serial Adapter. Is 0xe471 should 0x1400
[WARNING ] 2013-Aug-01 09:58:43.750912 Invalid CRC on MetraLabs CAN-to-Serial Adapter. Is 0x36aa should 0x8152
terminate called after throwing an instance of 'boost::exception_detail::clone_impl<mira::XRPC>'
  what():  Failed to read SDO node(0x08) index(0x2006) subindex (0x01) (/home/chmartin/release/MIRA-commercial/toolboxes/CAN/include/can/CANOpenSDOClient.h:134)
[ERROR   ] 2013-Aug-01 09:58:44.483837 Aborted!
[CALLSTACK]:
#0  0x7f522f201425 in gsignal from /lib/x86_64-linux-gnu/libc.so.6
    at /build/buildd/eglibc-2.15/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x7f522f204b8b in abort from /lib/x86_64-linux-gnu/libc.so.6
    at /build/buildd/eglibc-2.15/stdlib/abort.c:91
#2  0x7f522fb5469d in __gnu_cxx::__verbose_terminate_handler() from libstdc++.so.6
#3  0x7f522fb52846 in  from libstdc++.so.6
#4  0x7f522fb52873 in  from libstdc++.so.6
#5  0x7f522fb5296e in  from libstdc++.so.6
#6  0x63eabc in boost::exception_detail::clone_impl<mira::XRPC>::rethrow() const from scitos_node
#7  0x61f088 in boost::rethrow_exception(boost::shared_ptr<boost::exception_detail::clone_base const> const&) from scitos_node
#8  0x61f788 in boost::detail::future_object_base::wait(bool) from scitos_node
#9  0x62cd81 in boost::detail::future_object<std::string>::get() from scitos_node
#10  0x6298d9 in boost::unique_future<std::string>::get() from scitos_node
#11  0x62418c in mira::RPCFuture<std::string>::get() from scitos_node
#12  0x61ca0f in ScitosModule::get_mira_param_(std::string) from scitos_node
#13  0x715056 in ScitosHead::publish_joint_state_actual() from scitos_node
#14  0x71bca0 in boost::_mfi::mf0<void, ScitosHead>::operator()(ScitosHead*) const from scitos_node
#15  0x71af44 in void boost::_bi::list1<boost::_bi::value<ScitosHead*> >::operator()<boost::_mfi::mf0<void, ScitosHead>, boost::_bi::list0>(boost::_bi::type<void>, boost::_mfi::mf0<void, ScitosHead>&, boost::_bi::list0&, int) from scitos_node

OpenNi2 wrapper image_view error

When trying to run image_view with the depth/image_raw

rosrun image_view image_view image:=/head_xtion/depth/image_raw

I get the following error and nothing happens

[ERROR] [1394539150.828771105]: Unable to convert '16UC1' image to bgr8: '[16UC1] is not a color format. but [bgr8] is. The conversion does not make sense'

Does anyone else have the same problem?

Upgrading RAM on Central PC

Hi we upgraded Linda's RAM to 8GB this week and its working quite well, we think all robots would benefit a lot from doing this, sadly we didn't document the process thoroughly, but I'm posting a picture of the reference for the memories we used, and the one we removed from Linda:

to fit them in you just need to carefully gain access to the PC in your robot and replace as you would in any other PC.

Robot's PC fails to start

Sometimes - (approx. 20% of cases), the PC fails to start properly and gets stuck in this screen,
. The F2 and del keys do not do anything.

This requires to turn on and off the PC by means of the small control screen at the robot base - i.e. human intervention and prevents to use a PC reboot as a "last-resort" recovery strategy.

Anyone experiencing this as well?
@chmartin21 : Is the PC supposed not to boot reliably? Would it be possible to use a HW watchdog to resolve this issue ? Do you offer such a watchdog with SCITOS-G5 ? Is there an external signal line to reset the PC if we wanted to make our own hardware based watchdog ?

Linda not able to deal with a 10% slope

A ~4 meter long ramp with ~0.4m elevation has been installed in our place so Linda can access the other part of the offices. However, when we have tried to drive her up by joystick, her speed is gradually decreasing and she stops at ~1.2m of the ramp. Moreover, she cannot turn while moving forwards. According to the SCITOS-G5 flyer here: http://metralabs.com/images/ML_Downloads/Flyer_SCITOS_G5_Features_2.pdf, the robot should be able to deal with a 10% slope.

@chmartin21 : Any solution for that ?

Scitos dashboard free-run

Sometimes the freerun button needs pressing twice before the robot goes into freerun.

Linda shuts down completely without any obvious reason

We discovered that our robot (PC and the base) shut down completely several times a day without any obvious reason. It started recently; yesterday for all we know. So far it happened three times: once in the middle of the room while patrolling and twice when she tried to dock. Before the charging started she just turned off everything.
Is there any reason why this could happen, @chmartin21 ? The battery is at 98% but she just shut down regardless.

Linda is NOT charging anymore

Linda is not charging anymore, she completely ran out of battery whilst being at the charging station we have disconnected all the PCs and plugged the charging cable, the LCD display was on for a while but didn't show any current information after a while it quickly shows -13 A to immediately change to 0.1 A it stays there shortly and then it completely shuts down. we also plugged all the PCs back on and the current was still 0.1 A

Also whilst at the charging station the charging led is on. we think that the charging unit might be broken or that the current is not being meassured correctly any more is there anything we can do @chmartin21 @ml-stu

Occasional odometry glitch

When going through the data from Y3 deployment, we found an issue that seems to originate from the odometric subsystem. According to the logs from Y3 deployment at AAF, there were 6 events when the robot got lost due to a probable bug in the odometric module of the robot. All of these happened in the same area:

At AAF, there is a double wing door with a steel frame, which is on the floor. You can see it at 2:16-2:18 in this video: https://www.youtube.com/watch?v=tmYJ1DMwF2M. When the robot passes through that door, its odometry occasionally (in 6 cases out of ~270) jumps by ~10m or more. Normally, I would attribute this to a wheel skid or wheel stuck, but this glitch affects only x,y position, but not the orientation published over the /odom topic.

Moreover, while the robot forward velocity reported by /odom normally corresponds to the change in the robot x,y position, it does not correspond to it in these cases. The reported speed is sometimes unrealistically high, but still far away from ~100m/s that would correspond to the sudden jump in robot position.

The relevant logs and rosbags of these events are available here:
https://lcas.lincoln.ac.uk/owncloud/index.php/s/qrZ1nAsGpPIt1I6

Any idea what could be the cause of that ?

MIRA installation not working

Hi,

I installed the 64-bit ubuntu on the robot, now am trying to do the MIRA installation in /opt/MIRA I am following the exact procedure for the 64-bit system but it stops working when it reaches (INFO: Add installation repository) this is what I get on the screen and then it just stops there !

INFO: Create install directory...
INFO: Downloading MIRAEnvironment...
INFO: Downloading MIRA external...
INFO: Downloading MIRABase...
INFO: Downloading MIRAPackage...
INFO: Unzip MIRAenvironment...
INFO: Unzip MIRA external...
INFO: Unzip MIRABase...
INFO: Unzip MIRAPackage...
INFO: Fixing directory names in MIRA base system.
INFO: Clear repositories.
INFO: Add installation repository
INFO: Reindex installation repository

Muhannad / Leeds

openni wrapper does not publish depth/image

Is there a reason for the new openni wrapper not to publish /camera_ns/depth/image but just image_raw and image_rect? Also image_raw does not seem to use image_transport and is therefore not compressed.
Not having much to do with vision in general I don't really know what the difference between image and image_raw is so maybe I can just use the raw one?

Error in charger

Hi we just had a funny error in the charger Linda was docked but not charging and the charging station had the charging and error LEDs blinking.

(Sorry about the picture it wasn't easy to take it when the lights were on)

We tried to solved it by undocking and placing Linda back in the station but it didn't work, and then we unplugged the station until all lights went off and then plug it again and that solved the problem (classic rebooting), however, we would like to know what this means, @chmartin21 can you tell us?

OpenNi2 wrapper: change in image format?

I am in the process of migrating the perception people stuff to use the new openni2 wrapper. I encounter a problem which I can't figure out because I am not a vision guy and not very much into openni.
I have changed all the relevant topics to listen to the right messages but I don't get any detections. If I switch back to the old openni it works. So my question is: what changed?

Before I used:

depth/image
rgb/image_color
rgb/image_mono
rgb/camera_info

Now I use:

depth/image_rect (also tried raw)
depth/image_rect_color
depth/image_rect
rgb/camera_info (also tried the depth version)

Anyone any ideas why that might not work anymore? Has there been a change in the output, format, calibration parameters, etc.?

[scitos_bringup] sicks300 defaults to send_transform

This means that the sicks300 driver is broadcasting a tf transform. Since we are also doing it in the state_publisher, the laser frame jumps around. Could be solved by passing send_transform:=false to sick300_driver in s300.launch.

determine camera topics

Is there an easy way to fix which cam broadcasts on which topic? Currently our chest and image topics are swapped. I think I saw something about this somewhere, but can't find it now.

Restore this repo

I think we should re-instate this repository. The scitos_pc_monitor package belongs here as does a basic generic scitos_bringup. As the strands robots are not just scitos robots, we should then have another repo strands_robot that contains the strands_bringup package. I don't think scitos_bringup belongs in scitos_drivers.

scitos_drivers now no longer has a laser driver, and probably will eventually not have a ptu driver either since it is not a scitos specific device. So maybe we could move scitos_mira into this repo and remove scitos_drivers.

Replacing Battery in Linda?

One of the battery cells in Linda is apparently damaged according to analysis ran by metralabs over this mira tape. @creuther what is the recommended course of actions here?

[pc_monitor] AttributeError: 'NoneType' object has no attribute 'group'

When trying to run the pc_monitor I get:

process[pc_monitor-5]: started with pid [4704]
process[diagnostic_aggregator-6]: started with pid [4709]
process[joint_state_publisher-7]: started with pid [4731]
[ INFO] [1401964398.543195021]: Not loading with MIRA multiprocess support.
Exception in thread Thread-10:
Traceback (most recent call last):
  File "/usr/lib/python2.7/threading.py", line 551, in __bootstrap_inner
    self.run()
  File "/usr/lib/python2.7/threading.py", line 759, in run
    self.function(*self.args, **self.kwargs)
  File "/opt/strands/strands_hydro_ws/src/scitos_robot/scitos_pc_monitor/src/sysmon/status_monitor.py", line 32, in _on_timer
    self.update()
  File "/opt/strands/strands_hydro_ws/src/scitos_robot/scitos_pc_monitor/src/sysmon/network_monitor.py", line 21, in update
    self._transmit_total = int(m.group(2))
AttributeError: 'NoneType' object has no attribute 'group'

It is launched via the scitos bringup files.

Also it hogs a lot of memory even though - or maybe because - it doesn't launch properly.

slow cameras on betty

Our setup in betty is the head cam on the right pc, and the chest cam on the main one. I'm having issues with the cam topics frequency which might be problematic.

The chest works at normal rate (30) for depth, but it's intermittent for rgb. Note that for this one there's no network issues as all is in the main pc:

strands@betty:~$ rostopic hz /chest_xtion/depth/image_raw                                                                                              
subscribed to [/chest_xtion/depth/image_raw]
average rate: 29.922
        min: 0.030s max: 0.038s std dev: 0.00163s window: 29
average rate: 29.976
        min: 0.030s max: 0.038s std dev: 0.00140s window: 59
average rate: 29.960
        min: 0.030s max: 0.038s std dev: 0.00138s window: 89
average rate: 29.964
        min: 0.030s max: 0.038s std dev: 0.00141s window: 118
average rate: 29.957
        min: 0.030s max: 0.038s std dev: 0.00137s window: 149
average rate: 29.964

strands@betty:~$ rostopic hz /chest_xtion/rgb/image_raw                                                                                                
subscribed to [/chest_xtion/rgb/image_raw]
average rate: 14.167
        min: 0.028s max: 0.134s std dev: 0.03701s window: 9
average rate: 14.957
        min: 0.028s max: 0.239s std dev: 0.05528s window: 27
average rate: 15.843
        min: 0.028s max: 0.239s std dev: 0.05137s window: 44
average rate: 16.407
        min: 0.027s max: 0.239s std dev: 0.04575s window: 62
average rate: 19.048
        min: 0.027s max: 0.239s std dev: 0.03974s window: 91
average rate: 19.208
        min: 0.027s max: 0.239s std dev: 0.03873s window: 102
no new messages
no new messages
no new messages
no new messages
no new messages
no new messages
no new messages
no new messages
average rate: 7.368
        min: 0.027s max: 8.585s std dev: 0.84163s window: 103
no new messages

The head seems to have some issues due to the network not being fast enough. I don't know if these rates are ok:

strands@betty:~$ rostopic hz /head_xtion/depth/image_raw
subscribed to [/head_xtion/depth/image_raw]
average rate: 19.010
        min: 0.051s max: 0.053s std dev: 0.00050s window: 18
average rate: 19.013
        min: 0.051s max: 0.054s std dev: 0.00060s window: 37
^Caverage rate: 19.010
        min: 0.051s max: 0.054s std dev: 0.00060s window: 54

strands@betty:~$ rostopic hz /head_xtion/rgb/image_raw
subscribed to [/head_xtion/rgb/image_raw]
average rate: 12.674
        min: 0.076s max: 0.082s std dev: 0.00144s window: 11
average rate: 12.669
        min: 0.076s max: 0.082s std dev: 0.00106s window: 24
average rate: 12.672
        min: 0.076s max: 0.082s std dev: 0.00087s window: 37
average rate: 12.673
        min: 0.076s max: 0.082s std dev: 0.00077s window: 49
^Caverage rate: 12.674
        min: 0.076s max: 0.082s std dev: 0.00074s window: 59

Can someone that know how cameras are supposed to work tell me something about this? Are the head rates something to worry about? What's going on with chest rgb publishing?

refactoring and preparing release

This repository shall be removed:

scitos_pc_monitor should be moved to scitos_apps (if it is scitos-specific; if it's not, but in general useful and doesn't exist in the ROS universe yet, I suggest to separate it out.)
bringup launch file are STRANDS specific and should be moved (question to @hawesie: where? I suggest to make it part of scitos_common which also has a number of files in it that are specific to our robots, like the urdf definitions with cameras and sensors. So it feels like the launch files actually would belong there? We might also consider changing the name of the packages to reflect that this is about our specific robot, e.g scitos_g5s_description rather than scitos_description, but that's not crucial)
Wiki content at https://github.com/strands-project/scitos_robot/wiki/Setup needs to be moved https://github.com/strands-project/strands_management/wiki/Robot-Setup (and outdated stuff removed)
create install targets in the CMakeLists.txt for all packages and fix email, maintainer, etc. in package.xml
the run_depend should be filled for scitos_bringup (I wonder if one could write a little script that digs through all the *.launch files and figures out what package are needed...)
eventually delete the repo

@cburbridge I had your name against this repo, will you take care of it?

robot problem (CAN?)

Our robot didn't quite make it through the night. This morning I was just right there before the batteries got completely flat. Don't know how long it had been standing there and what really was the problem.
Anyway, this is the output of the bringup file. Maybe someone can help. Some side notes, Ubuntu's performance was really slow, /head_xtion stopped publishing, rostopic echo /mileage doesn't output anymore,...

[ INFO] [1384869592.836217097]: Going into main loop.
[ INFO] [1384869594.769535902]: Stopping to publish chest transform after 10 seconds, quitting...
[chest_calibration_publisher-26] process has finished cleanly
log file: /localhome/strands/.ros/log/cea77160-5122-11e3-a785-6c8814462a8c/chest_calibration_publisher-26*.log
Device "1d27/0601@2/3" error state changed to 2
Device "1d27/0601@2/3" error state changed to 0
Device "1d27/0601@2/3" error state changed to 2
Device "1d27/0601@2/3" error state changed to 0
Device "1d27/0601@2/3" error state changed to 2
Device "1d27/0601@2/3" error state changed to 0
Device "1d27/0601@2/3" error state changed to 2
Device "1d27/0601@2/3" error state changed to 0
[ WARN] [1384872152.007390162]: (MIRA) Dropping data (slot) in channel '/robot/RobotFrame' since slot with same timestamp already exists
[WARNING ] 2013-Nov-19 15:42:31.235056 Dropping data (slot) in channel '/robot/RobotFrame' since slot with same timestamp already exists
[ WARN] [1384872152.748707889]: (MIRA) Dropping data (slot) in channel '/robot/Mileage' since slot with same timestamp already exists
[WARNING ] 2013-Nov-19 15:42:32.748641 Dropping data (slot) in channel '/robot/Mileage' since slot with same timestamp already exists
[ WARN] [1384872152.749160210]: (MIRA) Dropping data (slot) in channel '/robot/Odometry' since slot with same timestamp already exists
[WARNING ] 2013-Nov-19 15:42:32.749143 Dropping data (slot) in channel '/robot/Odometry' since slot with same timestamp already exists
[ WARN] [1384872153.095865653]: Missing head angle publication as MIRA parameter error.
[ WARN] [1384872422.863033285]: (MIRA) Dropping data (slot) in channel '/robot/RobotFrame' since slot with same timestamp already exists
[WARNING ] 2013-Nov-19 15:47:02.862982 Dropping data (slot) in channel '/robot/RobotFrame' since slot with same timestamp already exists
[ WARN] [1384872422.863186082]: (MIRA) Dropping data (slot) in channel '/robot/Mileage' since slot with same timestamp already exists
[WARNING ] 2013-Nov-19 15:47:02.863171 Dropping data (slot) in channel '/robot/Mileage' since slot with same timestamp already exists
[ WARN] [1384872422.863254878]: (MIRA) Dropping data (slot) in channel '/robot/Odometry' since slot with same timestamp already exists
[WARNING ] 2013-Nov-19 15:47:02.863241 Dropping data (slot) in channel '/robot/Odometry' since slot with same timestamp already exists
[ WARN] [1384876577.769742822]: (MIRA) Dropping data (slot) in channel '/robot/RobotFrame' since slot with same timestamp already exists
[WARNING ] 2013-Nov-19 16:56:17.732940 Dropping data (slot) in channel '/robot/RobotFrame' since slot with same timestamp already exists
[ WARN] [1384876577.850097063]: (MIRA) Dropping data (slot) in channel '/robot/Mileage' since slot with same timestamp already exists
[WARNING ] 2013-Nov-19 16:56:17.850044 Dropping data (slot) in channel '/robot/Mileage' since slot with same timestamp already exists
[ WARN] [1384876577.850208616]: (MIRA) Dropping data (slot) in channel '/robot/Odometry' since slot with same timestamp already exists
[WARNING ] 2013-Nov-19 16:56:17.850194 Dropping data (slot) in channel '/robot/Odometry' since slot with same timestamp already exists
[ WARN] [1384876994.678674663]: (MIRA) Dropping data (slot) in channel '/robot/RobotFrame' since slot with same timestamp already exists
[WARNING ] 2013-Nov-19 17:03:14.678632 Dropping data (slot) in channel '/robot/RobotFrame' since slot with same timestamp already exists
[ WARN] [1384876994.678854826]: (MIRA) Dropping data (slot) in channel '/robot/Mileage' since slot with same timestamp already exists
[WARNING ] 2013-Nov-19 17:03:14.678835 Dropping data (slot) in channel '/robot/Mileage' since slot with same timestamp already exists
[ WARN] [1384876994.678914470]: (MIRA) Dropping data (slot) in channel '/robot/Odometry' since slot with same timestamp already exists
[WARNING ] 2013-Nov-19 17:03:14.678902 Dropping data (slot) in channel '/robot/Odometry' since slot with same timestamp already exists
[ WARN] [1384886160.005209726]: (MIRA) Dropping data (slot) in channel '/robot/RobotFrame' since slot with same timestamp already exists
[WARNING ] 2013-Nov-19 19:35:59.977748 Dropping data (slot) in channel '/robot/RobotFrame' since slot with same timestamp already exists
[ WARN] [1384886160.025040756]: (MIRA) Dropping data (slot) in channel '/robot/Mileage' since slot with same timestamp already exists
[WARNING ] 2013-Nov-19 19:36:00.024980 Dropping data (slot) in channel '/robot/Mileage' since slot with same timestamp already exists
[ WARN] [1384886160.025145959]: (MIRA) Dropping data (slot) in channel '/robot/Odometry' since slot with same timestamp already exists
[WARNING ] 2013-Nov-19 19:36:00.025124 Dropping data (slot) in channel '/robot/Odometry' since slot with same timestamp already exists
[ WARN] [1384893595.160455543]: (MIRA) Dropping data (slot) in channel '/robot/RobotFrame' since slot with same timestamp already exists
[WARNING ] 2013-Nov-19 21:39:55.160382 Dropping data (slot) in channel '/robot/RobotFrame' since slot with same timestamp already exists
[ WARN] [1384893595.160660839]: (MIRA) Dropping data (slot) in channel '/robot/Mileage' since slot with same timestamp already exists
[WARNING ] 2013-Nov-19 21:39:55.160647 Dropping data (slot) in channel '/robot/Mileage' since slot with same timestamp already exists
[ WARN] [1384893595.160718484]: (MIRA) Dropping data (slot) in channel '/robot/Odometry' since slot with same timestamp already exists
[WARNING ] 2013-Nov-19 21:39:55.160706 Dropping data (slot) in channel '/robot/Odometry' since slot with same timestamp already exists
[ WARN] [1384894764.773859064]: (MIRA) Dropping data (slot) in channel '/robot/RobotFrame' since slot with same timestamp already exists
[WARNING ] 2013-Nov-19 21:59:24.773792 Dropping data (slot) in channel '/robot/RobotFrame' since slot with same timestamp already exists
[ WARN] [1384894764.774037007]: (MIRA) Dropping data (slot) in channel '/robot/Mileage' since slot with same timestamp already exists
[WARNING ] 2013-Nov-19 21:59:24.774023 Dropping data (slot) in channel '/robot/Mileage' since slot with same timestamp already exists
[ WARN] [1384894764.774093594]: (MIRA) Dropping data (slot) in channel '/robot/Odometry' since slot with same timestamp already exists
[WARNING ] 2013-Nov-19 21:59:24.774081 Dropping data (slot) in channel '/robot/Odometry' since slot with same timestamp already exists
[ WARN] [1384903147.790232950]: (MIRA) Dropping data (slot) in channel '/robot/RobotFrame' since slot with same timestamp already exists
[WARNING ] 2013-Nov-20 00:19:07.790143 Dropping data (slot) in channel '/robot/RobotFrame' since slot with same timestamp already exists
[ WARN] [1384903147.790513796]: (MIRA) Dropping data (slot) in channel '/robot/Mileage' since slot with same timestamp already exists
[WARNING ] 2013-Nov-20 00:19:07.790493 Dropping data (slot) in channel '/robot/Mileage' since slot with same timestamp already exists
[ WARN] [1384903147.790586999]: (MIRA) Dropping data (slot) in channel '/robot/Odometry' since slot with same timestamp already exists
[WARNING ] 2013-Nov-20 00:19:07.790570 Dropping data (slot) in channel '/robot/Odometry' since slot with same timestamp already exists
[ WARN] [1384905544.775379862]: (MIRA) Dropping data (slot) in channel '/robot/RobotFrame' since slot with same timestamp already exists
[WARNING ] 2013-Nov-20 00:59:04.775314 Dropping data (slot) in channel '/robot/RobotFrame' since slot with same timestamp already exists
[ WARN] [1384905544.775540205]: (MIRA) Dropping data (slot) in channel '/robot/Mileage' since slot with same timestamp already exists
[WARNING ] 2013-Nov-20 00:59:04.775525 Dropping data (slot) in channel '/robot/Mileage' since slot with same timestamp already exists
[ WARN] [1384905544.775601030]: (MIRA) Dropping data (slot) in channel '/robot/Odometry' since slot with same timestamp already exists
[WARNING ] 2013-Nov-20 00:59:04.775588 Dropping data (slot) in channel '/robot/Odometry' since slot with same timestamp already exists
[ INFO] [1384932725.147267923]: Bond broken, exiting
[ WARN] [1384932725.675887900]: [image_transport] Topics '/chest_xtion/depth/image_rect' and '/chest_xtion/depth/camera_info' do not appear to be synchronized. In the last 10s:
    Image messages received:      5
    CameraInfo messages received: 100
    Synchronized pairs:           5
[ WARN] [1384932744.238248693]: [image_transport] Topics '/chest_xtion/depth/image_raw' and '/chest_xtion/depth/camera_info' do not appear to be synchronized. In the last 10s:
    Image messages received:      71
    CameraInfo messages received: 35
    Synchronized pairs:           22
[ERROR] [1384932749.413674398]: (MIRA) /robot/can/CANDriver Recovering: : Incoming message watchdog triggered. No incoming messages.
SerialCommS300: Checksum's dont match, thats bad (data packet size 1104)
SerialCommS300: Checksum's dont match, thats bad (data packet size 1104)
SerialCommS300: Checksum's dont match, thats bad (data packet size 1104)
[ WARN] [1384932750.832333080]: [image_transport] Topics '/chest_xtion/depth/image_rect' and '/chest_xtion/depth/camera_info' do not appear to be synchronized. In the last 10s:
    Image messages received:      0
    CameraInfo messages received: 5
    Synchronized pairs:           0
SerialCommS300: Checksum's dont match, thats bad (data packet size 1104)
[ WARN] [1384932752.973730776]: [image_transport] Topics '/chest_xtion/depth/image_rect' and '/chest_xtion/depth/camera_info' do not appear to be synchronized. In the last 10s:
    Image messages received:      0
    CameraInfo messages received: 19
    Synchronized pairs:           0
SerialCommS300: Checksum's dont match, thats bad (data packet size 1104)
[ WARN] [1384932762.974158674]: [image_transport] Topics '/chest_xtion/depth/image_rect' and '/chest_xtion/depth/camera_info' do not appear to be synchronized. In the last 10s:
    Image messages received:      0
    CameraInfo messages received: 46
    Synchronized pairs:           0
[ERROR   ] 2013-Nov-20 08:32:10.132588 /robot/can/CANDriver Recovering: : Incoming message watchdog triggered. No incoming messages.
[ WARN] [1384932772.973492116]: [image_transport] Topics '/chest_xtion/depth/image_rect' and '/chest_xtion/depth/camera_info' do not appear to be synchronized. In the last 10s:
    Image messages received:      0
    CameraInfo messages received: 48
    Synchronized pairs:           0
[ WARN] [1384932782.973841912]: [image_transport] Topics '/chest_xtion/depth/image_rect' and '/chest_xtion/depth/camera_info' do not appear to be synchronized. In the last 10s:
    Image messages received:      1
    CameraInfo messages received: 7
    Synchronized pairs:           0
[ WARN] [1384932784.087723036]: Missing head angle publication as MIRA parameter error.
SerialCommS300: Checksum's dont match, thats bad (data packet size 1104)
[ WARN] [1384932812.974128101]: [image_transport] Topics '/chest_xtion/depth/image_rect' and '/chest_xtion/depth/camera_info' do not appear to be synchronized. In the last 10s:
    Image messages received:      9
    CameraInfo messages received: 88
    Synchronized pairs:           8
[scitos_node-1] process has died [pid 22473, exit code -9, cmd /opt/strands/strands_catkin_ws/devel/lib/scitos_mira/scitos_node __name:=scitos_node __log:=/localhome/strands/.ros/log/cea77160-5122-11e3-a785-6c8814462a8c/scitos_node-1.log].
log file: /localhome/strands/.ros/log/cea77160-5122-11e3-a785-6c8814462a8c/scitos_node-1*.log
[ WARN] [1384932841.514991283]: [image_transport] Topics '/head_xtion/depth/image_raw' and '/head_xtion/depth/camera_info' do not appear to be synchronized. In the last 10s:
    Image messages received:      242
    CameraInfo messages received: 56
    Synchronized pairs:           48
[ WARN] [1384932845.557894860]: [image_transport] Topics '/head_xtion/depth/image_rect' and '/head_xtion/depth/camera_info' do not appear to be synchronized. In the last 10s:
    Image messages received:      43
    CameraInfo messages received: 146
    Synchronized pairs:           43
[OpenniWrapperNodelet-6] process has finished cleanly
log file: /localhome/strands/.ros/log/cea77160-5122-11e3-a785-6c8814462a8c/OpenniWrapperNodelet-6*.log
[points_head_xtion-11] process has finished cleanly
log file: /localhome/strands/.ros/log/cea77160-5122-11e3-a785-6c8814462a8c/points_head_xtion-11*.log
respawning...
[register_depth_rgb_head_xtion-12] process has finished cleanly
log file: /localhome/strands/.ros/log/cea77160-5122-11e3-a785-6c8814462a8c/register_depth_rgb_head_xtion-12*.log
[points_chest_xtion-19] process has finished cleanly
log file: /localhome/strands/.ros/log/cea77160-5122-11e3-a785-6c8814462a8c/points_chest_xtion-19*.log
respawning...
[register_depth_rgb_chest_xtion-20] process has finished cleanly
log file: /localhome/strands/.ros/log/cea77160-5122-11e3-a785-6c8814462a8c/register_depth_rgb_chest_xtion-20*.log
[points_head_xtion-11] restarting process
process[points_head_xtion-11]: started with pid [1040]
[points_chest_xtion-19] restarting process
process[points_chest_xtion-19]: started with pid [1047]
[FATAL] [1384932913.578187542]: Service call failed!
[manager-7] process has died [pid 22569, exit code -11, cmd /opt/ros/groovy/lib/nodelet/nodelet manager __name:=manager __log:=/localhome/strands/.ros/log/cea77160-5122-11e3-a785-6c8814462a8c/manager-7.log].
log file: /localhome/strands/.ros/log/cea77160-5122-11e3-a785-6c8814462a8c/manager-7*.log
[points_head_xtion-11] process has died [pid 1040, exit code 255, cmd /opt/ros/groovy/lib/nodelet/nodelet load depth_image_proc/point_cloud_xyz manager image_rect:=head_xtion/depth/image_rect /points:=head_xtion/depth/points /camera_info:=head_xtion/depth/camera_info __name:=points_head_xtion __log:=/localhome/strands/.ros/log/cea77160-5122-11e3-a785-6c8814462a8c/points_head_xtion-11.log].
log file: /localhome/strands/.ros/log/cea77160-5122-11e3-a785-6c8814462a8c/points_head_xtion-11*.log
respawning...
[points_head_xtion-11] restarting process
process[points_head_xtion-11]: started with pid [1272]

and scitos_2d_nav.launch says:

[ INFO] [1384883001.273491987]: Got new plan
[ INFO] [1384883001.773349971]: Got new plan
[ INFO] [1384883002.275993347]: Got new plan
[ INFO] [1384883002.373408537]: Goal reached
[ WARN] [1384922148.221897534]: Costmap2DROS transform timeout. Current time: 1384922148.2218, global_pose stamp: 1384922147.8519, tolerance: 0.3000
[ WARN] [1384922148.257584536]: Could not get robot pose, cancelling reconfiguration
[ WARN] [1384930780.610560254]: Costmap2DROS transform timeout. Current time: 1384930780.0149, global_pose stamp: 1384930779.7019, tolerance: 0.3000
[ WARN] [1384930781.391727465]: Map update loop missed its desired rate of 3.0000Hz... the loop actually took 1.4018 seconds
[ WARN] [1384932675.389041757]: Costmap2DROS transform timeout. Current time: 1384932671.7345, global_pose stamp: 1384932671.4295, tolerance: 0.3000
[ WARN] [1384932678.539124583]: Costmap2DROS transform timeout. Current time: 1384932672.9899, global_pose stamp: 1384932671.4295, tolerance: 0.3000
[ WARN] [1384932678.539253875]: Map update loop missed its desired rate of 3.0000Hz... the loop actually took 5.5494 seconds
[ WARN] [1384932678.539370332]: Costmap2DROS transform timeout. Current time: 1384932678.5391, global_pose stamp: 1384932671.4295, tolerance: 0.3000
[ WARN] [1384932678.539426978]: Could not get robot pose, cancelling reconfiguration
[ WARN] [1384932678.539490209]: Map update loop missed its desired rate of 3.0000Hz... the loop actually took 6.8140 seconds
[ WARN] [1384932679.539277823]: Costmap2DROS transform timeout. Current time: 1384932679.5391, global_pose stamp: 1384932671.4295, tolerance: 0.3000
[ WARN] [1384932680.539427932]: Costmap2DROS transform timeout. Current time: 1384932680.5393, global_pose stamp: 1384932671.4295, tolerance: 0.3000
[ WARN] [1384932689.757121879]: No laser scan received (and thus no pose updates have been published) for 16.562042 seconds.  Verify that data is being published on the /scan topic.
[ WARN] [1384932700.995800950]: No laser scan received (and thus no pose updates have been published) for 29.619926 seconds.  Verify that data is being published on the /scan topic.
[ERROR] [1384932702.550053040]: Extrapolation Error looking up robot pose: Unable to lookup transform, cache is empty, when looking up transform from frame [/base_link] to frame [/map]

[ WARN] [1384932703.330948674]: Could not get robot pose, cancelling reconfiguration
[ WARN] [1384932703.331059452]: Map update loop missed its desired rate of 3.0000Hz... the loop actually took 21.0109 seconds
[ WARN] [1384932703.331178406]: Map update loop missed its desired rate of 3.0000Hz... the loop actually took 21.0107 seconds
[ERROR] [1384932703.331277375]: Extrapolation Error looking up robot pose: Unable to lookup transform, cache is empty, when looking up transform from frame [/base_link] to frame [/map]

[ WARN] [1384932703.331370677]: Map update loop missed its desired rate of 3.0000Hz... the loop actually took 0.7812 seconds
[ WARN] [1384932703.331486854]: Map update loop missed its desired rate of 3.0000Hz... the loop actually took 0.7813 seconds
[ERROR] [1384932704.331442559]: Extrapolation Error looking up robot pose: Unable to lookup transform, cache is empty, when looking up transform from frame [/base_link] to frame [/map]

[ WARN] [1384932704.913652927]: Map update loop missed its desired rate of 3.0000Hz... the loop actually took 0.5824 seconds
[ERROR] [1384932705.331483996]: Extrapolation Error looking up robot pose: Unable to lookup transform, cache is empty, when looking up transform from frame [/base_link] to frame [/map]

[ WARN] [1384932705.902567245]: Could not get robot pose, cancelling reconfiguration
[ERROR] [1384932706.403795536]: Extrapolation Error looking up robot pose: Unable to lookup transform, cache is empty, when looking up transform from frame [/base_link] to frame [/map]

[ WARN] [1384932706.903099838]: Could not get robot pose, cancelling reconfiguration
[ERROR] [1384932707.503672036]: Extrapolation Error looking up robot pose: Unable to lookup transform, cache is empty, when looking up transform from frame [/base_link] to frame [/map]

No continuous charging anymore

I just observed a weird behaviour of the charging station:

Today I found our robot sitting on the station with a dead battery. The key was set to "on" so it must have been charging while on the station. I switched the robot on and the charging immediately began. The only problem was, that the charging was not continuous but the LED was blinking in 1 second intervals like when the battery is at 100% (see issue #26 and this link for a video: http://youtu.be/IW-odD6zXOk). The answer to our question if this behaviour is intended was: @ml-stu "Yes, it is right when the embedded pc is shut down ant the batteries are at 100% charge." But we still observed this behaviour even when the embedded PC and our version of the mira bridge was running.

Now the station seems to do this all the time even if the battery is at 0%. The voltage alternates between 3 and -1 so it does not really charge even if the LED is on.

@ml-stu @chmartin21 any ideas what could cause this and how to fix it?

/camera/depth/disparity missing

I am just trying to get this (https://github.com/strands-project/strands_utils/tree/hydro-devel/driveable_floor_calib) working.

However, I am missing the disparity topic when using the openni_wrapper. Even though the topic /depth/disparity is shown at rostopic list, the qt based calibration tool does not show anything.

move openni stuff somewhere else

We think that this is not the right repository for the openni stuff. It should go into its own repository as other people out there might want to use this independently of our very robot-specific stuff. And we also want to include it in the desktop installation, as it's not specific to the robot.

Dashboard battery display not working

I get the following backtrace:

Node: /rqt_gui_py_node_18721
Time: 1374573994.174
Severity: Error
Published Topics: /diagnostics_toplevel_state, /battery_state, /rosout, /rosout_agg, /motor_status

bad callback: <bound method ScitosDashboard.battery_callback of <scitos_dashboard.scitos_dashboard.ScitosDashboard object at 0x4060cb0>>
Traceback (most recent call last):
  File "/opt/ros/groovy/lib/python2.7/dist-packages/rospy/topics.py", line 683, in _invoke_callback
    cb(msg)
  File "/opt/strands/strands_catkin_ws/src/scitos_robot/scitos_dashboard/src/scitos_dashboard/scitos_dashboard.py", line 59, in battery_callback
    self._batteries.set_power_state(msg)
  File "/opt/strands/strands_catkin_ws/src/scitos_robot/scitos_dashboard/src/scitos_dashboard/scitos_battery.py", line 46, in set_power_state
    self.update_perc(msg.relative_capacity)
AttributeError: 'BatteryState' object has no attribute 'relative_capacity'


Location:
topics.py:_invoke_callback:686

----------------------------------------------------------------------------------------------------

Robot battery

We just experienced another severe problem with our battery. While running the waypoint patroller, the battery level shown on the small display on the robot platform indicated a very low battery level (blinking symbol). However, the rostopic /battery_state still published life_percentage with 79%. The cell voltage was down to approx. 2.4V. As expected, the robot died in the middle of its patrol run.

Not sure if this is related to our problem with a fully charged robot turning off abruptly when it stays on the charging station. Metralabs offered a firmware update. Was just wondering if anyone else experienced such a big discrepancy between ROS battery_state and the battery level indicated on the platform.

Run chest camera on a different machine

is there a nice way of running each camera on a different PC?
I know that you can add this tag http://wiki.ros.org/roslaunch/XML/machine for choosing on which machine every node has to run, the problem is that the openni has so many launch files and nodes that I am not quite sure which is the best way to do it since we want to have as little data running between machines as possible.

@RaresAmbrus can you help us here

strands-project / scitos_robot Goto Github PK

scitos_robot's People

Contributors

Watchers

Forkers

scitos_robot's Issues

Recommend Projects

Recommend Topics

Recommend Org

Jobs