Hi, I’m curious whether (with some customisation) it would be possible to implement torque vectoring with Rover.
My goal is a vehicle with 4 independently controlled motors (one per each wheel), and possibly also 4 independent servos (but one will do nicely at the beginning )
I would like to control the motors in a way that they actively assist steering. Therefore the steering input from controller would be more “yaw” in “deg/sec” than a simple position of steering servo.
I understand that I can achieve that if I wire the motors like copter, with some creative configuration, but I’m afraid that it won’t be much friendly to the tires. Hence I’m seeking mode that would combine copter and rover together. I understand that it most likely won’t be available today, but I’m curious if anyone can point me to the right direction to what needs to be done to achieve this.
Hi Peter, thank you for your reply. I very much like the API for Lua scripts, it would probably provide me with everything I need, which is great.
There are two possible issues I can see:
Speed - the walking robot script calls itself in 10ms intervals, resulting in 100Hz control loop, which compared to the other example scripts this already seems to be a stretch (they usually sleep for 1000ms). Do you think that I would be able to push it at least to 1000Hz (ie. sleep for just 1ms)?
Conflicts with autopilot - I want to prevent conflicts between the script and autopilot. I assume that by using set_output_pwm_chan_timeout, I should be able to neutralise input from the autopilot, and have a sole command of the outputs from the Lua script, correct?
I was about to ask whether it wouldn’t be better to create a new Flight Mode to achieve faster loop, but then I have realised that flight mode class is called with 50Hz frequency (Rover: Adding a New Drive Mode — Dev documentation), which isn’t really helping.
Theoretically - is there a way how to implement faster loop for autopilot, on some high-end hardware like say Pix32?
I’m building something very similar and have half mocked up on my desk ready for testing after the rest of the hardware gets delivered.
My main concern is the existing code in rover may not be reacting fast enough. It seems like it wouldn’t be quick enough to make use of modern high speed servos.
Would you be willing to share your design ideas? I’m drawing the car from scratch in Fusion 360, BTW (but reusing everything I can from Tamiya 1/10 cars). I plan on using 4x 4108 380kv motors, with belt transmission (1:2 ratio), blheli_32 ESCs, and perhaps Pix32 controller. I’m undecided around servos, but I guess that something “normal” like Savox SH-1250MG (one per wheel) will be fine. I intend to correct the direction of the car more through motors than servos…
Truth, they can deal with ~300 Hz control signal. Plus the motors should be able to deal with 1 kHz control signal. That’s the reason why race firmwares run between 1-4 kHz control loop, while ArduPilot seems to run 50Hz loop, which is IMO way too low for any racing. Hence I’m curious if it is possible to push it higher.
100Hz is fine, 200Hz should also be fine, 1Kz is too much. I’m not sure why you need 1000hz for a rover, ArduCopter fly’s fine at 400hz, motor inertia and servo speed make such a fast update rate pointless.
Just use the dedicated lua servo output functions, you can then do whatever you like and there is not need to set with a timeout.
You can turn up the loop rate, SCHED_LOOP_RATE up to 400hz will work. Above 400hz will probably also work but is not tested.
Yeah I’d be happy to share. To be fair the motor were picked an age ago and the potentially high RPM may cause resonance and vibration issues that cause the IMU readings to go seriously screwy. So, without reading too much into the failings of the double reduction here is the setup.
The CAD model is incomplete there (can’t see the little outboard motors for one!), but you get the general idea. In reflection things are getting very tight on 1/10 scale.The middle section is a large LiPo, the track and wheel base are limited to try and fit in a 1/10 body shell but at this rate it may have to be a van! Parts are base on the HPI Sprint models.
My half build was mainly a mock up and hasn’t run yet. I have another iteration of this nearly ready for build (whats shown in outline above) which is nearly ready for print.
I think the GT2 belts are probably cutting it fine in terms of power transmission and I will need to do more work on the suspension to make sure it is damping bumps well without excessive roll. The CofG will be way higher than standard so roll centers will need work.
This is currently printed in PLA which isn’t ideal. PTEG will take a little more abuse but ultimately may be looking towards the filled PETGs. I am hoping that it can become the basis of a STEM engagement competition, perhaps even open rather than just schools/unis. Like formula student but far more affordable. Things breaking if there is a crash isn’t necessarily a bad thing, encourages more caution in driving and makes it more realistic.
CAD is FreeCAD. In the process of learning the Assembly 4 workbench to make the assembly model more dynamic.
As far as I understand 50Hz is comparable to an experienced race driver, but they of course have all the benefits of seat of the pants driving. 400Hz is what I can see some of the Betaflight lot use on their quads, and so was a target, but there are diminishing returns after that. I was looking for some information on what rates modern highly safety rated cars run, I suspect it’s around the 200-400Hz rate.
My current servos are VERY slow, but just trialing on the cheap. The next ones typically do 60 degrees in 0.1 seconds, so potentially 12 degrees of servo motion between updates from the controller. Even with that ignoring servo acceleration it shows that the servos could benefit with a higher update, but they are likely to get hot, and be thirsty! I’m watching UAVCAN servos and ESCs very closely.
My thoughts on control are to start with me driving the car and slowly build up a picture of how the car handles and the data logs back from the car. In order to maintain maximum grip there is a small percentage of slip - similar to angle of attack for wings - between intended direction and where the wheels are pointing. Worst case situation for the controller is it it is doing a max G corner, and grip at one end of the car drops to zero - such as back end bumps up into the air. The challenge would be for the servos to react and change position to rapidly catch the slip. The real art would be getting the controller to change from a mode where it is trying to recover, to one where it is trying to keep the vehicle controllable in a slide. Recognising when the steering servos are having no effect on the IMU readings would indicate a flying wheel, but this is likely to be forcing in too much processing for my little F4 based Pixhawk clone.
I had considered the Donkey Car controller setup, and may still look into that for research but as it happens working on this with ArduPilot suits my need to learn ArduPilot better before attempting a more expensive ArduSub project.
I agree with servo, there’s no point to run them above 300Hz. What I’ve understood from various sources testing motors, they should be able to change RPM up to 1kHz. Again, what I hear this is the reason why Kiss is running 1kHz default loop. Betaflight goes higher (typically 2k or 4k). While 4k is probably little too much, 2k is probably the highest frequency which makes some sense.
With that said, 400Hz should be perhaps fine for car.
Does it mean that the moment when I start writing to servo/motor outputs from Lua script, the values which would normally come from Flight Mode controller are no longer send to the output? Sorry for maybe naive question here…
Thank you! Tell me about not having enough room on 1/10 scale model . I’m basing my car on Tamiya XV-01, for multiple reason. First I have a heap of parts for that car, perhaps enough to buy 3 of them , but more importantly, I already have conversion which puts these parts on a simple carbon plate.
Your design looks very similar to mine, with one difference - I’m drawing this to be a true racer in dirt, so I need to keep low center of gravity, and enclose all the components. Hence the design takes ages, as every millimetre counts for me. I really need to fit 1/10 hatchback body on it…
Well, you are certainly further than me, I’m still printing and verifying individual components…
I’m designing custom pulleys for S3M belts (which is what RC cars typically use). I have been warned that GT2 might not be suitable for this use-case.
In terms of damping, I’m used to running 72mm big bore 1/10 shocks with tuned pistons. But unfortunately also my car is expected to be a brick in terms of weight. I’m still trying to keep CoG low, I will see if I can stick with it.
The plate should be out of something more stiff and durable, if you plan to race it, I think. Carbon or duralumin. I use that on my other cars, works great.
I’m using PETG for prototyping, and I may even use it for some components (pulleys, covers). However, I also want to test ASA for pulleys. CPE HG100 (Fillamentum) is tougher replacement for PETG, works quite well.
Ultimately, I’m going to print the difficult parts using PC (PolyCarbonate) Blend (Prusament), or Nylon Co-polymer (Polymide CoPa). PC Blend is incredibly tough, I have tried to print a-arm using it, and I literally had to hit it with a hammer several times before I broke it. They are a bit tricky to print, but can be done even without an enclosure (with skirt).
BF is actually 10x higher. I happen to have few BF copters as well, and they run 4k loop by default. But as I have mentioned above, 1k is probably the limit of the motor. I can see a benefit of running the gyro/accel loop faster than the control loop (at least 2x), not sure if AP can do that.
Futaba develops some SBus2 servos, insanely expensive. I have decent experience with Spektrum servos (Spektrum RC S6270), which is 330Hz servo, insanely fast and strong for low profile servo. BK Hobies produces some very nice servos as well, plus ProTec. All high-speed servos.
However, I want to use mini servos, so I can put two of them horizontally next to each other. Not sure if I can find reasonably priced highspeed one in that form.
The same. I first want to gather some data, that will allow me to first implement electronic “diffs”. Once that works reasonably well, I plan to involve ahrs library and start playing with torque vectoring.
Interesting. I’m planning to involve sensors like Bitcraze Flow board to detect whether the car is actually moving, and how fast (on top of the ahrs sensor fusion).
Donkey car looks interesting, can it do 4 motors? Why ArduSub? Have you considered PX4? They have an interesting concept of text-based mixers, which seems to be easy to configure, so that would get one started very quickly. If you need more, new Flight Mode (Controller) is a must. Lua script in ArduPilot looks like a good compromise.
What about a GitHub repository once you start developing? I could contribute once my hardware is ready (which will take some time). Here’s where I am:
It is messy, not all joints are properly defined yet, but I first need to figure out the transmission box, so it fits between the arms, and not make the car too wide. I believe I’m almost done with that. Once I can verify it, the progress should be much faster. Once it works, I can share the design.
Hi Pete, have you flown BF in a 5" quad? Compared to AC its night and day in respect to low latency control and stability in the worst flying conditions, for example, with BF you can hover half inch off the ground is dirty air propwash and its perfectly stable. AC is all about being smooth, control response time is low on AC priorities. I have waisted months trying to get AC to fly like BF in acro mode after hearing posts of AC on the pixracer was good, but later to find out “good” was a relative term, like
backyard racers.
To say AC flys fine on 400Hz is true for its application on larger quads. Even my 5" on AC is not nearly as stable as BF, so its not a hardware issue. A few years ago all the top fpv racers flew 32KHz loop because it had to lowest control latency and best prop wash handling (flying backwards through your own dirty air), no one competitive flys on less than 8KHz now days.
A 5" quad motor can spin from idle rpm (~4% throttle = zero thrust) to 90% rpm in under 90ms. AC is born and raised on larger motor/props and there fore is not used to the quick response or racing environment and completely understood. Top LOS quads are at 15:1 thrust to weight now measured inflight with ACC, AP has not seen this kind of preformance and is not programmed/designed for this preformance, even my 5 yo quad is a slow 9:1 thrust to weight.
I raced rc on-road cars for 2 decades, 12th in the 1996 worlds, every little thing helps the top drivers (or pilots in the fpv case), for the entry level guys, well not so much. FYI, BF is now limited to 8K loops because they have so much better gyro filtering (cleaner and also lower latency, another edge BF has over AP), the 16 and 32KHz loops were not giving any better preformance now. Depending on what goals the OP has, BF or even iNav might be an option. Also, back in the APM days, there was one or two guys that used ardupilot to control 4 motors, one per wheel, might want to research that project for additional info. Some car esc have a gyro in them and then assist the steering servo for unwanted car movement, may also want to look into that for info. Great project, please keep us posted!
I appreciate the IMUs may be polled far higher than 400hz, but don’t expect control outputs to be made to my servos or ESCs at much more than that. Disregarding accelerations even with the higher speed servos thats about 1.5 degrees of angle change, the drive motors have the the reflected inertia of the vehicle to work against up until the tyre breaks grip, so 2.5ms would be plenty fast enough. That said, this assumes the servos and ESCs are polling shortly after controller updates.
There are some interesting videos on diagnosing IMU issues and polling rates on youtube. Think it was Joshua Bardwell - or similar spelling! The rpm filter is something that I am likely to need for sure!
Keep an eye on castor angle on the hubs. I am using two front ends and very nearly got one front end back to front. That would have likely gotten very shakey like a bent castor wheel on a shopping trolley!
One of my objectives is to get the majority of the vehicle printable while maintaining a realistic driving feel comparable to that of a full size vehicle when viewed from FPV, so I can tollerate a higher CoG. Tuning roll centres will wait, but strongly suspect the autopilot to be more of a limiting factor than the dynamics of the vehicle.
With regards to donkey car I was looking to that because it is built to race robot cars, be it considerably slower than normal racing. I would have been adding something in line that converted the two control channels into eight.
That is true. I would love to use BF because of its faster PID loop, the problem is that it isn’t easy to rewrite it. Why rewriting? Let me explain.
I can certainly modify mixer on Betaflight, introduce servos, and say that servos have 100% of yaw authority. Then I can say that motors have say 30% influence on Yaw. I’m pretty sure that it will work fairly well, and BF will rotate the car quite aggressively. The problem is, that I can’t implement Ackerman steering this way (I have 2 servos, so it has to be implement electronically). Hence I will introduce unnecessary tire slip, compromising traction of the vehicle.
Of course one might implement Ackerman steering in a traditional way, but that’s much of an option on my design. There are engines and belts where you normally have steering links. So I had to rotate the steering knuckles, which screams to be controlled by two servos, where the “inner” simulates the Ackerman steering by turning the wheel a bit more. Which simply can’t be done with mixer only.
Here come Lua scripting in AR. It seem that it should be fairly easy to implement Ackerman using the Lua script, plus some steering assistance. On the other hand, there’ll be no PID controller.
Alternatively, implementing new Flight Mode also might be an option. AC/AR is much more modular, and it is ready to be customised, contrary to BF.
Similar story with PX4.
iNAV is based on BF, so I expect the same story. But I have just emailed Paweł Spychalski, asked him whether he would be willing to help to identify things that need to be changed.
Do you have any link? I know about a guy who did this with Matlab, but abandoned the project. Then there’s another guy who wrote master thesis around it, also based on Matlab, but his code is apparently a part of CVUT Formula student car, so he was not willing to share it.
Then there’s this guy:
(very crude way to do it)
Right, I actually have a car with that setup. Works kind of OK, but I need to improve cornering performance, not keep straight the line , and for that the gyro is not that useful.
Good catch. Yeah, that would be very unfortunate .
We have this competition of RC Rally cars, where I ultimately want to test it. So low CG and dust-proof is an imperative for me. Which makes the design pretty tough. Fortunately this is not my first custom car that I’m building, but still…
We really need to figure out proper behaviour of diffs (both center and axle). Once the wheels rotate with correct speeds during cornering, higher CoG will become the limiting factor.
You have a point. For a long time the FC (multi-wii/KK2) only output at 490Hz (was the limit of the 1.0~2.0ms servo standard). There was much debate on the rcg BF thread about going to 1khz, most said it would not benefit anything. Oneshot esc protocol was bourn and it was night and day for stability. The things that helped BF advance is, only focus on just acro flight, black box logging/viewer, huge pilot community testing/feeding back BB logs daily and innovative pilots/programmers (boris being one). The rcg bf thread averaged over 100 posts a day for several years. The loop cycle time was short with that kind of resources.
I understand your project/status is completely different.
The issue with fpv on a rc car is the bumps are gigantic relative to a real car, we tried fpv racing in late 90’s, even on a smooth race track, it was bumpy in the goggles.
Roll centers I think will not matter very much, unless you you had early Tamiya car parts, they really sucked till they started copying AE, Trinity, Yokomo, etc. They were the single worst thing that happened in my 2 decade rc on-road racing, crappy plastic cars, 10 different versions (F1, mini copper, FWD, etc), this split up the main three groups of drivers into 8 groups and 2 drivers in each class, just about killed it. They would not allow any other MFG cars on their track because we were lapping them even with their factory drivers.
Regarding roll centers, generally its tough to change them unless there is already multiple suspension point mounting points. Springs and roll bars should get you 70% the way there, dampers/caster/camber/toe-in/Akerman/anti-dive-squat/etc another 20%.
I would first tune the car w/o interference from AP, why fight mechanical with unknown FW/settings.
F/R drive ratio will be a great parameter to tune among many others. If I was younger (and had the time), I would love to work on this project. When I raced and was sponsored, I had two identical cars, one was a test car I would try all kinds of things and easily compare lap times with my number 1 car.
I’ve been giving this a lot of thought, although I’ve no recent practical experience to base it on. I am considering a much softer suspension system to damp some of the vibrations and look to suspension design to control dive, squat, dive etc. “FPV” is stretching it a bit. I am really looking for something that is just about good enough for video processing, not necessarily good enough for a cinematic real FPV experience.
I used to race a Mardave Cobra indoors in a club that never raced other clubs. As I was doing this in my early to mid teens I never had the money to get into tuning, and it was before digital radios or brushless motors were common place. Six cell NiMH batterys and MTronics speed controllers were the norm, but I did get things hot enough to weld the truly awful Tamiya connectors together.
The ultimate objective is to develop a platform that can be used to drive engagement in autonomous driving though an accessible platform that doesn’t over sense. 3D laser scanning for example makes things easier, but is very expensive. If a human can drive a computer simulation well from their office chair then surely it should be possible with a single camera and IMU feedback! The real question will be how quick it can get before processors tend towards maxing out.
I’ve decided that practical trials are what will really give the best feedback. There are so many aspects of the car design that could be studied to the finest of details and loose hours of time for it only to fall apart in test because a basic assumption was flawed, or a critical issue overlooked. Current approach to packaging is favoring keeping the weigh as central as possible and aim to have CofG around wheel center height if possible. Other than that it is simply getting all features in without excessive compromise. Drive it, log it, video it and then back to the drawing board.
With regards to the electronic diffs and steering angles everything is going to be based around two channels of input as you would expect. I will need to look at where the turning center should be and how this changes based on speed. For the first iteration of the control the angles will be pure open loop, zero slip and just assume the vehicle can do what is commanded and see how that feels an performs. Then there will be work to see if it can detect slipping wheels, and a slip angle to the steering at higher speeds, and begin to get an idea of what is possible at different speeds. I strongly expect to have to wrestle dirty IMU feedback and shaky video. PTZ camera for the ‘driver’ would be great but I think that would likely be beyond what the auto driver could achieve and likely need 1/8 scale for space.
So grand vision?
A competition of bespoke built cars racing with fixed wheel base and track.
Limits on servo, esc, flight controller, single board computer, and motor spend along with motor battery spec limits.
Multiple level of competition ranging from heavily assisted driving through to full auto.
Tracks to start simple with features to aid autopilots, such as specified height (up turned guttering etc!) green left hand barriers and blue right. As the seasons progress greater complexity would be added such as two-way sections.
Track layout not pre-shared, but based on a rule set that determines tightest corner etc. Race format includes solo practice solo qualifying then race, heated if needed for numbers.
All designs and software logged with the race authority and open sourced at the end of the season to limit one-team dominance.
Competition set up to reward “build and racers” running on fixed designs through to development teams.
Prescribed safety system that will be able to reduce or completely cut power to ESC. Used for penalty, and safety.
I’ve started to discuss this with a company that loans 3D printers to educational establishments in the UK and I would like to open it up. As the racing is a similar idea to the Donkey Car league I really need to see if there is an opportunity to associate with them rather than make something that is completely separate. Much rather collaborate than compete. All, that said there is a lot of work involved in managing all that and I need to get bread on the table! I’m not greedy but I would need to get something back for my time to be able to put the time in.
At least in my case, I’m not planning to use FPV. With that said, I have already tried to mount camera on one of my rally cars, and it wasn’t that bad. There was some shaking, but it was definitely drivable - at slow speed. See here (and ignore the absolutely lame flying at the beginning, please):
However, full speed would be probably too much for FPV (try it on larger screen):
Interesting, I don’t have any autonomous ambition with my project. I “just” want to dramatically improve traction of a human controlled car.
I don’t condone bating the authorities like this but the video footage from this shows that the image quality can be good enough for what I have in mind.
Regards 1/10 vs larger is is a fine balance, but there are plenty of issues for my project as the scales increase. Typical 3D printer bed size is ~200mm. Yes there are plenty larger but costs go up and I want this to be accessible to back room hobbyists as well as uni project groups. Likewise track sizes need to increase so in an instant village halls drop off the list as potential indoor venues and your limited to school sports halls and similar sized venues.
All that said the buggy/truck format but on road would be easier to work with and the longer travel suspension and more compliant tyres would make getting suitable image quality easier, and potentially reduce the forces on the suspension components a little.