You could use the watchdog, but I just prefer to use a separate chip for this project.
At any rate, Testing on the ESC completed with the following results:
1.97ms positive extreme
1.46ms neutral
0.911ms negative extreme
EDIT: Vsignal is 3.3V
It’s probably a good idea to avoid exceeding any of these numbers. In fact, these are the numbers that I tested to, but you may even think about padding the extremes slightly.
Next up is testing the steering servo…
Testing of the steering servo has completed…
2.00ms positive extreme (left)
1.53ms Neutral
1.03ms negative extreme (right turn)
Vsignal is again, 3.3V
One of the benefits of managed code is that it is much harder to do something wrong and get the whole works locked up; native code is much more prone to errors that cause a catastrophic crash. There is no advantage to having a supervisor running native code other than you could probably use a smaller/cheaper processor to get the job done.
Alright, last update for the night.
I got the ESC driver up and running, and everything looks alright on the scope. I’ll have to test things tomorrow when my battery is done charging*, and I’ll post the source then.
The class works pretty much like this:
SpeedController xl5 = new SpeedController(FEZ_Pin.PWM.Di8);
xl5.DriveMode = SpeedController.DriveModes.Reverse;
xl5.PowerSetting = 100;
That code snippet would cause the car to go reverse at full speed. For cars that don’t have reverse, you can use DriveModes.FullScale.
Again, I still need to test it more, but it should be up sometime tomorrow.
Good job so far Chris.
Alright, well, I just got done with the first batch of ESC tests and the results are looking good.
Part of the reason why I want a dedicated chip as a failsafe is that the Domino has a tendency to pull the pins sortof high when they aren’t in use. During testing, the car leaped into full throttle for a second because it thought that it was being signaled, when in reality, the Domino was just starting up. I suppose I could get around this, but I seem to recall that the ATmega328 will not do stuff like that unless the firmware is being reflashed.
At any rate, my timings are pretty close, but they aren’t right on. 90% of what I saw during testing was exactly what I predicted. The car started at 0 and gradually ramped up to full throttle until it turned off again. I need to work on this more, later today.
It leaped into life? Hum. Hey Gus are the outputs of the Usbzi guaranteed to be in a particular state at start up? I.e. would pin x gaurentee to be low until it’s told to go high by code?
On power up all pins are in the input state. This is standard for almost all MCUs
I should add to Joes’s answer, they are inputs with internal pull up resistors.
It leaped to life for a split second. If it were on the ground I’ll bet the slipper clutch would have disengaged and it wouldn’t have taken off or anything, but on the bench with the wheels turning freely it made me jump :
As for the state of the pin at initialization, I’ll need to check what was going on there with the scope.
So then if I connect an NPN transistor to a pin, the transistor will be off right? Guaranteed…
The best way to handle a situation like this to ensure that the controller is powered up before any the drive power. On a large machine we would use a contacter that would require an EStop circuit to be reset and the controller to be in certain state before it could be engaged and supply power to the bits that move. On a small thing like an RC car you could do something as simple as have one power switch for the electronics and one for the control.
What happens if the ESC receives a steady state signal instead of PWM signal? If a constant HI or LOW caused it to shut off the output then you could use an AND (or NAND to invert the output) gate to control the flow of the PWM signal. One input to the logic gate would be the PWM signal and one would be the control signal. A LOW on the control signal will force a LOW on the gates output so the PWM will not get through.
Keep in mind that the ESC might cause the motor to jump when the ESC is powered up as well but putting a switch after a speed controller is typically a bad idea as you don’t to remove the driven load all of the sudden.
The motor will jump a few seconds after starting the Domino, so I know it’s something coming from that.
I have a feeling that the ESC is jumping when the PWM pin is instantiated, so what I might do is just press a button on the Domino to start the pin, then turn the ESC on (it’s got an on/off function built in).
I don’t know what happens when the ESC receives a steady HIGH signal, but I do know it will turn off if the pin is held low for more than 20ms.
Wait, The ESC causes the motor to pulse a few times on start up? I noticed that behavior when the ESC was not connected to any PWM source at all. After the first few jumps it’s started the motor running at full speed. I just thought that it was programmed to do that to tell you the controller was off.
Anyone else have a similar experience?
You might find ESC’s pulse the motors that they are connected to when they are powered on. To test whether the Domino is doing anything “different” to the RC control, go back to having the Rx connected to the ESC and power it up again, you will probably see the same behaviour.
Wait, WTF?
The ESC should be at total rest when it’s not connected to a signal. The pin may be floating which may cause some hose up, but it should never suddenly go full speed out of nowhere for any more than a split second.
What kind of ESC was it? Where did it come from?
It says this on the sticker:
“Electron Speed Control 3870 P160A”
The car is a : Victory Hawk VH-36 [url]http://en.victory-hawk.com/newEbiz1/EbizPortalFG/portal/html/ProductInfoExhibit.html?ProductInfoExhibit_ProductID=c373e916a579a9a08fef4c6c5aba22c8&ProductInfoExhibit_isRefreshParent=false[/url]
Well, I solved the “jump” issue. Basically, the car will jump right after the PWM signal is started, even if that signal is neutral. The fix was to remove one line of code after the PWM initialization. that set the pulse to neutral.
I’m now experimenting with different speeds and drive methods, so I’ll post the code in about 2 hours.
So far it looks like 15% is too slow and 22% is way too fast for my first mini project :o. This car has a lot of “umph”.
Ok, guys, I have the source code to a point where I believe it to be stable enough to run with other Stampede XL-5s ONLY. The timing settings in the driver files need to be modified to work with any other car. Eventually, the settings will be modular.
The zip file is here: http://files.chrisseto.com/c5V
The servo and ESC drivers are in the “Drivers” folder.
On the hardware side, the servo is connected to the 6V out pin of the ESC, both the ESC and servo are grounded together with the microcontroller. The ESC/servo signal pins are connected to PWM pins.
Give me a day, and I’ll have something much more fun written ;D
Also, be careful with the reverse function of the ESC driver. Everything look fine on the scope, but something is still wrong with it. For now, DO NOT USE it.
One more note: The ESC will only obey your commands if you ramp the wave up. You cannot suddenly apply the pulse length when you are increasing the throttle. Future version of the driver will have this hard coded in.
In my experience, 50ms is a good time to wait in the ramp loop, but it probably could be tighter.
Here is a new version of the original drivers (same URL) http://files.chrisseto.com/c5V
This also includes an example program, where the car will maintain 22% throttle until it sees a wall. It will then let off, but will not brake or reverse. Be careful if you do run this demo. I only had 20ft to test it on carpet, and the car got up to speed quite quickly. After a while, it may not be able to stop in time for the wall or object in it’s path.