Time Trialer

I am a Computer Science student and track athlete. With COVID cancelling all my track and field distance races, I have been doing solo races on the track and it just sucks. I just finished a EE class on Embedded Systems, though so I have been thinking about what I would need to make an RC Car pacer, so that it sucks less. I know that making an LED rope around the track would be simpler, but I think this sounds like fun to make. Anyway, so far I know I need:

• An RC car
  
• a Raspberry Pi ( Have 2 already )
  
• infrared/photoreceptive sensors ( I think I have 1 already lying around, but likely need two ) to detect the white lines on the track against the black surface
  
• 2.4 Ghz Transmitter and Receiver ( or which ever Frequency range is used by the RC Car that I end up purchasing
  
• Possibly need a second RPi or just a small ardunio board to send line sensor data back to the main Raspberry Pi.
  

I do not have tools or experience with any kind of soldering, so I would like to use the RC Car out of the box as much as possible with the exception of adding those line sensors and attaching a board to send back the sensor data. I am very comfortable with any programming, like Python or C, but I could do most any language. So then my current plan is

1. Buy a 2.4 GHz RC car that can go fast enough.
   
2. Buy a set of 2.4 GHz transmitter/receiver.
   
3. Turn on RC Remote and send control signals ( press throttle, turn wheel )
   
4. Use the extra receiver to capture what those control signals look like.
   
5. Send replicated signals from the Raspberry Pi with the extra transmitter to the RC Car, so that I have control over the RC Car with some kind of software (either C or Python)
   
6. Software does its thing and I can set on top of a white lane line and tell it to follow the line at a certain speed.
   
7. Race the car and try not to step on it.
   

Does this plan makes sense? Are there any obvious flaws? I'm mostly worried that the transmitters and receivers don't work in reality like I think they will or that different brands of transmitters/receivers wont communicate properly. Another concern is that bouncing around the line on the curves will make the speed of the car unpredictably imprecise making it bad at pacing correctly.


Thanks for any thoughts or help!

Bry195

you have 2 curves at least that will need adjustment.

the ratio the chassis turns in relation to steering angle, velocity, and traction’s (surface and tires).

as the tires wear the diameter shrinks so you will need some math to create a constant velocity model.

you might get lucky and write a program that can figure out how much steering angle to add and how often by using a known distance between white lines but I think you will need actual velocity feedback from a brushed motor with sensors. and if you are going to do that you might as well get your pi connected to the actual steering feedback by tapping into the pot in the servo because if you are going to do the work to adjust velocity from actual sensor feedback you might as well do 10% more work and grab the actual steering angle.

the servo command represents a position but it does not represent how much the chassis turns.
The esc command does not represent velocity it represents torque.

the scrub angle of the front tires is highly variable.
torque represents a combination of friction, velocity, work, acceleration, ...

it sounds fun and can be done. it possible to expand and contract the end point of the steering rack with dual rate. this might be a manual setup to adjust the chassis turn to the steering angle. you will need to have a mathematical model of where the line is at always so that you can use a 5th order polynomial to blend the chassis angle to the predicted line angle because if the car breaks traction or steps outside your variables from a jerky movement you’ll need a method to recover the hypothetical line angle.

if you write enough code you will need less sensors. you could even cheat and create a teach program that records the motions and then you can expand and contract variables based on the new pace. That is all good until something unpredictable happens. You can spend a bunch of time predicting and refining or you can add more data but either way something unpredictable will happen. But that is what it takes over and over again. that is how you go from student to teacher is by those iterations and refinements.

PDR

iTrader: (31)

Definitely sounds do-able and a lot of fun to boot. A well-tuned PID loop should keep things smooth. Outdoors, a sub $20 GPS module will track speed to better than 0.1m/s. It wouldn't be accurate enough for position within a running lane, but combine it with an OpenCV model for lane finding (eg: ) and you'd have some useful data to choose from, as well as maybe a "return to base" feature.

TBH - knock your socks off and let us know how you go.

Roelof

You want to make something like this?

iliveonnitro

Does he have a non-facebook page of how he did this? I'd love to see what his process was.

@OP Do you know how to use Simulink, or do you have access through your university? The program is used extensively in self-driving cars, launch vehicles, engine ECUs, etc. It'll easily do the code you need. https://www.mathworks.com/help/drivi...detection.html

Roelof

There is no website.. Maybe he has also a twitter and/or instagram account....
On his Facebook page also not much information.

andreas78

This might also be a nice platform to start with:
https://www.donkeycar.com/

Andreas

[email protected]

I try to only answer questions about Castle products on here instead of actively promoting our products, but I think Castle has a really good solution for controlling the speed of your pacer.

We have a communications protocol we call Link Live built into all of our ESCs. That allows telemetry feedback from the ESC to the receiver via the normal signal wire. It is a very strange protocol and kind of hard to implement, but it works really well. I know there is a library out there for using it on Arduino, but I don't think know of any for R-Pi. We sell an additional device called the serial link that handles all of that weirdness and converts it to a more traditional serial or i2c communication. The serial link can receive the link Live data and broadcast it back via serial, but it can also control the throttle via the same serial so you don't have to have your controller outputting a PWM pulse constantly.

When I think about the point of a pacer, I think of something with a very controlled speed. With a normal RC control, setting to 50% throttle might be the speed you want at first. As the battery drains, 50% throttle is no longer the speed it was going on a full charge. With Link Live, you could get feedback of the exact motor RPM 11 times per second and then adjust your throttle input very slightly to maintain a a very specific RPM. If you have a Castle ESC that has datalogging(like the Mamba X) you could also get an exact feedback of the amount of current used by the ESC/Motor so that you might be able detect object collisions by detecting when current goes up and RPM goes down. You could also use the motor RPM to calculate exactly how far you have gone.

Sorry for the promotion back to the project. I think if you had a pair of 7 segment displays showing on the back of the car that were showing the current speed it would be cool. Also instead of using an r/c transmitter to control, I was thinking you should get an IR receiver that the PI could listen to and then use a tv remote to control it. Power button as start/stop, and you can enter a channel number as a target speed. So if you type 50, then it will try to maintain 5.0 mph. Channel up could increase it to 5.1mph, channel down would change it back to 5.0 mph.

Another random/fun idea, put a sensor on the back to detect how far you are from it and if you ever start falling back have it play something motivational like Eye of the Tiger or the Rocky theme song over a speaker.