|
| From: | Refik Sever |
| Subject: | Re: [Paparazzi-devel] simultaneously using two autopilot systems for reliability |
| Date: | Mon, 25 Nov 2013 22:16:15 +0200 |
Hi Stephen, Thank you very much for the comments, Refik From: address@hidden [mailto:address@hidden On Behalf Of Stephen Dwyer Hello, A couple comments that might help: It definitely sounds like you have a power problem that causes resets or brownouts (after which who knows what might happen, given no watchdog currently). I would really suggest avoiding the use of the 5V linear regulator onboard Lisa/M v2 unless you are power nothing else. This is a known design limitation - the regulator can not really handle any peripheral loads as it is only rated for 250mA. I like to power my board with 5V directly and bypass the onboard 5V regulator. See http://paparazzi.enac.fr/wiki/Lisa/M_v20#Powering_the_Board for more details. My guess is your radio draws perhaps 100mA or more, and if you consider all the other peripherals and the STM32 draw as well, at 12V input brownout or thermal shutdown is highly likely. Regarding i2c, I am not 100% sure the current status of that issue, but I do know trying to talk to the eagle tree sensor before it is ready causes the i2c hardware to lock up. I also think that you might be able to power the eagle tree sensor a little bit just over the datalines, especially if there are pullup resistors letting some current through. I think setting up a watchdog and resetting the autopilot in flight is fairly dangerous. You will need to carefully comb through all the code and check all the initialization. For one, if you are using an internal AHRS, the AHRS needs be aligned on startup without moving the IMU. This is difficult if the aircraft is already in the air... If you are only wishing to get back into a mode where you can manually fly the aircraft, that would be much easier. Of course, if you are using an external INS/AHRS then this alignment isn't required. I think your best bet is still to look at your power supply and clean that up (also make sure no ground loops), and bench test after that to see if you still have failures. Perhaps someone with more knowledge can weigh in as to whether an in-flight restart is feasible. Thanks, -Stephen Dwyer On Mon, Nov 25, 2013 at 12:04 PM, Refik Sever <address@hidden> wrote: Thanks Michal... From: paparazzi-devel-bounces+refiksever=address@hidden [mailto:paparazzi-devel-bounces+refiksever=address@hidden] On Behalf Of Michal Podhradsky
Refik, just a side note - we have BlackMagic debugger and pretty often we have that flash erase error (both when uploading from Eclipse or Paparazzi center - obviously it is gdb related thing). But you can upload for second time then it usually works. Try this command sequence in gdb: and then load the target monitor option erase should undo the flash write protection, but sometimes it just doesn't work. M On Mon, Nov 25, 2013 at 11:36 AM, Refik Sever <address@hidden> wrote: Hello, Chris, I observed that when the modem tx power is above 25mW, then the voltage of modem drops to 4V. Thanks for warning. We will give the voltage from a different supply. Michal, I was not aware of I2C issue. We are using airspeed and temperature sensors connected to I2C. It seems that the I2C issue is a serious problem. We bought a BlackMagic probe and today we start working on debugging. We tried to upload using JTAG cable, but it always gives an error that it can not erase the flash when we upload from GCS. When we upload from terminal, it usually uploads successfully and sometimes it gives the same error. We want to have a very reliable system which can work for hours. I am planning to use a second autopilot which does not have any peripheral. It will be connected only to GPS, and maybe to modem also. It will always be on standby mode. I ordered an FPGA board. If it works porperly, I hope that the system will be more reliable. And I understand that using a watchdog timer outside of the microcontroller will be better. I am planning to use the FPGA for that purpose. Do you have recommendations about the connection of the second autopilot? 1. We can add the second autopilot with a second modem using API mode and the GCS will see the two autopilots as 2 different airplanes. 2. We can add only one modem and both of the autopilots will receive same commands from GCS, but only one of them transmits data to GCS. 3. The second autopilot will not have a modem. It will always be on standby mode. If the primary autopilot will freeze, the second autopilot will bring the plane to the standby. Regards, Refik From: paparazzi-devel-bounces+refiksever=address@hidden [mailto:paparazzi-devel-bounces+refiksever=address@hidden] On Behalf Of Michal Podhradsky
Refik, since you mentioned using I2C, look at the pending issue with I2C causing the autopilot to freeze (https://github.com/paparazzi/paparazzi/pull/531). What happens if you disable the I2C sensor, does it still hang? Also, do you have a debugger (http://paparazzi.enac.fr/wiki/JTAG)? That would be probably the easiest way to find what happened. On Mon, Nov 25, 2013 at 9:40 AM, Eduardo lavratti <address@hidden> wrote: When i do the first test with mine lisa_m it reset or hang. From: address@hidden
Although we do not give power to the Ets in the upload, its 7 segment display works and blinks. I think that it takes power from I2C pins. Does it create a problem in the upload? I don't know. Can you remove everything then add them back one by one, testing in between? That's software-guy thinking, maybe a hardware person has a more informed idea... Chris Gough
|
| [Prev in Thread] | Current Thread | [Next in Thread] |