Receive vehicle speed and steering angle from CAN messages

[Sarxell]

To acquire the vehicle speed and steering angle, we need to connect to the CAN-USB to extract the CAN messages required. For that a python code is needed to acquire those messages and publish them in the Odometry_msgs.

[Sarxell]

Hi @miguelriemoliveira Right now the code already publishes ackermann_msgs of the speed and steering angle from the CAN-USB, I just need to test it (and the gps) to compare values.

[miguelriemoliveira]

You are very lucky :).

What is the frequency of msgs? What are the units? Meters, radians?

[Sarxell]

@miguelriemoliveira So I know that the steering angle is in degrees , I already move the steering wheel and I got a value of -44° which looks correct seeing the way that it's rotated! Speed I can't tell , in Diogo Figueiredo thesis he doesn't say and because the car is stopped I only receive zero ... talking about frequency I did rostopic hz /atlascar2/ackermann_msgs and I'm getting the following values:

average rate: 1604.685
    min: 0.000s max: 0.006s std dev: 0.00068s window: 1596
average rate: 1602.650
    min: 0.000s max: 0.006s std dev: 0.00067s window: 3199
average rate: 1601.443
    min: 0.000s max: 0.008s std dev: 0.00069s window: 4802
average rate: 1597.969
    min: 0.000s max: 0.012s std dev: 0.00070s window: 6394
average rate: 1598.910
    min: 0.000s max: 0.012s std dev: 0.00070s window: 8000
average rate: 1598.580
    min: 0.000s max: 0.012s std dev: 0.00070s window: 9605
average rate: 1599.324
    min: 0.000s max: 0.012s std dev: 0.00070s window: 11217
average rate: 1599.275
    min: 0.000s max: 0.013s std dev: 0.00071s window: 12824
average rate: 1599.525
    min: 0.000s max: 0.013s std dev: 0.00071s window: 14432
average rate: 1599.496
    min: 0.000s max: 0.013s std dev: 0.00071s window: 16041
^@^Caverage rate: 1599.885
    min: 0.000s max: 0.013s std dev: 0.00071s window: 16699

without using rate.sleep(), so we can have a 1600Hz!

Steering angle visual proof:

[Sarxell]

I asked Engineer Rui to drive when I was acquiring data to here in the workshop, the value didn't change so I think it is in km since we only can drive very slow in here... and the code is equal to Diogo Figueirdos' code:

if (frame.can_id == 0x412)
{
        //printf("velocidade: %d    ",frame.data[1]);
        status.nominalvalues.velocity = frame.data[1];
        status.rawdata.vel_frame = frame;
}

and mine:

if msg.arbitration_id == 0x412:
    speed = msg.data[1]
    ackMsg.drive.speed = speed

So I think that the velocity may be in km/h but I'm not sure

[Sarxell]

I talked with Miguel pinto and he said that Diogo had a wrong ID, can be from the speed , I will try to talk to him so I can change the code if necessary

[miguelriemoliveira]

Kms will not be helpfull for us because they have very low resolution to compute odometry. Try to see if we get in meters or if we can get the displacement from the vehicle's odometer.

[miguelriemoliveira]

The frequency is more than enough. It may even be hampering the ROS communications, might as well as set a maximum of 100 Hz.

[Sarxell]

Okay, about the frequency it's done! About the km I will check what can be done!

[Sarxell]

Miguel created this table where we can see what we receive in the CAN messages. (In the thesis of Luís Cristovão it says that the velocity is in km/h) I did this piece of code:

if msg is not None:
    if msg.arbitration_id == 0x412:
        # speed is in km/h
        speed_km = msg.data[1]
        dt = (current_time - last_time).to_sec()
        # change to m/s
        speed = (speed_km*1000)/dt
        ackMsg.drive.speed = speed
        last_time = current_time

I don't know if it will work but I will ask engineer Rui to help me tomorrow moving the vehicle..

Changing to meters I asked Miguel and he said that in his research he didn't find anything about that...

[Sarxell]

In here https://github.com/plaes/i-miev-obd2 it says odometer display but it is also in km... But I think I can find a way! We also receive the rpm of the motor, with the formula:

We can find the velocity in m/s. This must be more reliable right?

