Brick Buddy Two Integration

With the successful integration of Motor control, the only missing functionality from Brick Buddy One is the Bluetooth interface and the scripting language.  The scripting language is going to take some thought, so I will do the BT interface first. 

Below is a quick video of LEDs bursting, cycling and pulsing along with one motor working at reduced speed.  You can see there are some issues with the green LED.  Right now I am going for functionality, then the code needs to be hardened.

The biggest issue was integrating a dynamic timer for the system timer (100ms, 500ms and 1000ms timing loops) and the static timer needed for the PWM, as explained in this post.  Harmony does not allow you to do this, so I had to do it manually.  How this was done is a topic for another post.  Then it was cleaning up the PC software to accommodate the speed functionality.

I suspect the BT is going to create it's own issues with the introduction of another serial port.  Right now a serial port is used to put out debug messages ( the ubiquitous printF type statements).  The BT module is on its own serial port and getting that installed will probably be as challenging as the second timer was.  Fortunately the debug port is static and I intend to make the BT serial power static as well.  So maybe it will be a little simpler.

After the BT is done and before I start the scripting, I am going to back into this code and start some cleanup.  There was some "hacking" done to get things to work and that needs to be fixed.  I am starting to see issues when the ICD3 is attached that I dont see when the board is just running.  I would like to spend some time with that also.

and the video

BC2 Integration #2

A quick update.  The LEDs and basic communication with the PC program over USB is done.  I have the same functionality that was present in the original Brick Buddy as far a s the LEDs are concerned.  Plus the same functionality in the control loop is done.  I am not ahppy with the way it works.  It is cross between the executive loop I had before and the Harmony framework of state machines.So some refactoring is in order.

Started the Motor Integration and realized it was not going to be that simple.  I have a Harmony system timer running now, Timer1 and instance IDX0.  The timer is dynamic  The motor test program used Timer 2 as the input to the CCP sections.  However this was also IDX0 and was a static implementation.  Merging these together will be challenging.  i intend to redo the motor test program using Timer 2 as IDX1 and see if that will simplify the problem.  More tomorrow.

Finally once the motor integration is done, the project will graduate to the final name, Brick Buddy 2.  so watch for it.

Brick Controller 1 User Videos

We have received two videos from a user in Georgia,  Considering that the young gentleman is only 10 years old, he has a very bright future as a Lego builder.  Here is one of the videos.

To see the other one and the rest of our video collection go to MyMakerTools.com and scroll down to User Videos.

MPLAB X Harmoney Framework - Lessons Learned

I will not say I am an expert on the Harmony Framework, but I have been using it for about a year now.  All of my experience is on version 2.06.  A couple of things I  have learned.

Copying a Project

Using the project copy feature in MPLAB X seems to be problematic.  I think I am using the standard (default) directory structure, I don't change anything when I created the Harmony project.

Not all of the source code seems to copy over and launching Harmony results in a not valid Harmony project message.  In the end I manually copied it over into a new directory and that seemed to work.  Now I always place files in the project using the relative reference method.  Something left over from the early days of MPLAB.  As added insurance, I renamed the original directory.  That way if any files were absolute referenced, then project would not compile and they would be identified.

Adding Features

My development philosophy is incremental for a software development project like Brick Controller 2.  That is  I get the basics of one feature, BSP, HID, RTCC, MicroSD, etc working and then integrate this into the bigger project.  This way I am not fighting both the feature and how it interacts with the bigger project.  I have found over the years that this is much easier and is, in most cases, how Agile development works. 

This is the approach I took with the Brick Controller 2.  What I discovered was that the Harmony Framework does not like it when you modify code or source files it generates.  In some cases it was trying to replace previous code or code that I placed with new code.  Needless to say, I selected "approve all changes" mode.  While this prevented overwrites of existing code that was needed, it would also prevent me from included new code.  There did not appear to be a way to copy the new segments onto the clipboard or anywhere else for later insertion.  This would lead to missing code and compile time failures.

My solution was to create a new project for every new feature.  This eliminated the code over writes.  It also had the added benefit of testing the feature in a standalone mode, before integration into the larger product.  You will have to go through all of the files in the directory "src" above and copy the relevant parts to the same file in the main project directory.  This does take a little time, but one big upside is that you are exposed to most of the generated code.  Once all of the code is transferred, you can compile and solve the inevitable integration issues.

Bricks by the Bay 2020

As I stated in this post, Bricks By The Bay 2020 will be a virtual affair.  We have signed up to attend.  This is the email announcement that we received.

After careful consideration, we've decided to take Bricks by the Bay into the online arena with a virtual version of the convention starting with an opening ceremony at 7 PM Pacific Friday July 10 continuing throughout the day on Saturday July 11.  While nothing can replace the feel of ABS under our fingertips, we hope to maintain the cool and clarity of our Vision 2020 theme and provide a fun and interesting experience for all of our fans. 

We will have virtual tours of MOCs built by Bricks by the Bay builders, panel discussions, workshops, LEGO Masters participants, talks, games, contests and a chance for you and your family to show off your own MOCs.

