Hi
I'm currently working on my lawnmowing robot and I have a problem where I can't get my head around.
The robot has 2 modes of operation. 1 is autonomous and the other is RC controlled (Futaba TJ6)
I have 2 problem scenarios:
Problem 1: When the robot is in autonomous mode and starts to drive the robot swaps to RC mode. If I detach the front left motor the problem is less severe. (Note that the robot first starts its mowengines; waits for the load on the knives to be low and then starts to drive)
Problem 2: When the robot is in RC mode and standing still (no engines powered) and I turn the left forward drive wheel the mowengines start and immediately stop. (this happens while turning forward or backward)
There are other problems but these are the most striking.
How are the 2 modes of operation setup.
I'm using 4 RC channels. 1)Forward/backwards 2)left/right 3)mowspeed and 4)RC mode on/of.
The RC receiver defaults on "RC mode of". So only when the RC sender is on and the RC mode switch (channel 5) is on the robot goes to RC mode.
From the loggings of my sketch I can see that in problem 1 arduino reads "RC mode on" on the RC channel 5 (numbers which mostly are obviousness wrong). I did not look to get problem 2 confirmed as a RC read error but I have every reason to believe it is so.
conclusion
The 4 driving engines (yes it is a 4 wheel drive mow engine) cause some noise which disturbs the RC reading.
I first thought it was caused by electric noise so I have been acting on grumpy mike his article on decoupling De-coupling But nothing seemed to have any effect. I found no acceptable choke (to expensive) as mike advises for motors. I did find this interesting article on reducing motor noise http://www.beam-wiki.org/wiki/Reducing_Motor_Noise which took me further
I have made a test set-up to see how bad the engines are. I'm not skilled in this area so I don't claim correctness and my material is limited (I use a DSO nano as scope) but I found nothing "wrong" or even slightly spiky, Even when putting load on the engine. I hardly saw a difference between no, 1 and 3 capacitors.
A good explanation on this may be the fact I use a megamoto Arduino shield from robo power (schematic http://www.robotpower.com/downloads/MegaMoto-v1.5-schematic.pdf) which has a 470µf capacitor and a SMBJ30 diode on board.
I have ordered diodes and capacitors (15000uF 50V) for the motor isolation as shown in figure 5 (of the same article) but I have added the diode (capacitor was there already: 100µf before and after the switching regulator) for the electronics. No change in behaviour :~.
On the other hand I'm thinking: If this can happen when I twist the wheel with my hands when no engines are running this is very unlikely a "load related problem"
The only thing which is left is RF interference caused by the motors. I don't think the error can be caused between the sender and receiver as problem 1 also exists when the sender is turned off.
So that leaves a problem in the receiver (now equipped wit a 0.1µf and 100µf capacitor), the wire or the arduino.
any ideas are welcomed.
Best regards
Jantje
Some more background
The robot runs on 2 12Volt 34Ah batteries in series
The robot contains 8 engines; 4 24 Volt drive engines; 2 23Volt mow engines; 2 12 volt cooler vans (currently directly attached to 1 battery)
The drive and mow engines are controlled by mega moto shields Robot Power Products - MegaMoto Motor Control Shield for Arduino
The robot has been running fine with the current software and hardware.
All other peripherals have been removed for investigation without effect.
Have you tried isolation to the motor drivers from the Arduino via opto-couplers (and a separate battery for the control electronics - ie, an R/C battery 9.6V or something like that, with an SBEC or similar to supply regulated 5 VDC to power the Arduino and any other smaller devices)?
Hi Cr0sh
Thanks for the input.
Octo couplers will be hard as I use Arduino Shields. But I'll try a different battery pack for the electronics tomorrow.
As I power my arduino over USB I can unplug it and run from a 9 volt battery. I just need to remember to connect the grounds.
But to be honest I don't think this will fix it. The electronics are pretty isolated now and the wheel turning problem happens at no current usage.
None the less I'll try it tomorrow to exclude (or confirm) this option.
Best regards
Jantje
Have you tested your code without the motors connected - perhaps substituting LEDs or anything that will show that the motor would get the right power if the motor was connected. This should be done to be sure there isn't a problem with the code. I strongly suspect the problem is in the code and is not due to electrical interference (apart, possibly, from the motors causing a voltage drop).
I think it's unlikely that the motors would cause a complex error, such as switching from one mode to another or causing the wrong thing to work properly. If the problem rests with the motors it may be that they are affecting the voltage and causing the Arduino to reset. If that is the case the observed behaviour should be the same as or similar to what happens at power-on - or in other words it should be like some "proper" sequence of events so that you can see what piece of code it is following, even if it shouldn't be using that piece at that time.
Does your Arduino code test for some conditions (such as whether a motor is on, or how much power it is consuming)? If so I would check carefully to see that the correct inputs are connected to the Arduino pins in case it is incorrectly responding to events.
What do you mean by "less severe" when you detach a motor?
When you say "When the robot is in RC mode and standing still (no engines powered) and I turn the left forward drive wheel the mowengines start and immediately stop.!" it is not clear whether the mow-engines should or should not start.
I tried today with a separate battery for the electronics. As I expected I see exactly the same behaviour.
Robin2:
When you say "When the robot is in RC mode and standing still (no engines powered) and I turn the left forward drive wheel the mowengines start and immediately stop.!" it is not clear whether the mow-engines should or should not start.
I realize the behaviour is so wierd it is hard to imagine. I probably should make a movie but I do not have the materials to do so.
Basically: if the robot is in rc mode he should only do what the RC tells him to do.
There are no encoders on the wheels so there is no easy way to detect that the wheel is turned as well.
So basically when I turn the wheel I want nothing to happen. It is a bit like: When I my car on a jack and turn the wheel of my car the windows go down a bit 8)
Robin2:
Have you tested your code without the motors connected - perhaps substituting LEDs or anything that will show that the motor would get the right power if the motor was connected. This should be done to be sure there isn't a problem with the code. I strongly suspect the problem is in the code and is not due to electrical interference (apart, possibly, from the motors causing a voltage drop).
The code is always my first suspect. But in this case the robot has been running on this code for days (He has been doing the lawn for me )
The code has been worked on for years and has gone through serious testing and debugging.
Still code is my first suspect. In this particular case the logging show that Arduino gets a wrong RC reading. On which the arduino reacts as it should.
In other words: When I twist the wheel arduino mostly gets a "turn on the mower" signal which stops immediately at the end of the twist.
I have moved the RC receiver so it is further away from the left front drive motor and the cables from the receiver to the arduino no longer cross the power cables of the motors. That didn't help.
Tomorrow I'll put a servo in the slot for the mower channel and see whether the servo moves.
To make this a bit more real I took some pictures
The picture below is a top view. All electronics are in the box. The Arduino tower in the left bottom is a mega with 1 mega proto shield and 1 go between shield https://www.sparkfun.com/products/11002 and 4 megamoto shields.
The mega is powered via the USB port from a hardly visible switching power module that converts 24V to 5V
And here is why you don't want the mow engines to start by accident.
This is about 64 cm wide
Have you tried your mower with all of its wheels jacked up so it can't move but everything will work. In this mode there will be less power draw by the motors which might eliminate a problem if the problem is due to the motors causing a brown-out.
If it was my project I would create new versions of the code with only one activity in each version and test each activity separately. If there were no problems I would start to combine activities and test again after each new activity was added.
An important aspect is whether it always errs in exactly the same way. If so I would assume it was doing what the code tells it to do - except that it's not what you want it to do or what you think it should be doing.
Radio interference might screw things up but it would be very strange if corrupted signals always matched a genuine signal. Is your receiving code designed only to respond to legitimate instructions - perhaps with some CRC check on the commands? It would be easy to leave a logical gap so that it would respond to all the letters > D (for example) even though you never intend to send anything but A, B, C or D.
Big high current DC brushed motors put out tonnes of RFI unless you take care to suppress it as
much as possible - if you run the wires carrying the motor current close to your receiver it will be
a problem - you have to keep them reasonably far apart in practice, or add extra RF filtering and
use a high quality receiver in the first place (RC receivers are usually only as good as they need to
be to work in the middle of a field).
A update on works but still no progress.
The caps and diodes for the "pseudo isolated power supply have arrived.
I bought 2 DSS25-0025B diodes and a 2 14mF cap. I have a separate power line for the mow engines and the drive engines so I put a cap and diode on both of them. The cap is as big as a drive engine as you can see on the image below.
Adding those didn't make any difference.
I put a scope on the gnd and V5 at the top of the arduino + shield tower. I didn't seen any fluctuations. I had a straight line with differences on the pixel level. This whether I use a lippo battery or with the "normal power supply"
I think this excludes the brownout or other high current related issues.
I also shielded the wires from the receiver to the arduino with aluminium foil. With or without grounded the foil .... same difference.
This setup was not "perfect" as I could only shield untill the arduino so the wires are still unshielded when going from the side of the Arduino to their pins as you can see on the image below. In the middle on the top you can see the aluminium wrapper and the wires. As I use shields the power lines are just on top of those wires.
I had removed all peripherals to investigate the root cause. I reattached my sd card to enable logging. The logging clearly shows wrong reads on the rc channel. The logging data is about 99% correct but there is some data corruption. As the cables to the sd card also pass the power cables (cables on the top left in the image above) and the shield is on top of the power shields .... the power cables may cause some corruption there as well.
I attached the log file (in xls format as I marked the special data in bold). I don't expect anyone to start digging into this to find the problem. I only attached it for background info and as proof that I'm not talking rubbish.
Every line in the log file is one loop run. I dump the same variables with every loop so you can easily understand why decisions are made. The RC loggings are the last columns.
on line 341 you can see the robot goes from automowing started to rc controlled and in the next line to initializing and then to automowing start.
in column fu you see that the rc actually read high for in RC control for 1 loop. The average between loops is 71ms (that is because of the extensive logging). I can not switch a button on and off in 71ms.
MarkT:
Big high current DC brushed motors put out tonnes of RFI unless you take care to suppress it as
much as possible - if you run the wires carrying the motor current close to your receiver it will be
a problem - you have to keep them reasonably far apart in practice, or add extra RF filtering and
use a high quality receiver in the first place (RC receivers are usually only as good as they need to
be to work in the middle of a field).
This confirms my conclusion of the first post
conclusion
The 4 driving engines (yes it is a 4 wheel drive mow engine) cause some noise which disturbs the RC reading.
Seeing the errors in the logs I think I can filter the errors out by throwing away out of range values and taking the median of the 5 last good readings.
That will keep me busy for a while. I'll report back when done.
Just out of idle curiosity I wonder did you mean the "mean" or the "median" because I can't imagine how the median value could solve the problem and if you really do mean the median I would be interested to know how it works?
The median is defined as the middle value of an array of sorted values. The two main advantages of using the median above average is that it is not influenced by a single outlier and it always represent a real measurement. On the other hand by averaging one could create extra precision.
lets assume that we have the following reads for "is rc on".
0 0 0 1 0 0 0 0 0
In this case the robot switches to RC mode after the third read and back to automatic mode after the 4th read. This is unwanted behaviour as it is clearly a wrong read.
If we take the median of the last 3 values we get
median of (0 0 0) -> 0
median of (0 0 1) -> 0
median of (0 1 0) -> 0
median of (1 0 0) -> 0
median of (0 0 0) -> 0
...
So no erratic behaviour.
If the rc on would really be triggered you would get something like
0 0 0 1 0 1 1 0 1 1 1 1
In which case the median would give
0 0 0 1 1 1 1 1 1 1
Again no erratic behaviour
Similar behaviour is shown when you have a range of values. Basically a single extreme read will never be returned by the median.
The bigger the range of the median the stabler but also the slower and the more memory you need.
I hope this explains how it works.
Best regards
Jantje
Another update
The wheel turning engine that caused problem 2 just died.
So probably the engine was kind of broken and caused more RFI than usual.
I don't think this investigation was a waste of time because I have seen similar -but not so explicit and repeatable- behaviour in the past. Moreover more engines will break in the future.
In other words I have a more stable solution now.
Thanks again for all the help
Jantje
)