Linda's mileage

[gestom]

Lindas mileage topic does not seem to work correctly during the last few days. Although her patrol runs are approximately 30m long, it's mileage topic increases only by ~10m each run. The topic was OK until Thu Nov 14 12:14:29.

[cburbridge]

I've not seen it here. What is the robots dosimetry reading like? Has that also gone bad?

[Jailander]

Hi yes odometry is working perfectly, we don't know where the problem may come from, I can only tell you that it happened right after updating Linda.

[marc-hanheide]

I just found this commit: 332833f which I find very suspicious, because our mileage is about 5 times less than it should be...

[cburbridge]

This was a while ago, and did not effect it then. However, this file is the only way I can see something us doing being able to effect the mileage. It is simply a MIRA channel which I publish out as a ROS topic, and I guess it is calculated in firmware. Did you update MIRA recently? (is there even a newer version that ours?)

[cdondrup]

@marc-hanheide the odometry changing pull request you mentioned was tested on Linda for a few weeks before we merged it into the master. So I don't think that this has anything to do with it. Otherwise we would have noticed.

[Jailander]

No we haven't update MIRA in a while. But you are right @cdondrup tried that commit a while ago and there didn't seem to be any problem.

[marc-hanheide]

Could this be related to us setting the force on the robot, e.g. a side effect or an implementation bug? Was it about the time we implemented the ramp behavior?

[marc-hanheide]

@chmartin21 have you got any other idea what could cause the mileage to be screwed up on the robot. We just publish the mileage as reported by MIRA, can we easily check something?

[chmartin21]

Can you have check the property "MainControlUnit.TotalMileage" of the authority Robot?

[Jailander]

Hi, @cburbridge and @chmartin21 Can you tell me how to get this I had never worked with MIRA before.

What I have tried so far is running miracenter then open the RPC console, my original intention was to run /robot/Robot#builtin.getProperty("MainControlUnit.TotalMileage") but TAB was not working for this so by doing TAB I got to run this

I suppose my problem is not running the Miracenter under the correct authority, but I don’t know how to do this, can you help me?

[chmartin21]

You have to start miracenter with a configuration, which contains at least the driver for the SCITOS. For example, you can use /opt/MIRA-commercial/domains/robot/SCITOS/etc/SCITOSDriver.xml.

[Jailander]

hi @chmartin21 that seems to work better but now I get this

Enter your RPC calls or type 'help' for more information.

/robot/Robot#builtin.getProperty("Modules.MainControlUnit.TotalMileage")
The property 'Modules.MainControlUnit.TotalMileage' could not be found in '/robot/Robot' (/home/chmartin/release/MIRA/framework/src/fw/Authority.C:740)
/robot/Robot#builtin.getProperty("MainControlUnit.TotalMileage")
The property 'MainControlUnit.TotalMileage' could not be found in '/robot/Robot' (/home/chmartin/release/MIRA/framework/src/fw/Authority.C:740)
/robot/Robot#builtin.getProperties
{
"Root" : {
"Children" : [
{
"Children" : [ ],
"Comment" : "Timeout for removing dead modules",
"Hint" : [ ],
"ID" : "DeadModuleTimeout",
"IsReadOnly" : false,
"Name" : "DeadModuleTimeout",
"Type" : "mira::Duration"
}
],
"Comment" : "",
"Hint" : [ ],
"ID" : "/robot/Robot",
"IsReadOnly" : false,
"Name" : "/robot/Robot",
"Type" : "mira::MicroUnit*"
}
}

Any Ideas?

[chmartin21]

