Post

Driver Regulation System (Part 2)

Development of the Driver Regulation System (DRS) for SPARK

Driver Regulation System (Part 2)

Recap

So last when I left off, I had an architecture planned out for the driver regulation system. Now it is time to actually interact with the hardware.


Hijacking the radio

So this was my target. This reciever had some code and software on it already that handled listening to the waves and send outputs on the channels shown below in Figure 1.

Desktop View Figure 1: The radio reciever on the car

Now I learned by obersevation that channel 2 was the channel that was impacted by the trigger on the remote. This makes sense since that is the channel that goes to the electronic speed controller (ESC) in the stock configuration of the car. As such that was the channel I was to listen to. Also channel 0 was the one incharge of steering since it was connected to the steering servo. I was not to sure what the other channels were there for but yeah.

My first attempt

Desktop View Figure 2: Radio hijack attempt 1

My first thought was to just plug everything to the servo head that I got and connect that to a teensy to try and read the PWM signals coming out of the car. This was a problem and didnt work. While I was able to send data to the servo and ESC (more on this in a bit), I was unable to actually read the data from the radios. 4 hours later, I read the data sheet and realized that the servo head is only capable of doing PWM outputs, not reading PWN inputs. So I had to try something else.

My second attempt

Turns out, I was able to just plug the outputs from channel 2 straight into the ESP-32 and just read from it!! I didn’t end up taking a picture of my setup but below is the wiring I had going to the ESP-32. Desktop View Figure 2: Radio hijack attempt 2


Profiling the Servo and ESC input space

Now that I knew what output come from the radio and how to use them digitally in the ESP-32 to control the gating mechinism of the DRS system, it was time to profile the servo for steering the the ESC for traction. To do this, I devised this super sketchy test bench setup that would probably get me scolded by my mentors at the Space Systems Lab.

Desktop View Figure 3: PWM Signal Testbed

It wasn’t pretty but it worked. Through trial and error I was able to find the following values for the servo and ESC.

For the steering servo:

Direction Commanded Outputs Ticks ever 20ms
Idle 1561 319
Left 1982 405
Right 988 202

For the ESC servo:

Direction Commanded Outputs Ticks ever 20ms
Idle 1492 305
Forward 1968 403
Reverse 987 202
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
// defines in code for steering
#define LEFT_STEER           405
#define RIGHT_STEER          202
#define NEUTRAL_STEER        319

// defines in code for traction
#define MAX_TRACT            403
#define MIN_TRACT            202
#define NO_TRACT             305

// defines in code for RF deadman switch
#define RF_NEUTRAL           306
#define RF_ENABLED           406

// PWM settings for pins
#define PWM_TRAC_FEQ         50
#define PWM_STER_FEQ         50
#define PWM_RESOLUTION       12
#define PWM_TRAC_CHANNEL     0
#define PWM_STER_CHANNEL     1

The idle for the ESC was very critical cause if the pwm is not exactly 305 ticks ever 20ms, the ESC errors out.

Looking back, I could have also gotten these values from listening to the radios, but this was far more fun honestly.


Next Steps

Now that I had figured out everything I needed, it was time to start formalizing the actual electronics and hardware for this subsystem!!

This post is licensed under CC BY 4.0 by the author.