Fosapifi

[MOC] Tesla Semi with Autopilot and torque vectoring

Recommended Posts

One more overengineered MOC from us:

640x427.JPG

We started this project in summer 2018. It was nearly finished in late 2019. There was only one problem left...

Like the prototype of the real truck, our model has 4 motors for driving, one for each rear wheel, without differentials. While steering, the motors would stop because they could not handle the speed difference of the inner and outer wheels. We thought of three solutions for this problem. 1: Use a high enough torque to grip ratio to make the wheels slip - not possible for this truck, 2: Use 24t clutch gears on one side - worked only while steering to one side and 3: Program the motors to slow down, matching the steering radius - not possible with the SBrick app.

We paused the project until we came up with a torque vectoring system this year, 2022 (still less delay than the real truck's production). You can see how it works in this video (at 0:45 - 2:35):

Functions of the finished model:

- driving (4x PF L-motor, 1x servo motor)

- steering (1x PF servo motor)

- torque vectoring (1x PF servo motor)

- fifth wheel lock (1x PF M-motor)

- moveable side flaps (1x PF M-motor)

- openable doors and front trunk

- Autopilot (2x WeDo 1.0 motion sensor)

 

Functions of the trailer:

- raiseable supports (1x PF M-motor)

- lifting the first axle (1x PF M-motor)

- passive trailer steering, connected to the fifth wheel

 

Is the torque vectoring system the perfect solution? Probably not. The driving works a lot better than without the system, but steering with the extra weight of the trailer still slows the truck down. The best option would be differentials.

Our setup only allows to use the driving motors at full power. In theory you could control the driving motors proportional to the steering angle and the desired driving speed at the same time, by connecting two servos to the battery boxes. One to slow the inner wheel down while steering, the other one to have proportional speed control, connected together with a diff for each side. If you want to be able to drive backwards as well, this would be an insanely complicated mechanism which does not fit in such limited space.

 

640x480.jpg

Disappointingly, the SBrick app still does not allow to use sensors in the control profile editor. For the Autopilot mode, we had to use the open source BLE protocol of the SBrick+ to write a simple code. By default, the truck is driving forward. If one "motion sensor" detects an object, the truck steers to the other side. If both sensors detect an object, the truck stops. The WeDo motion sensors can neither detect motion, nor distances. They only detect if their IR light is reflected. The distance depends on the colour and the brightness of the object. We had the best results with reflective materials. Light, shiny materials also work. If the object is to dark, the Semi will hit it, before stopping or steering.

 

Some more pictures:

640x427.JPG

640x427.JPG

640x427.JPG

640x427.JPG

640x427.JPG

640x427.JPG

By the way, the production version of the Semi has a longer cabin, longer wheelbase, side mirrors, no covers for the rear wheels and only 3 motors. This model resembles the prototype, presented in 2017.

As always, we plan to make free building instructions.

Edited by Fosapifi

Share this post


Link to post
Share on other sites

the bodywork looks very organic. The steering on the trailer is ingenious! Do you calculate the torque vectoring based on the speed?

Share this post


Link to post
Share on other sites

Great MOC :thumbup: and congratulations for succeeding with the torque verctoring system, I love it :wub:! I´ve had such ideas with the battery a long time ago, but from idea to realization is a long way as you know. Allthough I´m following a different idea as mechanical solution right now which involves multiple differentials.

Some questions: Who is "US"? Sharing one project with others must deliver double fun but is not as easy as well, right? 

Does the amount of torque vectoring correlate with the current speed? Why is the counterweight needed - is it because of a sensitive suspension?

Share this post


Link to post
Share on other sites

Fascinating drive train, and congratulations on finally getting it to work.

Also your timing is impeccable considering all the Tesla Truck internet traffic today. 

Share this post


Link to post
Share on other sites

Very nice MOC!
I love that you managed to build a Tesla MOC that is actually innovative (In the spirit of the originals) while maintaining the direct drive.

I also like the way you accomplished all the functions within the PF ecosystem, using the WeDo sensors and 8878 batteries instead of PU, which I imagine would have made it easier. The torque vectoring is very cool too! Overengineered, yes, but that's the point! The aesthetic is nice and clean, and the trailer is massive!
Good work!

Share this post


Link to post
Share on other sites
41 minutes ago, pow said:

Do you calculate the torque vectoring based on the speed?

Nope, it was just trying different lever lengths. For testing, we layed the truck upside down and placed a sheet of cardboard on the rear wheels. The movement of the cardboard should match the front wheels angle. Another way to make the effect visible is connecting both sides with a diff, one side reversed.

43 minutes ago, Murdoch17 said:

Does it burst into spontaneously into flames like the Tesla cars do?

Considering the density of electric elements and cables, it probably could...

19 minutes ago, brunojj1 said:

Who is "US"?

2 persons working on one MOC means twice as many ideas and twice the amount of endurance. I know this is not very common, but we, Pirmin and Levin, work always together. I, Levin, do all of the postings on EB, YT, etc.

25 minutes ago, brunojj1 said:

Does the amount of torque vectoring correlate with the current speed?

As the driving motors are controlled by pole reversers, directly connected to the battery boxes, there is only full speed. In the post I mentioned that analogue speed would be possible with another servo and diffs.

31 minutes ago, brunojj1 said:

Why is the counterweight needed - is it because of a sensitive suspension?

As far as I know, a mechanism like this always needs some kind of restoring force. In one state the potentiometers both have to be turned all the way up. The servo must turn one of them down, while not being able to turn the other one any further. You could use a spring, rubber band or counterweight. In a earlier prototype, we had a similar mechanism for the side flaps, to match them to the angle of the trailer while steering. We decided to use counterweights for 4 reasons.

1: It is different from standard solutions.

2:Counterweights should have less wear than springs or rubber bands.

3: It looks cool and exotic.

4: We wanted to show off with our EV3 steel balls.

It is obvious that we had to implement the counter weight again when we ditched the idea with the flaps.

800x600.jpg

Share this post


Link to post
Share on other sites
17 hours ago, Thirdwigg said:

Also your timing is impeccable considering all the Tesla Truck internet traffic today. 

That was actually the big motivation to finish the model. I had a sleepless night for maling the video.

17 hours ago, 2GodBDGlory said:

I also like the way you accomplished all the functions within the PF ecosystem, using the WeDo sensors and 8878 batteries instead of PU, which I imagine would have made it easier

I do not see the point in using PU. PF has stackable ports and more options, like pole reversers, extension wires, different battery boxes, RC system compability. The only thing I am missing is a programable app for SBrick+. We considered using EV3 wich would make the torque vectoring, autopilot, trailer steering and side flaps much easier but it was not possible with the limited space.

Share this post


Link to post
Share on other sites
4 hours ago, Fosapifi said:

I do not see the point in using PU. PF has stackable ports and more options, like pole reversers, extension wires, different battery boxes, RC system compability. The only thing I am missing is a programable app for SBrick+. We considered using EV3 wich would make the torque vectoring, autopilot, trailer steering and side flaps much easier but it was not possible with the limited space.

I think in general I'd agree with you that PF has more versatility, and it's definitely the system I prefer all-around; I just think that your model in particular could really have benefited from some of its unique features. Though, now that I think about it, with seven motors and two sensors, you'd need nine ports, which puts you into three-hub territory, which would be seriously annoying. Though, on the other hand, I suppose you could get rid of the servo for controlling forward/reverse, (since you could probably do that in the code) getting you down to eight ports and only two hubs, which sounds reasonable.
I'm definitely not suggesting that you change it, though! I think using PF must have made for some extra work without major practical advantages, but does make it a significantly cooler model from a complexity standpoint! I love seeing those WeDo sensors actually being used in an RC MOC!

Share this post


Link to post
Share on other sites

Over-engineered but such fabulous work and perfect timing with the RL revealed truck. Congrats!

Share this post


Link to post
Share on other sites
5 hours ago, Milan said:

Scheduled for frontpaging.

800x533.JPG

The photos in the original post are pretty small, so here is a large one.

Share this post


Link to post
Share on other sites
43 minutes ago, LordsofMedieval said:

I, for one, appreciate the potent irony of an artistic triumph in replicating an engineering disaster. It's like this conflict of good/Lego/creator vs Musk/Tesla/LI batteries. :pir-triumph:

The calculation in this video is not correct at all.

First, he did not consider that the Tesla has much better aerodynamics than a conventional semi.

Second, the drivetrain is much more efficient because it does not use gearbox, clutch and diff.

Third, he assumed that the empty trucks have the same weight wich is not the case at all.

Fourth, and I think this is his big mistake: He did the calculation for the range of a conventional semi. The Tesla has only one quarter of the range, which means that the battery needs to weigh only one quarter as well.

In total, his guess for the weight should be about 20 tons to high.

I think it is not fair to call it a "disaster" or "failure". One thing, he is right about is that EVs will not be a solution for traffic or climate change.

 

Enough OT. I want to share some pictures of the unfinished model. I took them at Bricking Bavaria 2021.

640x640.jpg

640x640.jpg

640x640.jpg

Share this post


Link to post
Share on other sites

Saw the video:

Truck alternative differential system is too complex for my mind. One servo does steering, the second servo slows inner pair of wheels, how...
 

Most I like the clutch in the trailer for the axle lifting and automatic system - very well engineering. Despite real EU trailers does not have steered axles :)

And the exterior is super smooth as I have already mentioned before!

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.