Looks not good: The SCITOS driver seems not be able to detect any module of the robot. I assume, that you are getting some error messages on the console. Or at least the robot authority is not green in the AuthorityView. Probably the driver tries to use the wrong CAN bus interface. The SCITOSDriver.xml assumes, that you have create a SCITOSRobotAttributes.xml file (http://www.mira-project.org/MIRA-doc/domains/robot/SCITOS/index.html#SCITOSConfiguration_Section). You also can specify the CAN bus interface at the command line:

miracenter ..../SCITOSDriver.xml --variables canType=MLCAN.

[Jailander]

Hi yes I didn't realise I was getting this error when launching the miracenter.

[ERROR ] 2013-Nov-21 12:27:39.720789 /robot/can/CANDriver Exception while invoking Runnable: Permission denied
[ERROR ] 2013-Nov-21 12:27:39.721155 Exception:
[boost::exception_detail::clone_implboost::exception_detail::error_info_injectorboost::system::system_error] Permission denied

however the SCITOSRobotAttributes.xml file seems to be fine and I also tried

miracenter ..../SCITOSDriver.xml --variables canType=MLCAN.

but I get the same error

[chmartin21]

The MLCAN uses /dev/ttyUSB2. To access this device, the user must belong to the group dialout. Does your user account have read permission on /dev/ttyUSB* ?

[Jailander]

Hi, I finally got it done, the problem was that /dev/ttyUSB2 was only accessible by root.

the mileage we are getting from ros is 290966.59375 whilst the mileage on MainControlUnit.TotalMileage is 307413 that is the problem

[chmartin21]

You also can read the channel /robot/Mileage, which contains the total mileage with a higher precision. Now you can drive a certain distance and compare the mileage with the real distance.

[marc-hanheide]

so, we tried to get to the bottom of the this. First, here are the relevant source code lines:

mileage_pub_ = robot_->getRosNode().advertise<std_msgs::Float32>("/mileage", 20);

then subscribe to MIRA:

robot_->getMiraAuthority().subscribe<float>("/robot/Mileage",
                                              &ScitosDrive::mileage_data_callback, this);

So, we are subscribing to the /robot/Mileage channel which is supposed to be more precise, I understand.

Then the callback:

void ScitosDrive::mileage_data_callback(mira::ChannelRead<float> data) {
  std_msgs::Float32 out;
  out.data = data->value();                                           
  mileage_pub_.publish(out);
}

Because this all looked fine, we tested pushing the robot around both in MIRA and our software. Here's a video of our little experiment:
http://www.youtube.com/watch?v=ibF-HDgUFc8

It looks as if at lower speeds the counter doesn't go up. When we push harder, it does. That's the same for our ROS implementation and also when we look at the MIRA center. This could well explain our observations to some extend. But I still have no clue how it happens. Anyone? @chmartin21 ?

[chmartin21]

Here are some more details about the mileage computation:

• The motor controller unit of the robot has a built in mileage counter, which counts the total mileage in [m]. The value is stored persistent in the EEPROM memory.
• The property MainControlUnit.TotalMileage gets the persistent value of the EEPROM.
• During the start of the SCITOSDriver, the total mileage is read one time from the EEPROM. Afterwards, the odometry is used to update the mileage. This value is stored in the channel /robot/Mileage.

We never analyzed the precision of the mileage channel at slow velocities. We will check this and give you some feedback.

[marc-hanheide]

That would be much appreciated. We have also tested the odometry when pushing slowly. That is correctly updated (we would have massive localisation issues otherwise). Note, that we have changed the update rate of odometry from 10 Hz to 50Hz, just to give a hint.

[cburbridge]

@bfalacerda mentioned that we also have incorrect mileage now...

[chmartin21]

@ALL: We were able to reproduce this issue: The incorrect mileage is caused by a precision issue within the SCITOS driver. The total mileage is stored in [m]. During slow movements the odometry increments at 50Hz are very small. Adding such small values to a value of some hundred kilometres will lead to precision errors, since the driver uses only standard floating precision for the mileage.

We fixed this bug in our development branch by using double floating precision. But for backward compatibility reasons the channel "Mileage" will still be a float channel. Maybe, we add a second channel, which publishes the mileage as a double value...

This bug was undiscovered until now, since we don't really use the mileage channel in our applications. What are you doing with the mileage? I'm asking, because another way to fix this bug would be to publish only the mileage value from the EEPROM in a fixed interval. This would give you a mileage only in [m].

Any other comments or ideas? What are your specific requirements for the mileage value?

[marc-hanheide]

@cdondrup has been working on another solution as well I believe.

[Jailander]

Yes @cdondrup implemented yesterday a solution based on odometry, you can find it here https://github.com/strands-project/strands_utils/tree/master/odometry_mileage

[cdondrup]

So far it only publishes the mileage since the start of the node using the odometry and double precision.
To have a total mileage there are two possible solutions:

1. Read the /mileage topic on start of the node (because the mileage seems to be correct after restarting the robot and is just not incremented correctly - still have to test this)
2. We can store the latest mileage in the datacentre and initialise the node from there. We can also put the current mileage of the robot in there to have the correct starting point.

Another advantage of the datacentre approach would be that we also have a mileage topic in simulation. Don't know if that would ever be useful :)

Any opinions on that?

[Jailander]

I like datacentre approach specially because it will be useful in simulation too, however, we can call this current mileage and is a topic that will tell us how much the robot has run since started, wich is specially good for the marathon.

Any ideas on what to do for the Marathon statistics?

[cdondrup]

strands-project/strands_utils#45 presents a solution to the mileage problem. The node initialises itself from a mileage paramtere which can be set to the current mileage of your robot before you start the node for the first time. Afterwards the node saves the current mileage to the datacentre regularly.
The only thing that has to be changed is that the statistics would have to use /odom_mileage instead of /mileage.
Instructions on how to run the node can be found in the README.

[cdondrup]

It's already a 400m difference since we started it the first time about 20 to 30 minutes ago.