Getting Vehicle Type in Veins through TraCI

[Daniel Febrian Sengkey]

Hi all,

I'm working on a simulation which requires vehicle type to be exchanged over VANET. Currently I've been stuck about getting the vehicle type through TraCI. The vehicle types was declared in SUMO route file along with the type distribution.

What I need is the vehicle (in OMNeT++) could know what its type. How to done this?
I've reading TraCICommandInterface, the getVehicleTypeIds(), is it the one I should use or not?

I am using OMNeT++ v4.5 and Veins 3.0.
Thanks in advance.

Regards,
Daniel

Sent from Gmail for Android

[Christoph Sommer]

Daniel Febrian Sengkey wrote:
> I've reading TraCICommandInterface, the getVehicleTypeIds(), is it the
> one I should use or not?

almost. The getVehicleTypeIds command returns a list of all known
vehicle type IDs. I noticed that there is already a stub declaration for
getVehicleTypeId (getting a particular vehicle's type), but you will
need to write the implementation yourself. I you do, I would be happy if
you sent me a patch to include this in Veins.

Best,

Christoph

--
Dr. Christoph Sommer
Distributed Embedded Systems Group
University of Paderborn, Germany
http://www.ccs-labs.org/~sommer/

[Daniel Febrian Sengkey]

Thank you Dr. Sommer. I'll try to write it.

Regards,
Daniel

Sent from Gmail for Android

--
You received this message because you are subscribed to the Google Groups "omnetpp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to omnetpp+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Daniel Febrian Sengkey]

Dr. Sommer,
I've been trying to write the code by:

• Adding the implementation to the TraCICommandInterface:

    std::string TraCICommandInterface::getVehicleTypeId(std::string nodeId) {
        return genericGetString(CMD_GET_VEHICLETYPE_VARIABLE, nodeId, VAR_VEHICLECLASS, RESPONSE_GET_VEHICLETYPE_VARIABLE);
    }

• Adding appropriate method in TraCIMobility.h:

    std::string getVehicleType() {
                return getCommandInterface()->getVehicleTypeId(getExternalId());
    }

But when I tried to assign the return value of the a variable in my application layer initialize method, I got following message:
    <!> Error in module (TraCITDE) StRoadScenario.node[0].appl (id=8) at event #2, t=0.1: Model error: TraCI server reported error executing command 0xa5 ("Vehicle type 'type1.0' is not known").

I think my presumption regarding nodeId is wrong. What is the suitable value to be passed to the method of genericGetString() to get the vClass?

Regards,
Daniel

To unsubscribe from this group and stop receiving emails from it, send an email to omnetpp+u...@googlegroups.com.

[Christoph Sommer]

Daniel Febrian Sengkey wrote:
> return genericGetString(CMD_GET_VEHICLETYPE_VARIABLE, nodeId,
> VAR_VEHICLECLASS, RESPONSE_GET_VEHICLETYPE_VARIABLE);
> }

> [...]

> TraCI server reported error executing command 0xa5 ("Vehicle type 'type1.0' is not known").
>

I think you are using the wrong TraCI command.

0xA5 is "Get Vehicle Type Variable" (Asks for the value of a certain
variable of the named vehicle type) [1].

You probably want 0xA4 "Get Vehicle Variable" (Asks for the value of a
certain variable of the named vehicle) [2]. In particular, you probably
want to ask a vehicle for variable 0x4F "type id" (Returns the id of the
type of the named vehicle).


Best,

Christoph



[1] http://sumo.dlr.de/wiki/TraCI/VehicleType_Value_Retrieval
[2] http://sumo.dlr.de/wiki/TraCI/Vehicle_Value_Retrieval

[Daniel Febrian Sengkey]

Oh, I see. Thank you for your explanations Sir. I'll check them out.

Regards,
Daniel

Sent from Gmail for Android

--
You received this message because you are subscribed to the Google Groups "omnetpp" group.

To unsubscribe from this group and stop receiving emails from it, send an email to omnetpp+unsubscribe@googlegroups.com.

