paparazzi-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Paparazzi-devel] First step with stm32f4_discovery


From: Hector Garcia de Marina
Subject: Re: [Paparazzi-devel] First step with stm32f4_discovery
Date: Tue, 31 Jan 2012 16:03:30 +0100

Hi Felix,

I realized that an RTOS was needed when I wanted to introduce other tasks in a clean way, without interfering the "main core". Tasks such as guidance, cooperative stuff with other vehicles, model identification, "heavy" models (like Earth's magnetic field) or whatever.

FreeRTOS is very simple to use, and it has a good documentation. ChibiOS is very simple to use as well, and you can have all tasks + core in a static way if you want (safety), the kernel is very light (about 4KB).

The plus of ChibiOS over FreeRTOS is that its development under ST micros is very active and currently they have (optionaly) a HAL layer for almost all micro peripherals (serial port/SPI/I2C with DMA, SDIO, etc). Currently the M4F (floating point hardware) is supported as well.

We can discuss it tomorrow in the IRC channel (sherinian xD).

Héctor


On Tue, Jan 31, 2012 at 3:04 PM, Felix Ruess <address@hidden> wrote:
Hi Hector,

that is very good to know! I wanted to add the option to use an RTOS
under paparazzi for a long time already. I had originally looked at
FreeRTOS but recently tended more to ChibiOS. I haven't had the time
to really try them out or to do a proper comparison. But there were a
few minor things that let me lean towards ChibiOS.

It would be really great if you could help out here and provide some insights.

Cheers, Felix

On Tue, Jan 31, 2012 at 2:38 PM, Hector Garcia de Marina
<address@hidden> wrote:
> Hi Heinrich,
>
> this is the actual board and operating system that I am employing for the
> development of my next autopilot.
> You can reach me in the ChibiOS forums if you need any help.
>
> Héctor.
>
>
>
> On Tue, Jan 31, 2012 at 1:14 PM, Prof. Dr.-Ing. Heinrich Warmers
> <address@hidden> wrote:
>>
>> Hi,
>> i found this project:
>>
>> http://www.chibios.org/dokuwiki/doku.php?id=chibios:articles:stm32f4_discovery
>> The pcb has the accelerator chip on board.
>>
>> Heinrich
>>
>> Hector Garcia de Marina schrieb:
>>
>> Actually,
>>
>> you can use the
>> http://www.ftdichip.com/Support/Documents/DataSheets/Modules/DS_FT2232H_Mini_Module.pdf
>> as well. I has been using it for both JTAG and Serial Port , as it is
>> employed in Lisa-L, it works well with OpenOCD.
>>
>> Already, gcc provides a pre-built tool-chain for ARM baremetal systems
>> (cortex m0-4), including multilib for cortexm4f. So you do not have to build
>> them anymore if you do not want to do it.
>>
>> Héctor
>>
>>
>> On Tue, Jan 31, 2012 at 11:52 AM, Prof. Dr.-Ing. Heinrich Warmers
>> <address@hidden> wrote:
>>>
>>> Hi Stewart,
>>> yesterday i got the olimex stm32 (26 Euro). I think this is also a
>>> candidate for low cost autopilots with paparazzi even for quadrocopters.
>>> You can by a jatag interface  ( OpenPilot Foss Jatag)   for 30 Euro
>>> (http://www.opstore.eu/en/2-openpilot) This is based on the work of  Piotr
>>> Esden-Tempski with the extension that more than one adapter can be used on
>>> the same usb connection. I think this is also working with the paparazzi
>>> hardware (Lisa). A tool chain is the GNU 4.6 CC  in combination with open
>>> cd.
>>> I am  angry of the politic of ST to sell MEMS sensors. Often the chips
>>> are only available for  less than two years. In 2007 an accelerator sensor
>>> in dual line package for the Mikrokopter pcb and in 2010 the rate sensor for
>>> the hbmini autopilot, razzor and adreimu..
>>>
>>>
>>> A low price hardware for the STM  is OpenPilot CopterControl Board
>>> http://www.innov8tivedesigns.com/product_info.php?cPath=125&products_id=894
>>> 89$
>>> I hope to hear more of your work. Good luck.
>>>  regards
>>>
>>> Heinrich Warmers
>>>
>>>
>>> Jake Stewart schrieb:
>>>
>>> Thanks Felix, I was hoping someone could clear that up.  I'm not quite to
>>> that stage yet, but I'm reinvigorated to know that there's the possibility
>>> of help if I get stuck.
>>>
>>> To explain a bit more about my project... I liked the idea of using ST
>>> chips for the IMU since they were cheap and had free samples available.  ST
>>> had also been starting to hype their "iNemo" sensor fusion and AHRS
>>> platform.  iNemo is supposed to run on STM32F103s, at least at first.  That,
>>> combined with the fact that LISA uses a STM32 processor, got me thinking
>>> that a STM32 + ST accel/gyro/magnetometer combo was the way to go.
>>>
>>> So I decided I better learn the STM32 and got a couple VL Discovery
>>> boards.  When I got the Discoveries I was pretty impressed with the units,
>>> and thought I'd do well to explore the capabilities.  What I found out was
>>> that the Discovery actually has both F100 and  F103 processors.  The F103
>>> runs the "ST-Link", which is STs USB programming/debugging link.  What's
>>> cool about the Discovery units is that there are two 4-pin headers on the
>>> board.  If you jumper one side you use the st-link to program the onboard
>>> F100.  If you remove the jumpers then the other 4-pin header allows you to
>>> use your discovery to connect to any other ST processor and flash/debug it.
>>>
>>> After reading about a hack to program the F103 using another discovery
>>> unit, requiring soldering two wires to one side of two SMT solder bridges, I
>>> figured out how to tie the right pins together on the bottom so that you end
>>> up with one header to program the F100 and one header to program the F103.
>>>  Now I could easily flash and debug either processor on the board.  So now
>>> the Discovery becomes a nice little dual processor dev board with USB.
>>>  Unfortunately, the F103 is not connected to very much, and what it is
>>> connected to is a little less than clear to me.  The processors are
>>> connected together by at least two lines and the F103 is connected to a USB
>>> port.  I also know that none of the I2C lines are connected and the F103
>>> does not have a digital crossbar.
>>>
>>> What I ended up doing for the moment was to pull up two I2C pins and
>>> solder little wires to them.  I think I've come up with an easier and better
>>> method now that involves tacking some small wires to the processor,
>>> scratching out a couple existing traces, and tying those I2C lines to the
>>> existing header pins.  It's somewhat tedious, but making a nice autopilot
>>> board for under $10 seems worth it to me.
>>>
>>> Anyways, the master plan is to have the F103 tied to the IMU and running
>>> ST's iNemo sensor fusion / AHRS firmware.  The F103 will be dedicated to the
>>> sensor fusion and processing the "true extended state Kalman filter" that ST
>>> is hyping.  It will also do some USB tasks, communicate with the F100, and
>>> do whatever else it's limited connections will support (hopefully flashing
>>> the F100 and helping put settings into it from the USB).
>>>
>>> So essentially I have the hardware side worked out and now I get to enjoy
>>> the real fun of beating my head against the wall trying to program the
>>> thing.  But, I don't see any insurmountable problems standing in the way.
>>>
>>> Right now my problem is that the code ST has released only compiles on
>>> IAR 5.x.  I wrote and asked them for Atollic/eclipse support and they told
>>> me that only IAR is supported for now.  I wrote them back and told them that
>>> IAR is NOT supported, only an old version of IAR that you can't get anymore
>>> is supported.  IAR 6.2+ has some major CSMIS problems which seem to have no
>>> good workaround since ST doesn't seem to have any CSMIS files out that
>>> actually work with current versions of IAR.
>>>
>>> So I need to figure out how to compile the code on some toolchain that I
>>> can actually get my hands on.  I just don't know enough about these
>>> toolchains to figure it out at the moment.  Seems like there's a lot of
>>> workspace/project file settings to configure, and I don't really know what
>>> I'm doing.  The free version of Atollic doesn't have the graphical setup
>>> features of the pro version, so it seems like I have to do a lot of digging
>>> through XML files and the like to get things running.
>>>
>>> At the moment I can flash the iNemo DFU firmware onto the F103 and the
>>> iNemo code also.  The DFU firmware (USB firmware upgrade tool) works just
>>> fine.  I can actually use the USB connection to flash whatever I want onto
>>> the F103.  Of course, the iNemo code is written for their $250 IMU
>>> evaluation board and I need to change a few settings to work with my pinout,
>>> and strip away the rest of the code related to their other sensors.
>>>
>>> My limited success with the iNemo code has kept me mucking about with it,
>>> but I'm about ready to try and get the PPZ code running on the F100 and
>>> worry about iNemo later, if I even really need it.
>>>
>>> Is anyone else interested in working on this project with me?  The
>>> potential benefit of the project is the development of an ultra-cheap PPZ
>>> hardware platform.  It also will offload the effort of AHRS and sensor
>>> fusion to ST.  Hopefully they can then do all the math and worry about
>>> supporting their chips.
>>>
>>> ST is also now producing a cheap ($35) little IMU designed to plug into
>>> their sensor eval board (STEVAL-MKI108V2).  It uses the latest L3GD20 and
>>> LSM303DLHC MEMS sensor chips. (L3GD20 is the replacement for the L3G4200D).
>>>  The L3GD20 is claimed to be immune to audio frequency noise and vibrations.
>>>
>>> STEVAL-MKI108V2
>>> http://www.st.com/internet/evalboard/product/252687.jsp
>>>
>>> So the end product of the project will be a PPZ hardware platform
>>> consisting of:
>>> STM32VLDiscovery - $7 (new ST suggested retail price)
>>> STEVAL-MKI108V2 9DOF IMU - $35
>>> Fastrax UP501 GPS - $28
>>> ---------------------------------
>>> = $70
>>>
>>> I think a $70 hardware platform would be an amazing price breakthrough
>>> and really lower the barriers to participation in the PPZ project.  Cost
>>> alone might draw new people to the project, but existing members with a
>>> significant investment might also consider the benefit of redundancy.
>>>  People with existing systems could add a completely redundant backup to
>>> their system for a reasonable price, and new people could have a redundant
>>> system (excluding radio link) for only $140.  That could be a great safety
>>> improvement.
>>>
>>> I'm hooked on doing the project and if anyone else wants to help out it
>>> might not take me a year to get it working.  I'm happy to modify the
>>> discovery boards for anyone who wants to get involved without bothersome
>>> soldering. Just shoot me an email.  I'm planning to get more Discovery
>>> boards shortly and should have some modified ones ready to go before long.
>>>
>>> The only real disadvantage I see to this project is that it will require
>>> a rather complicated main wiring harness to connect everything up since it's
>>> not a custom board.  Fortunately, I think a IDE hard drive cable (or
>>> similar) will work pretty easily and we'll just have to put the right
>>> connectors to the right wires to end up with a decent connection system.
>>>  I'll be happy to make those also as soon as it is figured out how the pins
>>> best map with the PPZ code.
>>>
>>>
>>> -Jake
>>>
>>>
>>>
>>>
>>>
>>>
>>> ----- Original Message -----
>>> From: Felix Ruess
>>> Sent: 01/27/12 05:16 PM
>>> To: address@hidden
>>> Subject: Re: [Paparazzi-devel] Introduction, Q's about STM32 development
>>>
>>> Hi Jake,
>>>
>>> just a quick note: I don't think that creating new board files for the
>>> STM32VLDiscovery board would be much work (if you already know
>>> paparazzi). Also flash should just be enough, depending on what
>>> subsystems/modules you include. Flash usage is roughly around 120kB on
>>> my setup here..
>>>
>>> Cheers, Felix
>>>
>>> On Sat, Jan 21, 2012 at 4:15 PM, antoine drouin <address@hidden> wrote:
>>>
>>>
>>> Hi Jake
>>>
>>>
>>>
>>> The idea is that the door kicks open and the rope falls to the ground
>>> where it is drug a short distance where particles stick >to the collector,
>>> then the motor kicks in and winds the sample back up into the pod.  Then the
>>> plane returns to base. > Using variations of that system should make it easy
>>> to snag lots of samples from remote locations for cheap.  Obviously >the
>>> danger is that the sample rope gets tangled and the plane gets dashed into
>>> the ground at 30+ mph.
>>>
>>>
>>> how far do you need to go fetch your samples? Have you though about
>>> doing it with a quadrotor?
>>>
>>> _______________________________________________
>>> Paparazzi-devel mailing list
>>> address@hidden
>>> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>>>
>>>
>>> _______________________________________________
>>> Paparazzi-devel mailing list
>>> address@hidden
>>> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>>>
>>>
>>> _______________________________________________
>>> Paparazzi-devel mailing list
>>> address@hidden
>>> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>>>
>>>
>>>
>>> _______________________________________________
>>> Paparazzi-devel mailing list
>>> address@hidden
>>> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>>>
>>
>>
>>
>> --
>> Héctor
>>
>>
>> ________________________________
>> _______________________________________________
>> Paparazzi-devel mailing list
>> address@hidden
>> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>>
>>
>>
>> _______________________________________________
>> Paparazzi-devel mailing list
>> address@hidden
>> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>>
>
>
>
> --
> Héctor
>
>
>
> _______________________________________________
> Paparazzi-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>

_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel



--
Héctor



reply via email to

[Prev in Thread] Current Thread [Next in Thread]