Ben's Blog

No description yet.

  • Home
    Home This is where you can find all the blog posts throughout the site.
  • Categories
    Categories Displays a list of categories from this blog.
  • Tags
    Tags Displays a list of tags that have been used in the blog.
  • Archives
    Archives Contains a list of blog posts that were created previously.
  • Login
    Login Login form

Robotics and FPGAs (6) - The Project Plan 1, Managing the 17 DOF Robot Project

Posted by on in Robotics Using FPGAs
  • Font size: Larger Smaller

Up till now we have merrily plodded along in the construction and assembly of the 17 DOF robotics kit. However, as we all know projects very rarely have unlimited resources and budgets, unless of course they are being conducted by a superpower trying to prove a point. We are nof a FPGA superpower, neither are we trying to prove a point and more importantly our pockets are shallow.

Hence, just like in any discipline, we need a plan even if it is only a half-baked one to maintain focus, mitigate risk and prevent costs from spiralling out of control. So the focus of this blog post is to develop the skeleton of a project plan, which will be fleshed out as we progress in the series. We do things this way, as unfortunately, we do not have the resource to preplan the project in-depth before hand, which is typical of home-brew projects.

One way we can begin to manage this project is by organising the outputs from the various stages of the development. Hence, we begin to develop the skeleton of a project plan to manage the 17 DOF Robot Project by listing the predicted outputs of our development process. This is depicted in the diagram below.


The major components of the 17 DOF Robotics Project that we have encountered or expect to encounter in the next few episodes of the blog series are:

  • Robot Assembly,
  • (Project) Management
  • PCB Design
  • Digital Design and
  • Software (Coding).

Each of the sub-elements of these major categories, from the  Figure above, are addressed in the Table below.

Number Name Description
PRJ NUM-001 Schematic PCB design schematic sheets associated with the PCB design.
PRJ NUM-002 Layout PCB design layout files.
PRJ NUM-003 Gerbers PCB design gerber files.
PRJ NUM-004 (PCB) BOM PCB design Bill of Material (BOM)
PRJ NUM-005 Issue Tracker Issues tracked using Bugzilla.
PRJ NUM-006 Images Images used in documents, articles and blog posts.
PRJ NUM-007 Documentation Project related documents.
PRJ NUM-008 Parts Parts bought or designed as part of the robot assembly e.g the robotic kit, servo control board, etc.
PRJ NUM-009 BOM Parts list Bill of Materials generated from the list of assembled parts.
PRJ NUM-010 Test Code Software code written for test purposes only.
PRJ NUM-011 Application (Code) Code written specifically as part of the project. e.g Multi-servo monitoring software.
PRJ NUM-012  SystemC  SystemC hardware deign files.
PRJ NUM-013  HDL VHDL and verilog hardware deign files. 

 How does this numbering system work then? Well, for example, if the official name of the project is 043-17 DOF Robotics Project, then the project number, <PRJ NUM> is 043 and the numbering of each sub-item provided in the Figure should follow. For example schematic sheets, will begin with the number 043-001-<num>-schematic sheet name, where <num> is the schematic sheet number.

So if the first PCB design schematic sheet, designed for a Multi-channel servo control board, is titled headers.sch, then it could be saved as 043-001-001-headers.sch. If the second schematic sheet is a schematic of the servo drivers, it could be saved as 043-001-002-servodrivers.sch and so on and so forth.

This numbering scheme makes the schematic sheets instantly recognisable and locatable. Alternatively,  if there are corresponding folder names for the project number and for the schematic designs, then the schematic sheets could be saved like so  ../043/001/001-headers.sch. and ../043/001/002-servodrivers.sch respectively. Organisation is key to a successful project and our success will be based on this schema, which you will see in action in the next blog post.

Not uncoincidentally each of the green and blue ellipses in the Figure above could be regarded as a relational database entites.  Hence, if we focus on the Robot Assembly entity, as an example, it could be fleshed out into the database schema depicted in the following Figure.


Lets look at this Figure in a bit more detail. This picture, which is worth more than a thousand words, says the following:  

The Robot Assembly has or consists of Parts which have a name, a quantity, an (actual) cost, as well as a purchase date, which is a complex attribute, as it could be recorded as a time, a day, a month and a year. Parts are obtained from a Supplier and each one has a description, a cost and ideally a URL link to the part on the suppliers website. The Robot Assembly can be used to generate a Bill of Materials (BOM). This schema can easily be converted into a relational database schema, as we have demonstrated previously in our Tutorial Series Two Project and Project Management

Many of you may have noticed omissions or wish to add entities or attributes of your own to our skeleton entity-relationship diagram above.  You could and should do whatever you want! We know that we will never get time to sit down and write a fully accessible database for the project. Hence, we will progress the management side of things, as need be, but don't let us stop you!

On the bright side though, the cold, dark and wet British winter is just around the corner and we may have more time on our hands than we think. The coding of the Parts and Supplier database tables, in MySQL,  could be represented in the following way, where PR_KEY is a primary key and FN_KEY is the foreign key:

  • Parts (PR_KEY, name, quantity, actual cost, purchase data)
  • Supplier (PR_KEY, description, cost, URL)
  • PartsObtainedFromSupplier (FN_KEY Parts, FN_KEY Supplier)

Now that we have added some management structure to our 17 DOF Robotics Project in the next part of the blog post we will begin the design of our first PCB for the project, A Mulit-Channel Servo controller board. It is worth mentioning too that we will be using the Git versioning control system throughout this project.

We think, IOHO, this has been a worth while inclusion in this project, because from experience the more complex a project becomes the more likely it is to spiral out of control.  Although the beginnings of our project management plan seem half-baked for now, as we know from little acorns big trees grow and we will for sure develop this plan, into a forest of accessible information, as time permits.

Half-baked our plan may seem, but it is may be worth while remembering the words of the great Cuban world chess champion Raul jose Capablanca "Half a plan is better than no plan at all". More soon.

Last modified on