Risks

• Rev. 2 is late at this point, realistically no time for a third revision (mitigated by the fact that rev. 1 meets our M.V.P. pending some firmware updates)
• We’re beginning to implement the CMR-specific use case of the TOM: creating the ground control application that uploads the CAN bus stream to a remote server for a web application to display to other team members. This is a reach goal, thus is not planned for in our Gantt chart, thus has some deadline concerns.
• Range testing continues
  • Successful tests at pittrace under 150m proved promising but still not fully conclusive, further testing will rely on larger track areas on some of their other tarmacs in the coming weeks

Updated schedule

No updates: We’re still on schedule in terms of PCB schematic and layout, as well as firmware implementation. (See our Gantt chart for more details.)

I implemented, tested, and merged the UART commands (firewall block/allow/list, help, etc).

I refactored the config system in the stm32 drivers to increase flexibility. It now allows each client to specify the flash sector and config size. If I have time,  I can quickly update it further to only write up to the last updated flash word, rather than the entire cached config array.

We’ll be moving to implement the CMR use-case of the TOM: creating a ground control application that uploads data to a remote server for a web application to display to other CMR team members. This ground control application will communicate with the TOM via UART; I’ll be adding a command that prints the bridged CAN bus next week.

My accomplishments this week:

• • Got the rev. 1 prototype securely mounted in 19e, tested at pittrace, confirmed to maintain message timing on 2.4GHz at sub 150m ranges (using the 19dbi parabolic antenna mounted on a tripod)
  • Me on the roof of Stan’s car with our slightly ridiculous setup in the background, before it blew over in the wind (photo credit to Cindy Deng)
  • Settled on a design for the off-vehicle TOM enclosure (with the help of Aidan Honnold of CMR)

My personal deliverables for next week:

• I really need to get this board ordered, I’m pretty garbage at this point. Let’s say by Wednesday I’ll have it ordered
• Status on UART/firewall testing on Rev. 1 (ft. Stan and Cameron)

Updates on last week’s deliverables:

• I didn’t post last week because 19e needed extensive work until Wednesday night, hoping to get back into the swing of things now

Risks

• Major risks have been assuaged: weird connection dropping behavior determined to be the effect of a bug in our CMR-teamwide CAN interface, so with that fixed, the only notable source of packet loss seems to be RF-related
• Rev. 2 is late at this point, realistically no time for a third revision (mitigated by the fact that rev. 1 meets our M.V.P. pending some firmware updates)
• Range testing continues
  • Successful tests at pittrace under 150m proved promising but still not fully conclusive, further testing will rely on larger track areas on some of their other tarmacs in the coming weeks

Design changes

• None

Updated schedule

• PCB rev. is late at this point because Zach is bad, but that will be biting into the slack we provisioned in our Gantt chart

Individual updates

• Implemented some application-level UART code (reading, parsing, command-line, etc.)
• Tested firewall integration
  • It works as expected, but further synchronization is required for it to be actually usable
• Assisted in preparing the vehicle for PittRace track testing
• Tested telemetry reliability at PittRace
  • Used the large 19 dBi dish antenna, mounted on a tripod
    • The range and field-of-view were quite sufficient for our test track setup
  • UDP remains effective for our purposes
  • Recorded CAN traces are generally consistent
    • Packets only dropped when the vehicle exited the track area

Schedule status

Firewall and UART integration continues; it remains feasible under our current schedule.

Deliverables for 2019 Apr. 14

• UART configuration interface and implementation

I verified the firewall functions as expected.

I implemented a few versions of the UART command line and refactored them with Stan. It all works as expected, with no timeliness issues.

I implemented the command parsing part of the UART, but need to rebase it on the latest UART revision and test it on the TOM; I’ll do this on Sunday/Monday as I’m out of town for Carnival. I suspect it will be trivial.

I removed many unnecessary features from the firewall system. Now it simply permits adding to a single firewall blacklist by CAN ID: No multiple firewalls with different priorities.

The UART command line implementation hit a road block. The UART driver’s receive function uses DMA (direct memory access) and receive idle interrupts. This had a small bug: the transmit function triggered an idle interrupt after each transmission despite the idle flag not actually being set. This was fixed by trivially checking the idle flag.

The UART driver works as expected; I’ll be implementing the command line on Sunday. The DMA receive call is blocking, thus command handling must not happen in the receive task. I’ll probably update the driver receive to be non-blocking by adding a per-message synchronization rather than global synchronization, as Stan implemented with the driver transmit function last week. Alternatively, I could simply add the received commands to a queue for a processing task to handle.

There’s currently an issue with the CAN driver; once resolved I’ll run integration tests on the firewall for a sanity check.

Individual updates

• Performed even more vehicle integration testing
  • In our garage environment, the link is stable enough to be functionally equivalent to a wired connection
• Adjusted UART driver to support a queue of pending messages to transmit
  • This eases synchronization and concurrent usage of the UART driver API functions by the configuration task(s)
• Reviewed and merged flash configuration library
  • Integration is still pending

Schedule status

Firewall and UART configuration integration has fallen behind due to higher-priority concerns with getting the vehicle driving in time for upcoming testing deadlines. Slack time will likely be consumed to account for this.

Deliverables for 2019 Apr. 14

• Firewall integration
• UART configuration integration

Risks

• The switch to UDP helped us with link stability, but the connection still dies for a few seconds at a time.
  • This occurs with the XBees alone (i.e. direct USB-to-serial connections, rather than plugged into TOMs)
  • It is not clear what exactly is happening, so we will continue to research it.
• Rev. 2 changes are still pending review/order.
• Range testing still to be done.
  • Testing will occur soon in the FMS breezeway and parking lot.
  • Additional testing will likely occur at PittRace; the team plans on heading there for track testing in a few weeks.

Design changes

• No design changes have been made.

Updated schedule

• No updates: We’re still on schedule in terms of PCB schematic and layout, as well as firmware implementation. (See our Gantt chart for more details.)

My accomplishments this week:

• • Worked on updating Revision 1 for ordering by Monday
  • Tested CAN bridging with Stan (confirmed working, some latent problems such as intermittent connection stalls)
  • Helped Stan debug garbage coming over-the-air (ended up being a misreading of the encoder interface)
  • Screenshots of layup pending final version

Note: Next week I will largely be waiting for the revision 2 boards to come in, which means I’ll spend the back half of the week playing around with Stan with UDP, possibly doing range testing in a few other radio configurations.

My personal deliverables for next week:

• Status on having ordered BOM and gerbers by Monday

Updates on last week’s deliverables:

• Revision 2 nearly orderable, just have to finish routing the replaced connectors (also need to investigate why PCBway is reporting the existence of a 5mil neck somewhere in my pours)
• Settled on single breakout for UART lines @ 100mil pitch