[Daniel Febrian Sengkey]

Dear Dr. Sommer

You probably want 0xA4 "Get Vehicle Variable" (Asks for the value of a certain variable of the named vehicle) [2]. In particular, you probably want to ask a vehicle for variable 0x4F "type id" (Returns the id of the type of the named vehicle).

I have updated the TraCICommand to:

    std::string TraCICommandInterface::getVehicleTypeId(std::string nodeId) {

        return genericGetString(CMD_GET_VEHICLE_VARIABLE, nodeId, VAR_TYPE, RESPONSE_GET_VEHICLE_VARIABLE);
    }

The code is work, proved by an initialization to the variable myType in my class' initialize(int stage) method
        myType = traci->getVehicleType();
      EV << "Vehicle ID: " << myId << ", type: " << myType << endl;

and output displayed by EV.


However, I experienced another problem. The simulation become unstable and always terminated with error code 139. I notice (or maybe I think I notice) that the error raised when the simulation is going to add vehicle. I ran several tries, sometimes the simulation terminated a while after a vehicle entered the simulation, sometimes a while after 2 vehicles entered simulation, but sometimes the simulation terminated even before a vehicle entered. That's why I conclude the error comes when a vehicle is going to be added.

Is there any further advice to overcome this problem Sir?

Best regards,
Daniel

[Christoph Sommer]

Daniel Febrian Sengkey wrote:
> I experienced another problem. The simulation become unstable and always
> terminated with error code 139

The Veins FAQ has an entry on this. Please see

http://veins.car2x.org/documentation/faq/


Best,

Christoph

[Daniel Febrian Sengkey]

Dear Dr. Sommer,

Thank you for advices. I had follow the instruction on Veins FAQ. The stack trace always led me to this line in TraCIScenarioManager.h:
        TraCICommandInterface* getCommandInterface() const { return commandIfc; }

I have to admit that I very bad with debugging. If the stack trace led me there then as far as I know this line of code is related with produced error. But for further action I really have no idea what to do. I need further explanation to understand this.

On 11/26/2014 04:12 PM, Christoph Sommer wrote:

[Christoph Sommer]

Daniel Febrian Sengkey wrote:
> I have to admit that I very bad with debugging [...] for further action I really have no idea what to do.

I am sorry, but I do not think I will be able to teach such skills via
one or two e-mails. There are some excellent online tutorials on how to
debug C++ though, and any should serve as a nice starting point for
learning more.

[Daniel Febrian Sengkey]

On 11/29/2014 04:54 AM, Christoph Sommer wrote:
> I am sorry, but I do not think I will be able to teach such skills via
> one or two e-mails. There are some excellent online tutorials on how
> to debug C++ though, and any should serve as a nice starting point for
> learning more.

No problem Sir. Since my last e-mail I've been looking for tutorials.
Thank you Sir :)
I'll coming back with my findings.

Best regards,
Daniel

[Daniel Febrian Sengkey]

Dear Dr. Sommer,

My code is finally worked. The solution is moving out the getMyType()
method of the initialize(int stage). Therefore getMyType() method and
all its related methods are going to be called recursively each time the
vehicle needs its type. I know this is not a good programming practice,
and still searching the solution to reduce memory usage. By the way, I
still have no idea why calling getMyType() from initialize(int stage)
will lead to unstable simulation. Do you have any clue on this Sir?

Best regards,
Daniel

[Christoph Sommer]

Daniel Febrian Sengkey wrote:
> I still have no idea why calling getMyType() from initialize(int stage)
> will lead to unstable simulation.

I just tried and did not encounter any problems. I am guessing that
there is a bug in your implementation.

[Daniel Febrian Sengkey]

Dear Dr. Sommer,

> I just tried and did not encounter any problems. I am guessing that
> there is a bug in your implementation.
>

Yes, there seemed a bug was existed. Today I try to forked veins from
github and I saw there is an implementation of getVehicleTypeId in
TraCICommandInterface.h. I used that and adapting the new code with my
code and all are working as I hope.

Thank you.
Regards,

Daniel