Hey guys,
First of all wanted to say that I am very impressed by what you have built here with the VESC tool.
My team and I are currently involved in a time-sensitive robot project. In essence this is a large (25KG, 600x500mm base) line-follower robot with infrared sensors. We're using an Arduino Mega with an expansion board. The board powers 7 separate Infrared sensors for the line detection along with a small LCD display. For motors, we are using 4 X 350W/36V 6.5" Hub motors from two identical hoverboards (same brand, internals and everything).
We completed Motor wizard, FOC/Hall calibrations separately for each motor. Each motor parameters varied some, but as I understand this is completely normal as no motor is the same, essentially.
We then calibrated the PPM input by programming the arduino to modulate a PPM signal between 1000 > 1500 > 2000 ms. After refreshing the values and applying them, we confirmed that the Arduino modulated signal corresponds with Max, Min and Center values in the live data of the VESC tool. Since we need active braking as well as reversing function to be available, DUTY CYCLE was chosen for all 4 motors.
At this point we let the motors run at different PPM values and monitored the NO LOAD RPM and DUTY CYCLE %. What surprised me was that with the same PPM value, the VESC displayed a varied Duty Cycle % (+/- 5%) between the motors. At low NO LOAD RPM the motor RPM would vary by ~5RPM. We also tried putting the robot on a flat surface and it would veer to one side about 30cm after traveling about 5 meters. This meant that even with load the motors varied enough to be unacceptable. We then made a graph of the differences on excel, noting that in slow speeds the RPM varies the most, while in the higher speeds it evens out (btw, higher speed was still within SENSORED ERPM). We also noticed that when the duty cycle is reversed, the RPM difference is even greater and motors run more poorly.
I'd like you to give our process summary a good read and maybe you could see what we're doing wrong.
I would also like to know whether it's possible to use PWM instead of PPM as I believe it's more accurate and reliable?
Also, during all of this we noticed some fluctuations in the RPM depending on whether the FSESC was connected to arduino with all three pins (black, white, red) or only via signal pin (white). Seems like a great mess of issues and at this point my knowledge of this stuff has reached it's limit.
Any help appreciated, thanks!
Matt
.
Have you made sure there is no ground loops? Each vesc should only have ground trough power ground and 3 of 4 small black and red signal wires should be cut if the all 4 vescs are driven from the same source. Have you tried altering the deadband percentage in ppm window? I would imagine putting the center value on the "fast" motors slighly behind the two slow ones could help to some degree. I don't have much experience with FOC but isn't there a minimum current on minimum duty cycle you can change? Some of this info might be obvious but it could have some value to beginners reading this post later on :) I have 4 hoverboard motors on my eboard and I found that the motor resistance windings varies quite a lot, with some brands having much better tolerances than other brands.
Mod everything!
Use RPM control, also called PID speed control. Will give you much better accuracy on the motor speeds.
I would also use CANBus if possible for controlling them as you can then just tell it to turn the motor at X RPM instead of an analogue PPM value, which is also affected by noise.
Other solution is to use UART.
Impuls60, thank you for the reply. Firstly- another question for you. What is the reasoning for cutting the 3 out of 4 red/black wires? I assume this is to power the Arduino from 1 FSESC, but avoid excess/unnecessary noise from the remaining power wires? The ground problem was solved for now by following a sequence when turning everything on. Initially we turn on the main power and only then the Arduino is powered via FSESC. This seems to initialize motors nicely. We also added about 15 extra kilograms to simulate the final metal box's weight which will enclose all the components. In the end it seems to go pretty straight and where we need it to go. We also added some additional code to slow one side of the motors resulting in a "correction" of the direction, when the sensors detect only a slight discourse, without having to completely stop and then "Tank turn" (one side forward, one side reverse, like those "zero turn" lawnmowers). Having the extra weight really helped the motors work at higher loads where the variation of RPM's is only slightly noticeable.
Will check the minimum duty cycle range as well as the deadband. We actually played with the deadband but only to make it same for all of the motors and avoid the erratic behavior of the motor when at 0-5% range of PPM signal.
TachAUmNu, thanks for the reply!
We skipped the PID control in fear of not being able to properly set it up. Is it a tricky process in your opinion?
If we were to use CANBus what cable would we need? Also, what would be tha cable and port used for UART? We're using the single motor FESC's with 4.12 hardware.
How is that 4.12 holding up? I am a newbie build a 6x6 robot lawn mower with 6 6.5 hoverboard wheels. I am trying to take notes and learn.
Artius Reynolds
PPM on 4 devices will only work with optocouplers. Otherwise you will always create a gnd loop. Also make sure to decouple the Arduino from the ESCs. CAN is the way forward. RPM control or duty cycle control will create issues. All wheels will want to spin at slightly different speeds and so one wheel speeds up another one and that wheel will regulate against the other and this wheel will try to compensate again etc. So basically the wheels will work against each other and funny oscillation will be the result. Have a look at the cruise control algorithm inside the VESC FW. This method avoids the problem by a mix of duty cycle control and current control.