Acromaster II

[Riccardo Kuebler]

Hi Pete,

I continue here as I would like not to pollute Gulio's thread (sorry
Giulio).
So Aero means G as 2000 = 1G.
Got it about telemetry file.
Thanks for those informations.

The Acromaster was flown with a UDB3 (on Posey's oil pan) and
MatrixPilot r1115 from Google repository trunk.
Yes a very old system and firmware, but it was working well and I should
be able to make some demonstrations with it.

I noticed in the telemetry files that there are a lot of lines missing,
with time jumping.
GPS is a Ublox with helical antenna at 4Hz.
In the telemetry file there are lines showing wind estimation and pwm
inputs and outputs at 0. Even the CPU is sometimes at 0.
There are PWM values at *0000 and there is an IMU glitch also.
Is that a temeletry problem or the UDB is at his very limits? Telemetry
is set at 57600baud.

When I compile I get memory usage at 99% and 63%.

I did a couple of flights on Sunday and had no problems of this sort.
What I changed today is I connected the Openlog (no telemetry on Sunday).

Btw which is the maximum voltage to feed the board through PICkit3?

Best regards,
Ric


---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
https://www.avast.com/antivirus

[Peter Hollands]

Ric,

It's great to see the KMZ file with the flight in the South Swiss Alps.

"Aero" Stands for "Aerodynamic Forces" on the plane. Essentially it what is measured by the 3 accelerometers. But what they measure is not just acceleration. They actually measure (gravity - acceleration).  So in the Aero Force Z axis for a plane that is perfectly trimmed and not side slipping you will see the following figures for a UDB4.

UDB4 flight State                                  Aero Z

Flying inverted and pulling negative 1G            -4000

Level and on the ground pulling no G.              -2000

Flying and pulling 1 G  in a turn                   0000

Flying and pulling 2 G  in a turn                   2000

Flying and pulling 3 G  in a turn                   4000

Flying and pulling 4 G  in a turn                   6000

Helical Turns code in Master is not supported on a UDB3. So you are going to need to use a UDB4 / UDB5 or AUAV3, if you want easy access to that telemetry. (Although you can in theory add the code to get it from your old revision).

I would consider whether you can use a faster memory card in the OpenLog, to try and stop characters being dropped. That is probably where the issue is. The dropping of the characters seems to happen fairly predictably after a few F2: lines have been received correctly. So I suspect it is associated with the time to write the buffer to SDD memory in the OpenLog. 

You may like to cut and paste you memory outputs after compiling to this thread. It sounds as if you are dangerously close to the limit of your micro controller. The printf vsnprintf library used for SERIAL_UDB_EXTRA does use a lot of memory. At one point, a few years ago, upgraded the printf library and it broke our code. So we introduced a special flag during compiling to use the "legacy" stdio library, with the older code. That fixed our issue. I'm not sure that you have that problem now, because your CPU usage seems reasonable, and the newer library used to use far to much cpu.

I'm not aware of the maximum voltage allowed to be fed to the UDB3. I hope Bill can answer that for you. (And add any salient comments of his own to the above).

Best wishes, Pete

--
You received this message because you are subscribed to the Google Groups "uavdevboard-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to uavdevboard-d...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[William Premerlani]

Ric,

1. When powering a UDB from a PICkit2 or PICkit3, the voltage depends on which UDB you are using. For UDB5 and UDB4, set the voltage to 3.3 volts. On all older UDBs, set the voltage to 5 volts.

2. Regarding hovering controls in the helical_turn versions, the new controls are used only for normal or inverted flight. For vertical flight (hovering) attitude, the code is still the old code, but has not been tested to make sure it works.

3. Regarding ways that log data can get lost, there are two ways. One way is some of the older versions of OpenLog could not keep up, and would lose data. The other way is that some of cheaper SD cards can not keep up and would lose data. I assume you know about both subjects, so this is just a reminder.

Best regards,

Bill

[Riccardo Kuebler]

Hi Bill, Pete,

thanks for that infos.

What does worry me the most is data at 0 more than lost lines.
In the attached picture there is an example.
I noticed that setting serial output from UDB extra to none I get memory usage of 93% instead of 99%.
Btw is it a problem having a memory usage up to 99% on a UDB3?

Best regards,
Ric

Now I guess I have few possibilities:
- don't log flights (shame)
- don't use LOGO (shame)
- reduce LOGO pattern
- don't fly
- eventually swap to a UDB4 (when I will have time to set it)

Mail priva di virus. www.avast.com

[William Premerlani]

Hi Ric,

If you look at the time values for the entries you just showed us, you will see that there were lost lines.

So, it may be that the zeros that you are seeing in the csv file are not zeros that were put in the log file by the UDB, they are the values that get into the csv file when there is missing data. For example, attached is a snapshot from your log file, there is clear evidence of many broken or missing lines in the log file.

I think the way that Peter's program converts the log file into csv and kmz file is that at the beginning of each line it initializes all values for that line to zero and fills in only those values that are parsed from the log file. So, a broken line in the log file will generate some zeros in the csv file. I am not 100% sure of that, though, I want Peter to confirm that is how flan works.

So we need to figure out what is causing the broken/missing lines in the log. The most likely cause is either the logger or the SD card cannot keep up.

Regarding memory usage, when you say 99%, is that 99% of the program space or 99% of the data space?

99% of the program space is fine, 99% of the data space could lead to stack overflow, but if that happened you would get many reboots.

Did you see any evidence of reboots?

Best regards,

Bill

[William Premerlani]

Ric,

I took a closer look at your csv file, the zeros are in the lines that were broken or missing. You can tell that because there are time values that are skipped after those lines. So, the zeros were artifacts of the parsing of broken/missing lines in the log file.

Best regards,

Bill

[William Premerlani]

Ric,

There is another option that will allow you to fly with LOGO and log flights: work with Peter and myself to discover what is causing the broken lines in the log file. If it is either the SD or the logger that is not keeping up, there are several ways we can prove that is the cause and get the logging working. Let us know if you want to explore that option.

Best regards,

Bill

[William Premerlani]

Ric,

Regarding your OpenLog and SD card, there are a couple of things you can do to help us figure out what is going on.

1. Put a blank SD card in your OpenLog and power it up, then power it down a few seconds later. The newer versions of OpenLog will create a config.txt file with two lines that will look something like this:

19200,26,3,0,1,1,0

baud,escape,esc#,mode,verb,echo,ignoreRX

If there is no config.txt file, or if it is missing the second line, you have an older OpenLog that may not be able to keep up with the telemetry. If that is the case, it is possible to upgrade the firmware that is in the OpenLog or buy a new OpenLog.

2. Take a look at your SD card and make sure that the speed class is 4 or greater. If it is not, then it might not keep up. Even if it is 4, some speed class 4 SD cards will not keep up. In any case, tell us what brand and speed class SD card you are using, and approximately when you bought it. For more information on SD speed class, see:

https://www.sdcard.org/developers/overview/speed_class/

I am hoping the problem you are having with the flight data is either with the OpenLog or the SD card. If so, it is an easy fix.

Best regards,

Bill

[William Premerlani]

Ric,

One more thing you might try with your SD card if you have used it for many flights, in which case it might be fragmented:

Delete all the files on it and reformat it.

It is my understanding that creating and deleting many files on an SD card can lead to memory fragmentation.

Best regards,

Bill

[Mark Whitehorn]

There's some very good info on SD cards for OpenLog on this page: https://github.com/cleanflight/cleanflight/blob/master/docs/Blackbox.md

[Peter Hollands]

Bill,

Just to confirm that you are correct; Flgiht Analyzer (flan.pyw) initialises most of the variables in a telemetry line to zero, before parsing the line. So if the variable is not found, it is likely remain set to zero. That is true for the GPS time that is stamped on most lines of telemetry.

Best wishes, Pete

[Riccardo Kuebler]

Hi all,

this sounds well. So it seems a problem related to Openlog and SD card.
Memory usage is program memory at 99% and data usage 63%, ok then up to what written by Bill.
I've never noticed a reboot in flight. I have noticed glitches in manual controls, especially throttle, and strange behaviours the first flight and the first time I switch to autonomous instead. Nothing out of control, just annoying.

In the Openlog card there is a single line (57600,26,3,0), definitely an old one. I may try upgrading the firmware.
I just thought that it would work as I leaved it. It was working well, withouth those problems. Now I'm using it exactly with the same hardware and firmware, except the hack ot have it compiling, and same openlog and SD card.
Telemetry file is elaborated by flan in the same version firmware.

But please, don't waste too much time on that subject.
The real goal is to do a demonstration in few classes for a friend teacher who theaches robotics and eventually for the swiss drones federation.

I really should plan an upgrade now.

Ric

[William Premerlani]

Hi Ric,

I am willing to work with you some more on this, I would like to figure it out.

Regarding the openlog and SD card, it does not make sense that they were working before and are not working now, so I am puzzled about that. For now, it is an unsolved mystery. In any case, it would be useful to get them working again, so we might want to try a couple of things. The simplest and easiest thing to try first is to reformat the SD card.

Regarding the glitches, I would really like to fix them. There are any number of "system" issues that might be causing them. Before we explore in that direction, I would like to investigate the possibility that the hack has somehow caused the glitches.

One possibility has to do with a combination of the hack and your oil pan.

The hack had to do with selecting the pins for the debugging port on the dsPIC. The hack that we did turned off the selection of the debugging port, so we are now getting the default debugging port, which the oil pan might interfere with.

So, if you want to explore a bit more, please tell me the following:

1. Which pins on the UDB3 does the oilpan connect to, and what does the oilpan do?

2. Which branch and revision number of MatrixPilot are you using? (You told me once, but I forgot.)

3. Please send me your options.h and waypoints.

If it does turn out to be an interference between the oilpan and the debugging port, I might be able to build the firmware here without the hack and send you a hex file.

Best regards,

Bill

[William Premerlani]

Ric,

There is a slight chance that the "ICS" hack is causing the symptoms that you are seeing. Here is how that might happen.

On the UDB3, there are 4 choices for the pair of pins for debugging using the PICkit, including the two pins that are used for the serial data. If that port somehow got selected, I am not sure what would happen, it might cause trouble.

In the earliest version of MatrixPilot and MPLAB, you set the selection of the debugging port using MPLAB. Later, Microchip moved the selection of debugging port to software. You specified which port to use by specifying the value for _ICS. The port that is supposed to be selected is the pair of pins in the ICSP.

However, when you tried to do your build, the build failed at the line that was specifying _ICS. So, I told you to comment out that line. However, with that line removed, it is possible the debugging port is set to the wrong pair of pins.

So, if you want to dig a little deeper, please do this. (I assume you are still using MPLAB).

Do a clean build of the software you are using on the UDB3 in question. When you are done, select the Configure tab at the top of MPLAB, go down to the Configuration Bits menu item, and select that. Take a screen capture of what you see and send it to me. I have attached a typical view of that window, but keep in mind, I did not do a build, I am just showing you what the window looks like.

The item that we are interested in is the last item, "ICS". The correct value for MatrixPilot on a UDB3 is C003.

If you are seeing some other value, we are going to have to figure out a way to get it set to C003. There are several ways we might do that, but first lets find out if that might be the problem.

Best regards,

Bill

[Riccardo Kuebler]

Hi Bill,

oilpan is Tom Posey's one. Here are schematics and instructions.

I did the build and attached you will find the screenshot of Configuration Bits.

I recall also that there where problems with the tx pin left unconnected. I can't recall from which version it was solved.
Btw Openlog was connected with a 3 wires cable: Vcc, Gnd, Rx (UDB side).

Yes, I'm using MPLAB.

In the meantime I copied all the logfiles to pc and did a format of the SD card. Btw they where not much (~20-30?)

Thank you very much!
Ric

[Riccardo Kuebler]

Hi Bill,

correction: Openlog is connected as Vcc, Gnd, Tx (UDB side) ... obviously = :D
UDB rx is left unconnected.

Best regards,
Ric

[William Premerlani]

Ric,

Ok, so the configuration bits are ok and now I am scratching my head, I cannot think of any reason why you are seeing some glitching in manual mode if you have not changed anything since the last time.

Are you sure about that? Can you think of anything that has changed? Perhaps your transmitter and receiver are different?

If the format of the pulses has changed, that might cause problems.

Are you sure you are using the same SD card as before? The SD cards are the usual source of problems when the logger fails.

In the meantime, it would be nice to get the OpenLog working properly. There are two reasons for that:

1. If we can get it working, it will give us data to help debug the problem.

2. If we cannot get it working, that will give us clues, too.

20 to 30 files are not many files, but I never leave more than 3 or 4 files on my SD card, so I am not sure about that.

Anyway, since you have erased and reformatted your SD card, the next step is to do some ground testing and see if the lines in the log file are getting broken or not.

Best regards,

Bill

[William Premerlani]

Hi Ric,

Regarding the broken lines in the flight data log, if reformating the SD does not work, another thing to try is to use 19200 baud instead of 57600 for the logger.

It seems to me that when you first set up your Acromaster, you were using 19200 baud, that was the default for MatrixPilot then.

It might be that the older version of OpenLog that you have in your Acromaster has trouble keeping up at 57600.

Best regards,

Bill

[Riccardo Kuebler]

Hi Bill,

I did a quick power up of the plane and seems Openlog is logging well. I will do now a longer time to watch it better.
About glitches I had a quick downpitch on the first flight I did few days ago. Then I noticed it only on the throttle. I have to check the ESC log to watch if something is related to battery, but in this case I guess there should be a reboot. Btw I use those batteries on a multirotor and they seems to work well.
Strange the IMU report from the mentioned flight at beginning. I had to set the file 10m higher as it is showed underground at takeoff.
Picture attached.

Unfortunately it's raining and I can't do better on the field testing.

Best regards,
Ric

[Riccardo Kuebler]

... forgot to say: I took off in manual mode.

Here is a log of about 15min. I only found a single line with some values at 0 and flan pointed only a few errors. In the last ones flan pointed a lot of errors.
GPS data are jumping all around, because I did it inside (thick stones walls).

I will do some flying in the next days to watch how it goes.

Best regards,
Ric