[miguelriemoliveira]

Hi @Sarxell ,

One thing I could not understand: the value is is kms, but is it an integer value or a float? I mean, if we go from kilometer 1.102 to 1.103 then its ok to compute the odometry.

About the equation: I think you need some constant to multiply because the rotations in the motor are not the same as in the wheels. The good thing is that you don't have clutch or gears so the constant will always be the same, right?

[Sarxell]

Hi @miguelriemoliveira , unfortunately the value of the kms is an integer .. yes I think I need the gear ratio that can be found in the specs of the car.

[miguelriemoliveira]

Ok, so if you use the rpms that should also be an integer, probably in rpms*1000.

Do some calculations to assess, based on all this how much resolution of movement we would have. 10cm? 1meter?

You know how to compute this?

[Sarxell]

So, in terms of code I already did it, the procedure is equal to the steering angle, we get the byte from the right transmission ID:

I'm already having trouble here because although the car is stopped, the rpm gives a value of 8984 , which doesn't make sense (the byte gives me a value of 39), so or the value of the ID is wrong or the used byte

Where bit can go from 0-255 (max values, I don't know the range which is used), doing the example of 10 and 11 bits it gives us:

rpm_10: 1560 rpm_11: 1816

Doing the velocities for both of these values:

v_10: 46.5584 v_11: 54.1988

We loose a lot between bits, 7.64 meters ...

[miguelriemoliveira]

hum, if this is true the can messages are useless for computing the odometry. Perhaps prof @vitoruapt may help here, since he has more experience with CAN. Can you talk to him?

[Sarxell]

Yes, I'm going to send him an email to see if he knows a better way or something that I am missing about the CAN messages

[Sarxell]

Hi @miguelriemoliveira ,

I talked with @vitoruapt , more bad news ... So the only way is really using the speed of km/h ...but at the worst chance is that the car uses a tacometer in which he only sends values to the CAN after 5,10 km/h

Today I'm going with the car to the parking lot to see this values

[miguelriemoliveira]

Bad news indeed ... @vitoruapt is it an option to install the odometer we had in the old atlascar?

[vitoruapt]

Installing the odometer would not be very practical, nor necessary, I suppose. And finding volunteers to do it could be a challenge :-). And I do not think that this is really bad news. In short: we have two main issues: 1-Minimum velocity measurable (is it 1 km/h, or more, like 10 km/h?) 2-Limited velocity resolution (1km/h ~ 28 cm/s)

Issue 1, if verified, does not allow odometry at very low speeds. So, we have no tracking when starting motion, mainly! Issue 2 is not a severe problem. Having speed information at more than 1kHz allows us to integrate measurements along time and several approaches can be used, like moving averages.

Integrating variables is always a risk due to cumulative errors, but having the information at a so high rate allows averaging sets of successive measurements and reduce some errors. This might even be an interesting technical topic do discuss and analyze in the thesis ;-)

So, all summed, there is indeed a limitation for velocities below the minimum measurable (which is yet to be measured in this car) but that does not compromise the validity of the solution, and neither its results for this car when driving above the minimum velocity.

There is another concern which is the calibration of the velocity with the real distances traveled. I recommend to do some tests outdoors in a well marked floor (e.g. parking area at Crasto site) and figure out how well the system is performing and extract some calibration factors, at least for straight motion. The steering angle may be another source or error, but that can be left for a later concern ;-)

[miguelriemoliveira]

Hi @vitoruapt ,

I agree that using the old odometer could be a problem. However, we should find a better solution tryin to get better info from the can, because these makes the calibration not viable. Also, for testing we must do the calibration at very slow speeds, possibly pushing the car in the DEM workshop. My experience is that we do these tests hundreds of times before everything works properly. Having to do these tests with the car moving outside the workshop while driving makes it very difficult to develop and validate the solution.

In summary, we can implement this odometry, but with this level of quality I think we cannot do the calibration of the atlascar sensors w.r.t. the vehicle.

@manuelgitgomes , this is important for you.

[vitoruapt]

