cmd_vel and odometry for different frames?

edit

Thank you for the answer. The reason I prefer to use the front wheel kinematics is that the odometry is the integral of the kinematics equations, so since the front wheel equations are simpler and less coupled, there will be less error and less drift. (if I am wrong about that, please let me know). My plan was indeed to use the twist components of the /front_wheel in the front wheel frame, and the geometry components of the /front_wheel in the /odom frame. Now, assuming I am also publishing the Joint angle to /tf, why wouldn't the tf and navigation package be able to calculate the geometry and twist of the /base_link and use it for navigation?

in the following link, page 6,link text, there is a geometric comparison of different odometric methods. You can see that if I use just the kinematic relations (the Euler method) I will have an error. I order to reduce the error I will have to use runge-kutta method. But in the kinematic equations of the tricycle there is a coupling between alpha and theta, so I am trying to bypass this complication.

The comparison on slide 6 is of different integration methods, which can all use a kinematic model. Even if you focus on the odometry of the wheel alone, at some point you need to calculate/measure the pose and velocities of the robot base for navigation--or provide enough clearance to disregard it.

All that aside, assuming you publish the correct data, using a frame other than the robot's base will only work if the navigation components you choose know how to handle it. For example, the base_local_planner assumes "the odometry is published in the frame of the base" (see source code). I suggest transforming the data into the base_link frame when publishing odometry. You can use a tf2::Buffer and the transform() funciton.