beaglepilot project boundaries

Google Summer of Code
1

Hi Victor, Anuj and Siddharth,

Jason Kridner has asked that the 3 beaglepilot projects be more isolated
from each other. At the moment the boundaries between them are not as
clear as they could be. I presume that Jason wants to see isolation so
that if one student doesn't make progress that it doesn't hold up the
others.

I've clicked the button on your 3 proposals so they are open for editing
again, so you can make updates based on this discussion if you want to.

The way I see the separation at the moment (based on current proposals) is:

Victor: hardware drivers, hw test code, realtime kernel evaluation and
         comparison, IDE integration, ROS integration, security review

Sidbh: PRU communication from Linux userland, port starterware to PRU,
        sensor drivers on PRU

Anuj: device tree for cape, PRU PPM/PWM handling, SPI on PRU, GCS development

(I know this isn't complete, just a rough summary)

Some of these components are well separated and are not dependent on the
work of the other students. For example the ROS integration work is well
separated I think.

Other pieces have overlap. The most obvious pieces of overlap are:

- the hw test code for the cape in Victors proposal will probably need
   the device tree that Anuj is planning to develop, unless Victor has a
   plan for writing the test code without a DTS?

- the hardware drivers in Victors proposal potentially overlaps with
   the SPI work by Anuj and the sensor drivers work by Sidbh.

To get the separation that Jason has asked for I think we first need to
work out the plan for the split between PRU and ARM functionality in
ardupilot on BBB. My current thought is that the split would be as
follows:

  - PPM/PWM/PPM-SUM on PRU (see earlier IRC discussions on why this is a
    good idea, and why not using the eCap and hw PWM chips)

  - I2C sensor drivers on ARM, either kernel drivers or userspace drivers

  - SPI sensor drivers on ARM, if possible. Either kernel or userspace
    drivers

Running the I2C drivers on the ARM I think is fairly obvious. We expect
the I2C sensors to be low rate (100Hz and below) for things like
magnetometer, airspeed sensor, sonar etc. The only real question is
whether we do in-kernel drivers or do userspace drivers via the AP_HAL
I2C abstraction layer. The existing port of ardupilot on BBB uses
userspace drivers, but there may be reasons to move them in-kernel.

The SPI drivers is trickier. So far I've done SPI drivers in userspace
on ARM, but the performance isn't (as yet!) great. I'm hoping that with
a bit of work on the Linux SPI code on BBB that it will be viable, but
if we find we can't support at least 4 sensors running with 1kHz
sampling on SPI with very consistent timing then we may need to look at
doing SPI transfers on a PRU.

This is where things get a bit tricky with project proposals. If the SPI
work on ARM goes well then Victors "hardware drivers" work can be
separate from the other two proposals. If however we find that we just
can't get SPI drivers on the ARM working well enough then the proposal
from Anuj on SPI on PRU will be needed (btw, I'd still think that we'd
do the main sensor drivers on ARM, we'd just offer an API to ask the PRU
to queue and service SPI transfers on behalf of the ARM - we would
dedicate one PRU to SPI transfers, probably interfacing via the AP_HAL
SPI API).

I think the solution to this overlap is to propose that Victor will work
on making the SPI drivers on ARM work as well as possible, while Anuj
will work on SPI on the PRU, working in parallel with Victor and not
depending on Victors work. Both are very worthwhile pieces of work, and
it is quite possible that we will decide in the end to use a mixture of
the two approaches in the final design. To choose between them we really
need both developed and well tested.

The next piece of overlap between the proposals is the PRU comms work
from Sidbh, and the PRU PPM/PWM handling from Anuj. At first glance this
looks like a dependency issue, but I think it is easily resolved. For
the PRU PPM/PWM work Anuj can use a simple shared memory ring buffer to
start with, similar to what Pantelis did here:

  https://github.com/pantoniou/testpru

then when the PRU comms API from Sidbh is ready, Anuj could choose to
start using it at his own discretion. That allows Anuj and Sidbh to make
progress independently.

Does that sound OK? If it does then it would be great if you could edit
your proposals a bit to make this separation a bit clearer. I'm sure
Jason would appreciate it!

Cheers, Tridge

2

Hi Victor, Anuj and Siddharth,

Jason Kridner has asked that the 3 beaglepilot projects be
more isolated from each other. At the moment the boundaries
between them are not as clear as they could be. I presume
that Jason wants to see isolation so that if one student
doesn't make progress that it doesn't hold up the others.

I think this is also a GSoC requirement to not have dependencies
on other projects.

3

Dear Andrew,

Thanks for your message. Following your advice I just finished updating my proposal. Included a clarification on the hardware tests specifying that “scripts coded in python (or code in C/C++) will be provided to independently test each different sensors (pretty much following the line that ardupilot has been doing so far, e.g.: example)”. Clarification on the hardware driver development has also been included.

Regarding the hardware tests without the DTS, I believe there’re different ways of doing this matter. From making calls to the userspace interface of the general-purpose memory controller (GPMC) in the code to use already available libraries **(**such as Adafruit_BBIO python library) that allows to operate both with SPI and I2C directly.
If somebody has a better idea on this matter, please point it out.

Bests,

Víctor.

4

Hi Víctor, thanks for the update!

One minor thing, in your update you have:

"With this two clarifications, this proposal pretends to be independent
to other's work."

I think the word 'pretends' is not what you intended. Perhaps "this
proposal is independent of other project proposals" ?

Cheers, Tridge

5

Of course, my mistake.
Thanks for the catch :).

