berickson / car Goto Github PK

Currently the route is planned using the following considerations:

1. Maximum speed around turns without slipping
2. Maximum deceleration rate
3. Maximum velocity

This causes the car to jump to maximum velocity instantly on start and after turns, instead of smoothly.

In addition, we want a maximum acceleration to be taken into account. This should cause the car to have a smooth and controlled acceleration up to the cruising velocity.

note:
For now, we can use the same acceleration parameter for acceleration, turning, and deceleration. Eventually there should be a polar plot of the maximum acceleration / deceleration with one axis being lateral and the other axis being medial acceleration.

Instead of just moving waypoints around to smooth the route, a continuous smooth approximation would be better, especially during the route following phase where discontinuities in yaw have a big effect on PID controllers.

It looks like spline fitting would be best suited to this task. An example implementation is here:

https://github.com/volkerp/fitCurves

It seems sensitive to small changes in data, so may need to be improved. Other solutions use simple polynomial fitting over local sections during runs, but this doesn't provide smoothing over large sections and it doesn't address that the points are parametric and can't be represented as simple functions.

When only low to moderate accelerations are required, the car's velocity should be controlled smoothly and precisely. The velocity curves should perfectly fit the planned velocity curves, the acceleration curves should be smooth and not jerky an there should be no throttle induced slippage.

Measures of success:

1. Low mean squared velocity error.
2. No rear wheel slippage
3. Minimize jerk (change in acceleration)

This is to get a better velocity estimate.

For each sensor Teensy should log the following:

• odo_a Total A count (up/down counter)
• us_a Last A Microseconds
• odo_b count (up/down counter)
• us_b Last B Microseconds
• us_ab Total A to B transition time (or B to A if reversing), this is time for magnet to travel hall sensor gap of ~1mm, this should be a negative number if the wheel is reversing

This will allow the following calculations

    // constant, distance car moves between magnets
    d_aa = (wheel_circumference/magnet_count) 

    // constant, distance car moves when travelling sensor gap
    d_ab = (wheel_circumference/magnet_ring_circumference)* 0.01

    v_a = d_aa * (odo_a(t) - odo_a(t-dt)) / dt
    v_b = d_aa * (odo_b(t) - odo_b(t-dt)) / dt
    ab_count = diff(b) if forward or diff(b) if reversing
    v_ab = d_ab * ab_count / t_ab(t) 
    odo = odo_a + odo_b

Analyze each of the velocity measures to get standard deviation, and use all three readings in Kalman filter to get best velocity estimate.

You shouldn't need to use the display on the car
You should be able to control the car with a mobile phone

easily connect mobile device to car
monitor status, voltages
start and stop runs
add waypoints
create routes

In prisk runs with aggressive path pruning, car would follow path then go in little circles until manually stopped.

Simplest might be to gauge position in lane / sidewalk and only correct lateral position in lane and heading.

Jevois could do all the processing and output

1. Timestamp of the frame
2. is car in well defined lane (bool)
3. What is the lateral position in the lane (meters from center), or zero if not in a lane
4. What is heading relative to the lane (radians), or zero if not in a lane

If car was in a well defined lane during recording and is also in a well defined lane in the playback, the position can be updated by above, looking back in time to where car thought it was at the given timestamp of playback.

Position update can be partial if the readings are found to be inaccurate, e.g., move state 10% toward reading, or max of 5 cm and 1 degree toward reading, etc.

Update

Based on difficulty and complexity, this may not be worth it, working on better adaptive velocity first.

Description

Automatically update the lookup tables of esc value vs speed. Save lookup table to sd card.

goal: for a given speed and battery level, and desired acceleration, find esc

get_esc(speed, battery, desired_acceleration)

Either, manually by doing calibration routine where constant esc value is set, or as an online routine where values are updated when:

1. esc input is constant
2. acceleration is near zero

Design for manual system:
Accelerating
for different ESC values

1. start at zero speed
2. go in a straight line up the the max distance, or until car stops accelerating
3. return to zero
4. calculate and store run speed, esc, acceleration, and slippage at 1/2 m/s intervals

easiest way would be to set min and max esc in manual mode and record manually running to max speed and back again, then then sort out data in python.

to find esc for speed and acceleration, find acceleration in floor(speed) and ceiling(speed) and note two esc. Interpolate between two escs using actual speed

Deccelerating
Pick some max speed, say 20 mph
for each esc value, slow to either a stop or where car is no longer accelerating

This should be calculated as the total time that the rear wheels were considered slipping based on their velocity. For example v_rear is more than 10% different from f_front. To account for turn radius, it should be the inferred velocity of the car datum based on each wheel. It can be reported as a ratio of slip (time,distance,count?) vs total.

Wheels would jerk back and forth while turning on low speeds. This appears to be fixed as a result of the timing fix #28

The 1 second timeout is being reported by the driver code while it tries to read dynamics.
It appears more often when heavily loaded like when the camera is run.
Perhaps it is an exception, perhaps it is bad / slow usb loop. raised #29 to instrument the code.

Car should load stereo calibration for 640 x 480 on startup.
A single remap operation should be done per frame to flip, and stereo rectify the cameras.
The get one frame operation should return the calibrated image

calculate car error_d term by using heading error and velocity. This should prevent under-damped responses at higher velocity. This is related to issue #9 .

Calculate mean squared error velocity error for route vs. run.

Best done on car directly so it can be saved with the run.

Tbd whether it is time weighted, position weighted or simply sample based.

Calculate the total jerk (change in acceleration) for the route. Do per run and save with the run summary.

After each route and run, metrics of the route/run should be calculated and saved to a "metrics" file. These metrics will be useful for sorting and selecting routes. Individual issues will cover specific metrics, but metrics are expected to include:

• Max Speed
• Max acceleration
• Total Distance
• Crashes
• Total number of points
• Total curvature
• Bugs encountered

Metrics should be saved in a self describing form like JSON / INI / YAML where they can be discovered by the UI. Different tools can add different metrics to this file, for example, max speed might be added by the car itself during the run, but we may use analysis utilities after the fact to more "goodness" metrics. For this, the file format must be flexible. Tools should tolerate missing metrics.

Add AP Mode hotspot

Add project to test car service, does not include porting tests over.

v_output += k * error

Because Dr. Bruce

Possibly switch from a velocity based PID to a position based PID when car is within some distance of the finish line.

Unexpected exceptions should be caught in dynamics loop, displayed and logged.
Long loop times should be displayed and logged (>0.1 second)
Long usb loop times should be logged

Car looks like it has under-damped behavior at higher speeds.

This can likely be fixed by adding a proper damping term kd and proper derivative calculation. Adding feature for "calculate car error_d term by using heading error and velocity".

Create a web server as primary interface to car.

Design at https://docs.google.com/document/d/1jnkTpTTBObkT73hrilyDSGfgBl9zBDW5EBVpt--Oazk/edit?usp=sharing

Probably because of PID and fixed acceleration. If it ever ends up going slowly backward, the track acceleration can cause it to go backward.