You can sign up for the virtual convention on this website (www.bricksbythebay.com) starting June 1.  There is a limit of 1000 attendees.  Registration for the virtual convention (per connection) will be $5.  If you visit us in the real world in 2021 we will have a printed convention brick for 2020 virtual attendees.

Let us know if you would like to be part of a presentation at the virtual convention. We will be contacting people from our recent survey but please let us know again if you do not hear from us.  We are assembling the schedule at this time!

We will be returning to the real world June 17-20, 2021 with our new theme being Looking Back which should allow your Vision 2020 MOCs to remain relevant while also giving you a chance to also build a depiction of history either recent or long ago.  We hope to see you at the Santa Clara Convention Center in 2021!

Attendees

So how is this going to work. Don't know, but it could be interesting.  Unfortunately I will not have anything new done in time.  So I will be attending as a viewer and not a presenter.  Going to the presentations will be fun, though I probably should have volunteered my presentation from 2018 on the the Planetary Space Port.  If they are anything like the Zoom meetings, the discussions might be more robust than a typical in person lecture.  How they are going to do MOCs will be interesting to see. 

I can see where this can even be applied next year to a full convention, where you can get people to attend from around the world, that otherwise could not go. 

Vendors

Bricks by the Bay is also considering some type of virtual presence for vendors.  This will be limited to a non interactive vendor hall.  But in the future this could be interactive with the right technology.  As soon as I know how this is going to work, I will update everyone.

BC2 - Integration Begins

Started integrating all the code that I developed earlier on the PIC32MX470 Curiosity Board.  First up was getting the HID device to work.  Well did not go exactly as planned.  First the transferring from the Curiosity Board to the BC2 Proto by changing the BSP files there was a small burp.  So I had to start that all over again. 

Two things happened:

1. Using the project copy function in MPLAB X, did not do what I thought it should.  The code would not compile and the Harmony framework would not start.  Web searches showed I was not alone in this.  In the end I just manually copied the directory and then went into MPLAB X and made sure all files were relative and not absolute.  To make sure there was no absolute references, I renamed the original directory.
2. The Harmony framework will on occasion  will want to overwrite existing code with what it thinks are changes.  In reality these could be additions that were added.  I assume the process is to never modify the files Harmony generates, but at least for me, this seems impossible.  So when the BSP changed, other code segments I had added were deleted.  Had to start over and be more diligent about the changes I approved.

With that hurdle overcome, compiling and running worked up to the point that the PC was to enumerate the USB HID device. The device was reset, but never configured and the PC announced the device was recognizable.  MY first thought was the same problem I had encountered on the Curiosity board.  But after examination that was not the problem.   I spent a day and half looking at everything I could think of.  Prepared another BC2 proto board just to see if there was a problem in assembly.  Reviewed the layout and the connections, this was my first working USB Type C connector board.  Everything was where and how it should be.  My only clue was that it seemed to be running slow, but I assumed that some loop was taking to long since the USB wasn't working.

I had long ago connected a serial port to spew the debug messages from the Harmony framework and the ones I put in it.  But now this was not working either, bits were coming but the baud rate was wrong.  Curious!  Checked all the code to make sure the baud rate was set correctly, no issue.

Then the light bulb went on, the clock setup had to be wrong.  Even the though the code indicated it was running at 80MHz, looking further into this segment, showed it was only a #define.  Now with the running slow I noted earlier, I went to look at the clock setup.  Sure enough it was using the setup from the Curiosity board.  Changing that to correct values and the USB HID connected to the PC followed by the PC software recognized the proto as a Brick Controller 2.  Now integration can truly begin.

BC2 with Basic Motor Control

I have basic motor control working.  Motor Port 2 has some issue in the forward direction.  Looking at the pin on a scope shows the waveform, only at a few hundred mVolts.  I suspect there is a short to ground somewhere but I have not spent the time to look for it.  The other 3 Motor Ports work so I moved on for now to testing and driver development. 

When I first started testing, the PWM frequency was 20KHz, but on the scope it did not seem as though LB1836M motor driver could handle it.  I eventually lowered the PWM frequency to 5KHz, which seemed to work better.  I have read where Lego is using 1150Hz.  After finishing some driver cleanup, I am going back to retest the PWM frequency and generate documentation for no load motor conditions.  Just so I have it for future reference.

Here is a video that shows the basic driver going forward and reverse.  The motor starts at 100% and then slows down 5% every second.  It is actually easier to hear the change than see it.  This particular MOC I use at shows for customer interaction.  I have the Android App (modified for show use) running on a small tablet and the customers, mostly kids, can rotate the turret left or right and then fire the cannon.  It also has a clear front so you can watch the large (multiple gears) gear train work.  Because the gear train is so large, there is a large amount of the slop and slip in it.  This slop was always obvious when it changed directions in that you could hear the motor turning but the turret was not moving.  Then once the gears caught up it would move in the new direction.  I suspect this is also happening even when going in the same direction.  As the motor slows down in small steps, the gear train takes time to catch up.  I need to run this test by increasing the motor speed and see what happens.