Andrew, do you think that is possible to get some comments on these questions?

Bests,

Víctor.

6

Hi Víctor,

Andrew, do you think that is possible to get some comments on these
questions <Redirecting to Google Groups?

yep, I've replied on the beaglepilot list:

  Redirecting to Google Groups

Sorry for the delay in the review!

Cheers, Tridge

7

Hi Andrew,

I have made the following additions to my proposal.

I have already begun some work on a pin map for the BeaglePilot project. A device tree will be generated by me using the same for PixHawk Fire Cape. This work will ideally be done in the community bonding period as this is something that will be required for all work related to the BeaglePilot project, so should be available asap.

…
The main objective of the project is generating PWM and PPM signals using the PRU as well as making provisions for receiving PPM-SUM signals from radio devices. The interface for communication here can be used from the one available in panto’s testpru for the time being.

…
Bit banging SPI using the PRU is something that I would like to include. Of course SPI can be done very well from ARM, but I would like to explore how well it performs using multiple sensors and a dedicated PRU for the same. As per tridge, supporting at least 4 SPI sensors with 1kHz sampling and consistent timing is something that would be required of BeaglePilot and should be definitely explored using the PRU.

Also, I have updated the timeline as required.

Please check

Cheers,
Anuj

8

All of the development covered under my proposal will involve data sharing b/w PRUs and ARM and the driver development using the starterware library which will involve data writing and reading from ARM’s peripheral registers e.g. SPI, I2C, ecap etc while Anuj Deshpande’s work which will be totally done using only PRU’s resources e.g. SPI (using bitbanging), PPM/PWM and Victor’s work involving the usage of peripherals and resources connected to the ARM only (without PRU’s involvement). Thus this part of our work may have same output but from different direction and giving us choice to select what is best for beaglepilot but as the software developed will be reusable and all of the work that does not get involved in beaglepilot can still be used by other users with different requirements.

If this is the case the only clash that seems to occur involving my side of development will be with part of Anuj Deshpande’s work in which he requires uploading code and exchanging data with ARM. For resolving this issue Anuj Deshpande will be using panto’s development for PRU’s communication with ARM, so even if my development is under progress his work will be going on without any hiccups. And if my work is successfully completed then he may involve my side of developments into his work, which will be one of the last orders of business when all the loose ends will tie at APM_HAL.

These points i guess clears up the chances of inter-dependencies, none of our work will be paused until other one completes his task and all of our work will be usable independent of each other.
e.g.
My work can be used for any realtime development which involves accessing most of the peripherals connected to ARM.
Anuj Deshpande’s work can be utilised for development of any application with very hard real-time application with SPI as i/p entity and PWM/PPM as o/p entity which is the case most of the time in real-time control systems.
Victor Mayoral’s work independently can be utilized for many soft real-time robotic systems such as rovers, with support of ROS + Ardupilot.

In a Nutshell: Only intersections which will happen between the path of three of us will be for resolving compatibility issues, other than that our work will run on separate tracks and will mold into separate entities which can be either used together or one or two of them as per user’s preferences .

I’ll include these points as Note in my proposal if you all approve what has been written above.

-Siddharth B Purohit

9

All of the development covered under my proposal will involve data sharing b/w PRUs and ARM and the driver development using the starterware library which will involve data writing and reading from ARM’s peripheral registers including SPI, I2C, ecap etc while Anuj Deshpande’s work which will be totally done using only PRU’s resources e.g. SPI (using bitbanging), PPM/PWM and Victor’s work involving the usage of peripherals and resources connected to the ARM only (without PRU’s involvement). Thus some of our work may have same output but following different paths and giving choice to select the option that is best for beaglepilot.But since the software developed will be reusable the work that does not get involved in beaglepilot can still be used by other users with different requirements.

If this is the case the only clash occurring on my side will be with Anuj Deshpande’s work of uploading code and exchanging data, for resolving this issue Anuj Deshpande will be using panto’s development for PRU, so even if my development is under progress his work will be going on without any hiccups. And if my work is successfully completed he can involve his work with my side of development, which as per my understanding will be the last order of business when all the loose ends will tie at APM_HAL.

These points i guess clears up the chances of inter-dependencies, none of our work will be paused waiting for other one to complete his task and all of our work will be usable independent of each other.
e.g.
My work can be used for any realtime development which involves accessing peripherals connected to ARM.
Anuj Deshpande’s work can be utilized for development of any application with very hard real-time application with SPI as i/p entity and PWM/PPM as o/p entity which is the case most of the time in real-time control systems.
Victor Mayoral’s work independently can be utilized for many soft real-time robotic systems such as rovers, with support of ROS + Ardupilot.

In a Nutshell: Only intersections which will happen between the path of three of us will be for resolving compatibility issues, other than that our work will run on separate tracks and will mold into separate entities which can be either used together or one or two of them as per user’s preferences.

10

I’ll add these points to my proposal if you all agree what i’ve mentioned here.

-Siddharth B Purohit

11

Hi Siddharth,

I'll add these points to my proposal if you all agree what i've mentioned
here.

yes, please update the proposal, thanks!

Cheers, Tridge

12

Hi all,
I’ve added an additional point “Task Distribution with two other Beaglepilot Proposals” inside my proposal, pls have a look at it.

Regards,
Siddharth B Purohit