So I spend a few frustrating hours tracking down a bug in this seemingly simple idiot proof code:
long labs(long val)
{
long retval;
if (val < 0)
{
retval = -val;
} else {
retval = val;
}
return retval;
}
So most of the time this code does exactly what you might expect. It returns the absolute value of the parameter you pass in. All except in one case. Can you figure it out? Answer after the break. Continue reading
I have this bizzar bug that comes and goes. When connected to the JTAG pod, I never see it. When operating disconnected, it will in fits and starts not boot properly. Since it never seems to happen when connected to the JTAG pod, it is making it very difficult to hunt down.
I have come to call this the “Nap Bug” as it seems to clear itself over time. This made me think of a temperature, but that does not seem to be the case.
On other news, I data logged my commute to and from work from inside my car. The track supperimposes on Google Earth with amazing accuracy. This this 1/2 the satellites obscured by the metal car roof. I love this GPS (uBlox LEA-6H) from HobbyKing ($50).
I have now gotten a shell of the navigation thread running. This thread takes a semaphore from the GPS thread at the end of each update. This is currently set at 5Hz. The purpose of this thread will be to compute the speed and steering commands for the next period of time. Currently I am implementing a very simple homming algorithm just to get going.
My GPS provides either ECEF or L/L in degrees. ECEF is not ideal in that you need to do some trig before getting into grid like coordinates. L/L in degrees is strange as well. With the binary format, I would have assumed the value to be in radians as the user would likely want to use trig functions on them. I guess its not a big deal as it only adds a multiply to scale the value.
I was going to convert the L/L into true MGRS or UTM so that I could map paths using Google earth, but have decided against it. The math to do so is ridiculously complex for what little benefit it would give me. As such I am implementing a personal private grid system. I will take the L/L and subtract a know grid reference location from it. I will then scale lattitude to meters knowing that a minute of arc is a nautical mile. Scalling of longitude needs the scaling factor based on the cosine of the latitude. This I will simplify with a single constant for the working area.
I will assume that I will have another higher speed control task running to do such things as filter the commanded servo controls to prevent jerking and to implement PID loops for speed control. 5Hz for the basic waypoint nav and perhaps 30Hz for the control task should do the trick.
I got the statistics task running and find that I am only currently using about 4% of the CPU cycles. This is good as I am only just starting on the hard math.
My near-ish term goal is to set a waypoint across town and watch the steering servo for glitches. I will then bring the waypoint closer to me and see the efects of the GPS position wander.
The speed control module that came with the second hand RC car I bought (a Traxas Rustler) does not seem to allow for low speed control. It seems to go from off to 1/2 speed. Is this the normal mode for these speed control units, or do I need to think about a new ESC? Currently I am sending a PWM signal to the PWM ESC to get slow speeds. Idiotic!
Another frustrating evening. On occasion, my processor will not boot if you press the reset button. You can press then button a hundred times and nothing. And yet it never seems to fail when commanded to reset from JTAG.
Since I will be running outdoors soon, I decided it would be a good thing to find this bug. So I sat down to work the issue and after two hours I was unable to reproduce the issue. Could it be the instrumentation that I added (short GPIO pin pulses) that changed the behaviour?
I was unable to allow the dog to sleep. Had to find the bug or I was not going to be able to sleep.
After a few more occurances, I had enough data to give me reason to suspect I was going out of range on the GPS receiver buffer. So I instrumented that section of code and let it run. An hour later, the code triggered and I had my answer. The GPS decided to send me a message I had not registered. It was larger than the buffer size I had allocated based on the messages I had registered for. To make matters worst, I had an error in the code that checked that the message would fit in the buffer. Made the correction and let it run all night. No errors!
Now its time to start logging the GPS data to the SD card.
I have a crash that occurs at somewhat random times. It may go 20 minutes or it may crash within a few seconds. The blink code on my LED indicates a Prefetch Abort. In other words, the instruction it went to execute was bogus. Breaking in the debugger the registers only point to the bogus instruction. This address is well outside of valid RAM or ROM address spaces. I suspect that a jump is using a bogus address and jumping into the weeds. Continue reading
Last night I stopped trying to add more functionality and get to the bottom of these random crashes. If I have lots of GPS data flowing through the system the system will crash in various ways. One way includes a Data Abort exception. This usually means a bad point or corrupted data. Overrun stacks is a great way to corrupt data. Continue reading
What a horrible day this has turned out to be. Continue reading
Today I was going to finish the GPS code for the robot when I discovered that my automated backups had not run in a few days. Sure enough I found a bug in my software that does backups. Lets hope this does not take long to fix.
Saturday I connected the GPS module and for a few seconds things looked good. But then the dreaded Data Abort exception started to occur. I have yet to narrow the problem down, but it would seem that bad things happen when the UART circular receive buffer becomes full. I hope to get more time today to isolate and fix.
This weekend my goal is to get my uBlox LEA-6 module connected to my ARM processor. I have lots of other things I have to do this weekend (pay bills, …) but with a good following sea I should be able to make the goal. Fingers crossed. Continue reading