Theoretically, with the data available in the CAN bus, having the velocity information at 100 Hz allows you to "measure" a displacement as small as 0.28/100=0.0028 m, that is, less than 3 mm! Of course, we should be moving at a minimum speed, which we do not know yet what is it, but I Diogo's thesis he did some tests at 6 km/h so I suppose that we can measure velocities this low...

[Sarxell]

I went with the car to the crasto's parking lot and I got values in the order of 2km/h , it's the minimum !

[vitoruapt]

OK, not bad! Did you register all intermediate velocities (3,4,5,6, ... etc.) or some values are missing from the records?

[Sarxell]

With 100Hz I lost values when I got to 20km/h.. On another note @miguelriemoliveira , has I said yesterday, I went to test the new formula using the motor rpms

I checked the car specifications and I saw that he only has a diff gear ratio of 7.065 and the wheel radius is 0.285... So using the formula:

speed = (motor_rpm*math.pi*0.285)/(30*7.065) I could find the speed (where the rpm are motor_rpm = (msg.data[6]*256 + msg.data[7]) - 10000 , having 2 bytes for more precision)

I went with @manuelgitgomes to test this new code and compare both velocities and got the following results:

comparison_velocity.txt

(The values from the speed and the rpm are clear since the speed only changes 30cm between each value)

I think this way is much more precise, the only downside (that also happens with the speed) is when we are braking the rpms take their time to stop (values of 0.15km/h-0.045m/s)... This can be improved using a value to decrease this value when the CAN message sends the byte that we are braking... but we need to check in tests if this is really a problem or not since these values are very small

[miguelriemoliveira]

Hi @Sarxell ,

thank for the experiment. Can you make a graph with the values (with matlab for example) instead of the raw values and post it here? It would be much better to see.

Yesterday we talked to @vitoruapt and he said the gear ratio changes, so we thought of also exploring the possibility of using the odometer that we have on the old atlascar1 and install it on the atlascar2.

@manuelgitgomes was going with Eng. Rui Heitor to the old car today ...

[manuelgitgomes]

I went with @Sarxell! IMG_20220422_110758.jpg

We were having difficulties on extracting the odometer, so we took the rim to compare and the screws were not the same, so a new copulling is needed.

[Sarxell]

http://myimiev.com/forum/viewtopic.php?t=232 in this forum it says the gear ratio is fixed in this car... I will do the graph with the values for the professor to see how it went

[miguelriemoliveira]

http://myimiev.com/forum/viewtopic.php?t=232 in this forum it says the gear ratio is fixed in this car... I will do the graph with the values for the professor to see how it went

@vitoruapt can you take a look?

[Sarxell]

Here it is @miguelriemoliveira ! The graph using the different values from the motor rpm and the vehicle speed

[vitoruapt]

http://myimiev.com/forum/viewtopic.php?t=232 in this forum it says the gear ratio is fixed in this car... I will do the graph with the values for the professor to see how it went

@vitoruapt can you take a look?

The car has different driving modes (https://designobserver.com/feature/mitsubishi-i-miev-electric-car/15058) that is why I assumed different gear ratios for each of them, but that can possibly be managed at software level and not at hardware as manual gear cars! So, if there is a direct connection from the motor rotation to the car wheels, excellent, that can solve the limitation of the speed read from the CAN ;-)

[miguelriemoliveira]

So we confirm that the speed is not usable, right? About the rpms we have some noise in the signal. @Sarxell I did not understand very well. Do we have rpms all the time? Even when stopped?

But when you say

This can be improved using a value to decrease this value when the CAN message sends the byte that we are braking.

I see this difficult to do ... by how much would you decrease the value? Does not appear to be a way to get precise values ...

About the odometer, lets move the discussion to #36

[Sarxell]

@miguelriemoliveira when we stop the rpms gives us one or two values in the values of 0.045 and then it gives us zero since the motor needs time to stop, but yes we have rpm values all the time ( just sometimes they are zero)

I think I could only check if the values are precise if I test it with the odometry, this values where taken inside DEM so there wasn't much space to see the braking problem...because my biggest issue is "and if we are going "fast" and we brake suddenly?" I think that can be a problem but I can't test it with this weather

[miguelriemoliveira]

OK. We only need high precision for calibration, which is limited to very low speeds.

[manuelgitgomes]

Done