search

strands-project / scitos_robot

Everything related to the STRANDS robot hardware can go in here
0 stars 10 forks source link

Fast odometry causes over shooting #53

Open cdondrup opened 10 years ago

cdondrup commented 10 years ago

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?

hawesie commented 10 years ago

If something somewhere is doing processing on every odom update then this could be increasing load or tying up a thread when something else is trying to run.

cdondrup commented 10 years ago

Maybe @ml-stu @chmartin21 have an idea why that might happen?

chmartin21 commented 10 years ago

We never used a such high odometry update rate. For what do you need this? Usually, we use an OdometryInterval of 50ms (20Hz). This value should be enough for all navigation tasks.

cdondrup commented 10 years ago

We actually need an odometry rate of at least 25hz because some of the vision processing needs the odometry as well to transform the detections into world coordinates. It would be a shame if the vision (which is very heavy on the computation) is slowed down by the odometry which could be published with about 100hz normally.

hawesie commented 10 years ago

But does the vision really need it at this rate? Maybe this isn’t a discussion for this thread, but is seems a tough and slightly arbitrary requirement (which I think is not yours directly).

mzillich commented 10 years ago

I think only people detection will run while the robot is driving, so this is for Aachen people to decide. I would assume however that a slightly lower rate should not be a problem. But apart from that, we should know why this overshoot happens. Even 100 Hz update rate should be nothing in terms of computation or ROS messaging, right?

lucasb-eyer commented 10 years ago

As-is, the tracker doesn't support odometry at a much lower rate than the camera input and it would be quite some work to support that. I understand from this thread that 25Hz works fine, so please keep it there, or higher.

chmartin21 commented 10 years ago

Are you using the ROS navigation stack of MetraLabs CogniDrive for navigation?

We did some tests with one of our robots and the latest version of MIRA and CogniDrive: The smallest reasonable OdometryInterval is about 20ms, which results in an update rate of about 45Hz. Higher update rate are not supported by the hardware. Typically, we are using an update rate for 20Hz. But also at 45Hz no overshooting was visible during navigation.

If you really need an higher update rate, then there are two ways: The first solution would be to interpolate the odometry (see here: http://www.mira-project.org/MIRA-doc/PublisherSubscriberPage.html#ChannelInterpolate). The second solution is to set the property "CalculateOdometryFromDistance" to true. This way, the hardware sends the raw distance values from the motors at an update rate of 100Hz to the driver. And the driver computes the odometry at the same update rate. In this mode, the parameter OdometryInterval has no effect! This biggest disadvantage of this approach is, that the gyro angle will not be incorporated anymore in the odometry computation.

cdondrup commented 10 years ago

@chmartin21 we used to have the odometry at 20ms so 45hz which should be perfectly fine and observed no overshooting (due to the odomerty). That said, on the Vienna robot we had to reduce it after it came back from the repair. I don't know if some components changed but it couldn't handle the odometry.

I don't think we need any interpolation but at least the 45hz should be possible. I'm not sure if @gestom and @Jailander might need a faster odometry for navigation but for the vision it should be fine.

Regarding the components we use, maybe @cburbridge can give some insight on that.

cburbridge commented 9 years ago

@cdondrup Is the current odometry rate sufficient? The bug I fixed in ROS-MIRA brige helped with the overshooting...

cdondrup commented 9 years ago

I only observed this on Werner so I can't really tell if it is fixed.

ToMadoRe commented 9 years ago

I had to reinstall MIRA yesterday and just have this overshooting problem again... Help, help... we have a demo this afternoon.

cdondrup commented 9 years ago

Check the odometry frequency in SCITOS-G5.xml Don't know where it is located now though...

Jailander commented 9 years ago

It is here https://github.com/strands-project/scitos_drivers/blob/hydro-devel/scitos_mira/resources/SCITOS-G5.xml

cdondrup commented 9 years ago

That should be it. Try increasing the OdometryInterval value.

ToMadoRe commented 9 years ago

it is 20 atm... should I increase it to 40 or so?

cdondrup commented 9 years ago

yes

ToMadoRe commented 9 years ago

I set it to 50 and indeed it works :-)

cdondrup commented 9 years ago

Still strange why that only happens on Werner. Maybe @chmartin21 has some more insight on how that could be so robot specific. Are there hardware differences?

chmartin21 commented 9 years ago

First you should compare the firmware version of the MCU using the scitosFirmwareLoader.

bfalacerda commented 9 years ago

after the updates i had the exact same issue with bob

cdondrup commented 9 years ago

So something in the firmware has changed causing this. We haven't seen it on Linda ever and we still use the old firmware.

chmartin21 commented 9 years ago

Which firmware is installed on which robot?

cdondrup commented 9 years ago

Since Linda is currently not working, I can't check that I reckon.

bfalacerda commented 9 years ago

on bob:

 Found 7 CAN bus modules:
    (0): NodeID=0x01  S/N=10-000878  HWRev=B001E222_v4  SWRev=1.6.0     Main charger Li - 2011
    (1): NodeID=0x04  S/N=10-000809  HWRev=B001E215_v3  SWRev=1.8.9     Main control unit - 2011
    (2): NodeID=0x07  S/N=10-000894  HWRev=B001E220_v6  SWRev=1.1.2     Display module G5 - HG2
    (3): NodeID=0x08  S/N=10-000914  HWRev=B001E137_v4  SWRev=1.0.5     Head module G5 - 2010
    (4): NodeID=0x09  S/N=10-000237  HWRev=B001E139_v1  SWRev=1.3.0     Status display G5 - 2010
    (5): NodeID=0x0b  S/N=10-000982  HWRev=B001E305_v2  SWRev=1.0.2     Motion Tracking Module B001E322
    (6): NodeID=0x17  S/N=10-000752  HWRev=B001E034_v2  SWRev=1.1.0     EBC module G5
bfalacerda commented 9 years ago

what value were we using for OdometryInterval?

cdondrup commented 9 years ago

20 but that seems too fast for the new firmware

bfalacerda commented 9 years ago

so 20 is already after we made it slower to avoid the old overshoot issue?

I was checking with @creuther and the default value in mira is 50 right now. There's a new version of the firmware that handles higher frequencies though, so we might want to update again

cdondrup commented 9 years ago

No 20 is the fast one I set in the beginning of the project which results in 45hz.